Can you be sure that your GitHub isn’t vulnerable to an attack called RepoJacking? This alarming thread in the cybersecurity world is gaining more and more concern with days. The fact is that millions of software repositories on GitHub may be vulnerable to this kind of attack according to Aqua’s study released in June 2023.
So, in this blog post, we’ve decided to figure out what GitHub RepoJacking is and what measures to take not to be a sitting duck.
RepoJacking: short description
Dependency repository hijacking has already been threatening software houses for years. It can potentially have affected major projects of such companies as Google, Kubernetes, GitHub, NodeJS, and many others. RepoJacking is a supply chain vulnerability with a subdomain takeover-like conceptual underpinning. In more common language, it results in that the attacker may take over retired organizations or users’ names and publish trojanized versions of repos to run some malicious code in it. Let’s look at the actions that can make a RepoJacking possible and your GitHub vulnerable…
How a repo becomes vulnerable?
There are only two most common methods that RepoJacking attackers may potentially use:
- A username swap, which takes place when a GitHub user changes his nickname on GitHub (his username), and a hacker can potentially register the new repo with the original name,
- An account deletion, which happens when a GitHub user deletes his account and a malevolent actor re-registers a deleted account and re-creates the initial repo. To avoid breaking the link and, as a result, getting errors for those projects’ URLs, attackers should manage to register the deleted username between the moment of actual deletion and the refresh of the project.
Who is vulnerable to RepoJacking?
If you rely on dynamically linked code from GitHub sources for compilation, then your project may be potentially vulnerable. Actually, to understand it better let’s look at an example.
You may use both commercial and open-source resources in your company, it’s an obvious thing and a usual practice. Let’s imagine that your code is designed to use dependencies from another project on GitHub and the link to it looks like: github.com/username_N/repo_N. From that, we know that the owner of the repo’s username is_ N_ and his project is N, as well. One day this user N decides to change his username. Why not? It’s absolutely essential, and GitHub permits us to do it… So, his new name is, let’s say, A.
Here should be mentioned that GitHub automatically will create a new link and will redirect all the users to another link with a new username: github.com/username_A/repo_N. Sounds cool from your DevOps experience side!
Though, here comes the risk of becoming vulnerable to RepoJacking as an attacker can easily use the previous account user’s name and at the precise moment he creates his repository, which has the same name and repository name as an old one. So, the link between the current name and the once-created repo is broken and an attacker can take control of the repository and upload there any malware. Thus, everybody who will download the dependencies from the previous repo is automatically redirected to the new account where a bad actor may have already pushed some malicious code. So, that it…it’s the way you may be vulnerable!
RepoJacking: Use Cases
This unpleasant situation concerns not only individual users but also organizations. For example, in the analysis conducted by Security Innovation in 2020, they found more than 70K impacted open-source projects, which included projects of GitHub, Google, Facebook, NodeJS, Kubernetes, Amazon, and others. Now the number of vulnerable projects may go up to millions according to Aqua’s 2023 report in June. This news burst the cybersecurity media and it’s possible to find numerous mentions of this topic.
Here are some Use Cases of Repojacking incidents in action:
CTX Hijack
In May 2022, the PyPI expository for the Python package CTX was taken over. Due to the fact that the original domain-hosting email of the repository owner had expired, hostile actors managed to reset the password and re-register the domain. Determined to replace the original versions, the bad actor made a fast upload of malicious packages. As a result, there were over 27K downloads of the malicious CTX versions during 10 days. After being detected, the hijacked account was suspended and all the versions of CTX were removed.
PhPass
Again, in May 2022, a similar incident occurred to the PHP package PhPass. When the owner deleted his account and an attacker registered a new account using the same name, and, thus, getting full control of the original repository. The attacker changed the original package versions for the malicious ones. To solve this issue and fight corrupted package versions, there was created a forked repository with non-malicious versions. After that, there was made a redirect to the new fork from the original URL.
UAPaser.js
Almost a year earlier, in October 2021, after the threat actor accessed an NPM account, he managed to corrupt a popular JavaScript library UAParser.js. Actually, to be more exact, he published three malicious versions of the library. And we’ve already mentioned that this library was rather popular! The threat actor managed to exfiltrate a lot of sensitive information from Windows systems and cryptocurrency mining software with malicious code. To remediate and fight the corrupted library, the malicious versions were quickly removed, and to mitigate automatic upgrades to those compromised versions some new ones were released.
How does GitHub deal with RepoJacking?
Of course, GitHub has never been standing aside and has been trying to block RepoJacking for years. One such protection measure is a high volume of cloning or repository namespace retirement mechanism. It works like this: if a user has more than 100 clones at the moment he changes his name, his account name is considered “retired” and other users can’t use it. But can it guarantee the protection of your repo?
Unfortunately, there is a fly in the ointment… those repositories that were previously unpopular yet became favored after the ownership shifted to major organizations are not covered by this protection measure. So, here is a loophole attackers may easily use…
Another security measure is multifactor authentication, or 2FA, which is going to be obligatory for GitHub users. In this case, a user has to provide more than one authentication credential. For example, an email address and a telephone number.
Is it possible to minimize the risks?
Unfortunately, there is no magic pill not to be exposed to RepoJacking. You can only try to minimize the risks by building a GitHub security strategy addressing different disastrous scenarios, including this software supply chain attack, and you can use different DevSecOps apps to mitigate the risks. However, the following security tips won’t be redundant:
Tip 1 Better understand what GitHub open-source software you’re using
It’s a usual practice for organizations to use open-source software to operate some of their procedures. Thus, it’s important to check if those tools are vulnerable from time to time.
Tip 2 Monitor if the name of open-source has been changed or moved
As we already mentioned before, you should have your finger on the pulse. It’s important to check from time to time if an open source you depend on has some changes in naming or is removed.
Tip 3 Fork the repository before using it
Security should always be in the first place, so before starting to use any data found in open-source it’s better to fork it. It will help you to have a full copy of the entire repo you need and, it will also permit you to control and audit the forked one.
Read more about git forking in our blog post: Git Forking Workflow.
Tip 4 Keep up with SBOM
Software bill of materials (SBOM) is a methodology that enables developers and security professionals to get full visibility and control over the codebase of the application stack they use. It can assure them that their company doesn’t run vulnerable open-source components. What’s more SBOM permits to keep track of patches and critical updates of the components the company uses. So, don’t hesitate to check the software you are using or are about to use.
Tip 5 Security is a first-class concern
No doubt it’s hard to be sure that the software you’re developing is completely secured. Though, to stay peace of mind you need to try to do your best to guarantee your code is under protection and that you can access it at any time. So, it’s important to use two-factor authentication and firewalls, enable control access restrictions, and change your access tokens or SSH keys on a regular basis.
Moreover, you should think about backing up your GitHub environment to WORM-compliant storage regularly. How to build your GitHub backup strategy effectively we explained in our GitHub Backup Best Practices.
Want to know what other dangers can await your source code? Check our Ultimate Review of the most infamous GitHub-related incidents in 2022 and learn more cases of attacks and vulnerabilities in GitHub.
✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights
🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial
📅 Let’s discuss your needs and see a live product tour
Top comments (1)
More artifact repositories should take Maven Central's approach of immutable artifacts. In the PhPass attack that you describe, the attacker changed existing versions for malicious ones. If artifacts were immutable, then the attacker would have been limited to publishing new versions and would not have been able to change existing versions. Obviously immutable artifacts isn't a full solution, but it does limit what an attacker can do even if they takeover the account of a legitimate owner. It also gives downstream projects the chance to audit the new versions before moving to them. When package repositories allow changing existing versions, a prior audit of a dependency version can be bypassed without warning.