A logical flaw in GitHub allows attackers to take control over thousands of repositories, enabling the poisoning of popular open-source packages.
This flaw is yet to be fixed and the steps to exploit it were recently published, making it highly likely that we will see more of these in the near future.
What happened?
A few days ago, someone launched an attack on three popular open-source packages. Two of these attacks were done by the use of the RepoJacking technique.
Due to the popularity of the packages that the attacker compromised — millions of total downloads — the attack was widely reported and yesterday a security researcher took ownership over these attacks and published his own blog explaining the technique he used.
The blogpost included the steps to reproduce a bypass for the “popular repository namespace retirement” protective measure put in place by GitHub to prevent users from hijacking repositories of renamed usernames.
Since this issue is still unresolved it is likely that other attackers will try to use this bypass and potentially cause serious damages to the open-source ecosystem by poisoning popular software packages with malicious code.
The Checkmarx Supply Chain Security team has been engaged in a responsible disclosure process of this issue for the past six months.
RepoJacking Protection
One of the many features GitHub provides is the ability to rename your user account. Users taking advantage of this renaming option leave all of their old repository names vulnerable to takeover by a technique referred to as RepoJacking.
To avoid this potentially harmful behavior, GitHub put in place the following protection measure: any repository with more than 100 clones at the time its user account is renamed, is considered “retired” and cannot be used by others.
To clarify: what is considered “retired’ is the namespace, meaning the combination of the username and the repository name.
For example, let’s take the repository named “repo” of the username “account-takeover-victim”.
This repository was recently cloned 100 times, which qualifies it for the popular repository namespace retirement.
At this point, the account’s owner decides to rename the username to whichever name they choose.
The practical result of this is that the username “account-takeover-victim” can now be claimed by anyone.
However, once the new owner of this username tries to open a new repository under the name “repo,” they will be blocked and get the following message:
This way, the old username is available for anyone to claim, but once this new owner of the username tries to create a new repository with a “retired” name, GitHub blocks this attempt.
Bypassing the protection
To bypass this “retired namespace” protective measure, attackers will need to be a little bit premeditated.
Instead of:
- Claiming the targeted username (“repo”)
- Then trying to create a repository with the targeted repository name (“account-takeover-victim”)
an attacker will need to:
- Open a random GitHub account
- Create a repository with the targeted repository name (“repo”)
- rename the account’s name to the targeted username (“account-takeover-victim”)
What’s the Impact?
The fact that any attacker can claim GitHub repositories that were renamed has an enormous impact on the open-source ecosystem.
One reason for this is the numerous languages that pulls packages’ code directly from version control systems, prominently GitHub, and uses GitHub URLs as pointers for packages.
Among these languages are:
- Go
- Swift
- PHP
This puts dozens of thousand open-source packages at risk of hijacking. The Go and Swift languages alone have more than 10,000 packages that are vulnerable to this attack vector. The practical meaning of that is that thousands of packages can immediately be hijacked and start serving malicious code to millions of users and many applications.
Swift and GoLang vulnerable packages
Considering the major role GitHub plays in software development and specifically in open-source software, it’s reasonable to assume that other repercussions exist.
Disclosure
The Checkmarx Supply Chain Security (SCS) team discovered this issue over six months ago and has been engaged in a responsible disclosure process with GitHub ever since. We refrained from publishing this bypass as this issue is still not resolved by GitHub.
Although this bypass wasn’t made public at that time, Checkmarx SCS team has released the ChainJacking open-source tool to help Go developers detect vulnerable packages in their dependency trees.
As the recent PHP hijacking showed, this weakness is being exploited in the wild. The public disclosure of the steps to reproduce this bypass will likely result in copycats that will take advantage of it.
Disclosure Timeline
- 1 Nov 21 – We found a way to bypass the GitHub namespace retirement validation feature
- 8 Nov 21 – We disclose the bypass findings to GitHub
- 8 Nov 21 – GitHub acknowledged the bypass and replied that they are working on a fix
- 24 Mar 22 – GitHub respond that they have fixed the bypass
- 11 May 22 – We discover that the bypass is still exploitable (fix not working)
- 12 May 22 – We report back to GitHub that their fix is not working, and this bypass is still exploitable
- 23 May 22 – This attack was found active against open-source attack
- 25 May 22 – This technique was published publicly by the security researcher taking ownership of the attacks
To sum up
The ability to claim the name of any GitHub repository belonging to a renamed user account is a highly undesirable weakness in GitHub’s architecture and for that reason, they created a protective measure to block that specific behavior.
The fact that this protection can be bypassed and is currently used in the wild is highly concerning and has a huge effect on several popular programming languages, among other things.
Understanding the graveness of the situation, we have employed an inhouse monitoring system that actively tracks down attempts to exploit this flaw. We will work with GitHub to block these attackers until a full fix is in place.
We urge developers to avoid this possible risk by making sure that they are not susceptible to it using our open source ChainJacking tool.
We will continue working together with teams like GitHub’s to keep the ecosystem safe for all developers and their application users.