Millions of GitHub repositories may be vulnerable to dependency repository hijacking, also known as “RepoJacking,” which could help attackers deploy supply chain attacks impacting a large number of users.
The warning comes from AquaSec’s security team, ‘Nautilus,’ who analyzed a sample of 1.25 million GitHub repositories and found that about 2.95% of them to be vulnerable to RepoJacking.
By extrapolating this percentage to GitHub’s entire repository base of more than 300 million, the researchers estimate that the issue affects approximately 9 million projects.
What is RepoJacking
Username and repository name changes are frequent on GitHub, as organizations can get new management through acquisition or merger, or they can switch to a new brand name.
When this happens, a redirection is created to avoid breaking dependencies for projects using code from repositories that changed their name; however, if someone registers the old name, that redirection becomes invalid.
RepoJacking is an attack where a malicious actor registers a username and creates a repository used by an organization in the past but which has since changed its name.
Doing so results in any project or code that relies on the dependencies of the attacked project to fetch dependencies and code from the attacker-controlled repository, which could contain malware.
GitHub knows about this possibility and implemented some defenses for RepoJacking attacks. However, AquaSec reports that the solutions have so far been incomplete and easily bypassed.
For example, GitHub only protects highly popular projects, but those projects may use a dependency from a less popular, vulnerable repository that isn’t covered, so the supply chain compromise impacts them too.
Also, GitHub protects repositories with over 100 clones the week before changing name, indicating malicious preparations. This protection doesn’t cover projects that became popular after their rename or transfer of ownership.
Exploitation potential
To highlight the importance of the problem, AquaSec scanned renowned organizations for vulnerable repositories and found exploitable cases in repos managed by Google and Lyft.
In Google’s case, a readme file containing instructions on building the fairly popular project “Mathsteps” pointed to a GitHub repository belonging to Socratic, a company that Google acquired and assimilated in 2018 and no longer exists.
Since an attacker can clone that repository to break the redirection, users following the readme instructions could have downloaded malicious code from the rogue repository.
Also, because the instructions included an “npm install” command for the dependency, the attacker’s code would achieve arbitrary code execution on the devices of unsuspecting users.
In the case of Lyft, the attack would be more automated, as AquaSec found an installation script on the company’s repository that fetches a ZIP archive from another repository, which is vulnerable to RepoJacking.
An attacker registering a new username and repository with the right names (“YesGraph” and “Dominus” in this case) could inject their code to anyone executing Lyft’s “install.sh” script.
Conclusion
Unfortunately, the risk of RepoJacking is widespread, hard to mitigate, and can have severe repercussions for organizations and users.
Project owners should minimize the resources they fetch from external repositories as much as possible.
Additionally, owners should consider keeping control of repositories of old brands or of acquired entities, just to prevent dependency hijacking attacks on themselves and their users.