Breaking News: How a Massive Malware Attack Almost Occurred on GitHub

Earlier today, Stephen Lacy published a Twitter post about a massive attack attempt on GitHub. This attack attempt is a huge deal, but fortunately it seems the attack was prevented from being successful and no GitHub repositories appear to be compromised.

35,000 of the most popular repositories on GitHub were cloned and had malicious code insertions. It seems that no actual malicious code was merged back to the original repositories, and GitHub removed all traces of that code which was designed to steal sensitive data such as cloud credentials, passwords, environment variables, documents and more.

The protection GitHub provides: forcing a first-time contributor to a repository to be approved by a repository member before making a contribution, kept this attack from becoming devastating. However, one slip could have made a huge impact.

We still don’t know who is behind this attempt and what they tried to gain, but this type of attack is yet another example of bad actors attacking software development pipelines and targeting the development systems used when building those pipelines. These types of attacks have become known as software supply chain attacks and they are a massively growing threat.

[This blog is being actively updated as we learn more about the incident.]

The possible flow of a successful attack

We have been pointing out how vulnerable the GitHub ecosystem is to attack, and this latest news demonstrates that someone attempted to take advantage of that.

This type of clone and then merge (pull request) with malicious code is sometimes called “pawn request”.

To successfully carry out a similar attack, the adversary needs to:

1. Make a clone or a fork of a very popular repository.
2. Alter the latest commit to contain malicious code that steals data, mines cryptocurrency, etc.
3. Make the malicious change look innocent by pretending to be the original author, which is done by spoofing the contributor email in the commit metadata. (Note: The attacker cannot make this change appear as GPG signed.)
4. Create a pull request to the original repository, causing a GH action to run. Here the attacker can either leverage a flaw in the CI script and immediately steal data, alter the original repository, or hope that the malicious contribution will be accepted due to the lack of attention of the reviewer.

What can you do to protect your repository against such attacks

1. Use commit signing. As noted above, the attacker cannot make their change appear signed. Without commit signing it would be difficult to detect spoofed commit metadata.
2. Remove vulnerabilities from your GitHub Actions build script. (Learn more from our series of blogs on vulnerable GitHub Actions workflows.)

Additionally, there are many crawlers indexing libraries in GitHub (e.g., pkg.go.dev), and if some of them caught the vulnerable clones, users might be fooled by referencing them directly from there.

Legit Security can help you prevent the next attack

Verifying the integrity of the packages you’re using is critical for your software supply chain security. Legit Security protects your pre-production development environment from source to build to artifact. This includes, but is not limited to, detecting dangerous misconfigurations like using unsigned commits in your development pipelines and finding GitHub Action vulnerabilities that might put your project at risk of being compromised by a malicious pull-request.

To learn more about the Legit Security SaaS platform check out our platform page or book a demo today.