Checkmarx warns that attackers could have exploited the renaming of popular GitHub accounts to create malicious repositories using the vacated name and launch software supply chain attacks.
The technique, dubbed RepoJacking, involves the hijacking of a renamed repository’s traffic by breaking GitHub’s redirection mechanism, and routing the traffic to a malicious repository controlled by the attacker.
Each GitHub repository has a unique URL under the user account that created it and, whenever the repository is cloned, the full repository URL is used.
When a user changes their GitHub account username, the URL is changed by replacing the old username with the new one, and the code-hosting platform automatically redirects users to the new URL (for example, github.com/username/repo becomes github.com/new-username/repo).
An attacker aware of the change could have hijacked the old URL traffic by creating a GitHub account using the old username, and then creating a repository matching the old repository’s name, thus gaining control over the github.com/username/repo URL and breaking the default redirect.
“A GitHub repository is vulnerable to RepoJacking when its creator decides to rename his username while the old username is available for registration. We have shown the coupling in the repository URLs between the repository name and the creator username, and this means attackers can create a new GitHub account having the same combination to match the old repository URL used by existing users,” Checkmarx notes.
To prevent such attacks, GitHub implemented a mechanism to ‘retire’ repositories with over 100 clones at the time the user renames their account. However, GitHub would only consider as retired the namespace, or the combination of username and repository name.
Thus, should a user decide to change their account’s username, a malicious attacker could then create a new GitHub account using the old username, but would not be allowed to create under it a repository using a name that would match a ‘retired’ combination.
What Checkmarx discovered was that the ‘popular repository namespace retirement’ protection measure could be easily bypassed.
For that, an attacker would need to create a new GitHub account with an arbitrary name, create a repository with the name of the target repository, transfer the ownership of the repository to a different account, then rename the second account to the old username of a recently renamed account.
Thus, they would gain control over the URL containing both the old username and the repository name of the targeted popular account, and could launch software supply chain attacks.
“Successful exploitation enables the takeover of popular code packages in several package managers, including ‘Packagist’, ‘Go’, ‘Swift’, and more. We have identified over 10,000 packages in those package managers using renamed usernames and are at risk of being vulnerable to this technique in case a new bypass is found,” Checkmarx notes.
The software security company explains that the bypass could also allow attackers to take control of popular GitHub actions consumed by specifying a GitHub namespace, which could lead to major supply chain attacks.
Checkmarx says it initially identified the namespace retirement protection bypass in November 2021 and that GitHub has made several attempts to address it, with a complete patch rolled out in September 2022.
“The mechanism that was found vulnerable, the ‘Popular repository namespace retirement’, remains an attractive attack point for supply chain attackers in the future,” Checkmarx says.
As a result, the company has released an open source tool to help identify packages that are at risk, warning that an attacker exploited a similar issue earlier this year to hijack and poison PHP packages that have millions of downloads.
Related: Timing Attacks Can Be Used to Check for Existence of Private NPM Packages
Related: GitHub Improves npm Account Security as Incidents Rise
Related: PyPI Served Malicious Version of Popular ‘Ctx’ Python Package
Ionut Arghire is an international correspondent for SecurityWeek.
Tags:
