Software supply chain security has gotten attention since 2020 after the SolarWinds attack. The open-source ecosystem also suffers from breaches targeting the supply chain. While multiple vulnerabilities have been patched since then, the threat persists.
If you missed Part 1 of our research, where we uncovered how repository hijacking affects GitHub repositories in 2024, you can read it here. There we showed how to run a massive scan over all GitHub repositories and managed to excavate 1363 vulnerable to repojacking.
In this article, we explore hidden repojacking consequences and share mitigations.
Repository hijacking, or repojacking occurs when cybercriminals take control of a code repository. This often occurs through an 'account resurrection' attack, where an attacker reclaims a previously deleted or renamed user or organization name.
GitHub's current recommendation to use package managers doesn’t solve the core issue: direct links to repositories aren’t reliable.
Direct links issue.
Package managers typically display a source code link for published libraries, which developers rely on for documentation and additional instructions. Hijacking the source code repository leads to a URL hijacking attack on a package main page.
Direct links to sources can't be trusted - GitHub and others do not guarantee repository persistence.
We have checked vulnerable repositories searching for those that have a package published. Not surprisingly, a few dozen vulnerable packages were found on major package managers. A particularly concerning case involved a vulnerable PyPi module that provides an API to remotely control a door lock from a well-known vendor. And the record-breaker was the Ruby library, the latest version of which has been downloaded almost 300,000 times!
Here is the screenshot of the vulnerable package page at rubygems.org, notice the Homepage link:
If any of your dependencies are vulnerable to repojacking through account resurrection attacks, a quick defense is to register the deleted account at the source code repository. Check out how we did it for the mentioned vulnerable Ruby library and the disclaimer we put into the README.md.
A better solution would be to tie the direct links to a unique user or repository ID. For example:
-
github.com/<org>/<repoId>or github.com/<org>/<repoName>?repoId=<repoId>
Currently, no major Git platform offers this capability. We have been in contact with GitHub and they have not expressed interest in implementing our suggestion.
Package managers could also take a more proactive approach by verifying links on their end using programmatic solution, like checking user IDs.
Top comments (0)