GitHub, a code repository which is used by more than 83 million developers across the globe, has been the victim of a supply chain attack.
The attack was discovered on the morning of 3 August by software developer Stephen Lacy and involved a bad actor cloning and adding malicious code to more than 35,000 GitHub repositories, while keeping the code’s original source code. Almost 40 percent (13,000) of the repositories affected originated from a single organization, referred to as “redhat-operator-ecosystem” on the site, a spoof of RedHat openshift ecosystem.
Additionally, the cloned projects attempted to encourage users to click on them by spoofing genuine user accounts, using names that were very similar to the original projects they were clones of and using legitimate-sounding organization names.
The malicious code allowed the repositories to collect information on the environment they were executed in, for example, identify information on the device it was executed on and the user that executed it, as well as the potential to collect other sensitive data.
The code could also download additional malware from a third-party site that allowed it to further exploit any application or environment that was using the malicious cloned code originally introduced to the GitHub repositories.
The weaponized code could lead to developers accidentally downloading cloned code repositories which contain the malicious code. If used in their applications, this would then lead them to exposing their users to code which includes malware.
The attack was reported to GitHub by Lacy, who, according to Lacy, “cleaned up” the attack and stopped it spreading further by removing the affected projects and organizations.
What is cloning?
GitHub allows developers to store, track and control source code within the repository. It also allows for collaborative efforts between developers, meaning developers on GitHub are able to contribute to code deposited on the site by other members. Any changes, however, are controlled by the owner of the original code, who has full visibility on any changes made, and can choose to accept or reject any changes.
Members of the site can, and frequently do, download code stored on GitHub for use in their own projects or applications. Developers can also use GitHub’s clone function to make an exact copy of a developer’s code. This does not affect the original version of the code and allows the developer who uploaded it to retain its existing statistics (for example, views, contributions and follows). The cloned code has none of these statistics and essentially becomes new code. Developers often clone code if they wish to make significant changes to code created by another developer.
Preventing supply chain attacks
GitHub has provided advice for securing the code supply chain on its website. The advice contains three steps:
- Securing the account
- Securing code on the supply chain
- Securing the build system
Securing the account
By securing their accounts, developers make it harder for bad actors to access their original source code. GitHub suggests doing the following:
- For accounts used for personal use as well as those used by organizations and enterprises, set up two-factor authentication.
- Connect to GitHub using secure socket shell (SSH) keys.
- For enterprises, centralize user authentication.
Securing code on the supply chain
By securing the code on the supply chain, developers can mitigate the risk that the code they are using to build their project is exposed to. GitHub advises that developers:
- Create a vulnerability management program for dependencies which will allow them to have full visibility over any vulnerabilities the code they are using has.
- Secure communication tokens by not using passwords or API keys within source code.
- Keep vulnerable coding patterns out of your repository by reviewing and testing all pull requests before merging.
Securing the build system
By securing the build system, developers can protect against attacks that target their system without exploiting vulnerabilities in the system like dependencies or gaining access to accounts. GitHub recommends safeguarding against these attacks by:
- Signing all builds with a public and private cryptographic key pair. By using the private key to sign the build and publishing the public key, the signature on the code can be verified before it is used. This means that if the bytes of the build are changed, the signature will no longer verify.
- Hardening security for GitHub Actions by evaluating the treat levels of third-party workflows before using them, and limiting who can make changes to your code by using codeowners.