GitHubs new policies allow removal of PoC exploits used in attacks

GitHub announced on Friday their updated community guidelines that explain how the company will deal with exploits and malware samples hosted on their service.

To give some background behind the new policy changes, security researcher Nguyen Jang uploaded a proof-of-concept exploit (PoC) to GitHub in March for the Microsoft Exchange ProxyLogon vulnerability.

Soon after uploading the exploit, Jang received an email from Microsoft-owned GitHub stating that PoC exploit was removed as it violated the Acceptable Use Policies.

In a statement to BleepingComputer, GitHub said they took down the PoC to protect Microsoft Exchange servers that were being heavily exploited at the time using the vulnerability.

“We understand that the publication and distribution of proof of concept exploit code has educational and research value to the security community, and our goal is to balance that benefit with keeping the broader ecosystem safe. In accordance with our Acceptable Use Policies, GitHub disabled the gist following reports that it contains proof of concept code for a recently disclosed vulnerability that is being actively exploited.” – GitHub.

However, GitHub faced immediate backlash from security researchers who felt that GitHub was policing the disclosure of legitimate security research simply because it was affecting a Microsoft product.

GitHub releases updated guidelines

In April, GitHub issued a ‘call for feedback’ to the cybersecurity community regarding their policies for malware and exploits hosted on GitHub.

After a month of input, GitHub officially announced yesterday that repositories created to host malware for malicious campaigns, act as a command and control server, or are used to distribute malicious scripts, are prohibited.

However, the uploading of PoC exploits and malware are permitted as long as they have a dual-user purpose.

In the context of malware and exploits, dual-use means content that can be used for the positive sharing of new information and research while at the same time can also be used for malicious purposes.

The key changes added to the GitHub guidelines are summarized below:

We explicitly permit dual-use security technologies and content related to research into vulnerabilities, malware, and exploits. We understand that many security research projects on GitHub are dual-use and broadly beneficial to the security community. We assume positive intention and use of these projects to promote and drive improvements across the ecosystem. This change modifies previously broad language that could be misinterpreted as hostile toward projects with dual-use, clarifying that such projects are welcome.

We understand that many security research projects on GitHub are dual-use and broadly beneficial to the security community. We assume positive intention and use of these projects to promote and drive improvements across the ecosystem. This change modifies previously broad language that could be misinterpreted as hostile toward projects with dual-use, clarifying that such projects are welcome. We have clarified how and when we may disrupt ongoing attacks that are leveraging the GitHub platform as an exploit or malware content delivery network (CDN). We do not allow use of GitHub in direct support of unlawful attacks that cause technical harm, which we’ve further defined as overconsumption of resources, physical damage, downtime, denial of service, or data loss.

We do not allow use of GitHub in direct support of unlawful attacks that cause technical harm, which we’ve further defined as overconsumption of resources, physical damage, downtime, denial of service, or data loss. We made clear that we have an appeals and reinstatement process directly in this policy. We allow our users to appeal decisions to restrict their content or account access. This is especially important in the security research context, so we’ve very clearly and directly called out the ability for affected users to appeal action taken against their content.

We allow our users to appeal decisions to restrict their content or account access. This is especially important in the security research context, so we’ve very clearly and directly called out the ability for affected users to appeal action taken against their content. We’ve suggested a means by which parties may resolve disputes prior to escalating and reporting abuse to GitHub. This appears in the form of a recommendation to leverage an optional SECURITY.md file for the project to provide contact information to resolve abuse reports. This encourages members of our community to resolve conflicts directly with project maintainers without requiring formal GitHub abuse reports.

While dual-use content is allowed, the new GitHub guidelines around PoCs and malware states that they retain the right to remove dual-use content, such as exploits or malware, to disrupt active attacks or malware campaigns utilizing GitHub.

“In rare cases of very widespread abuse of dual use content, we may restrict access to that specific instance of the content to disrupt an ongoing unlawful attack or malware campaign that is leveraging the GitHub platform as an exploit or malware CDN. In most of these instances, restriction takes the form of putting the content behind authentication, but may, as an option of last resort, involve disabling access or full removal where this is not possible (e.g. when posted as a gist). We will also contact the project owners about restrictions put in place where possible. Restrictions are temporary where feasible, and do not serve the purpose of purging or restricting any specific dual use content, or copies of that content, from the platform in perpetuity. While we aim to make these rare cases of restriction a collaborative process with project owners, if you do feel your content was unduly restricted, we have an appeals process in place.” – GitHub.

GitHub states that they continue to support community feedback regarding their policies to continue improving their policies.

Update 6/5/21: Removed a comment to the PR as it was related to the previously proposed language and not the current guidelines.

Source

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s