GitHub RepoJacking: Are You Sure Your GitHub Is Safe?

Dependency repository hijacking or RepoJacking, which has already been threatening software houses for years, 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 RepoJacking possible and your GitHub vulnerable…

How Does a Repo Become 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 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, New-N. It should be mentioned that GitHub will automatically create a new link and will redirect all the users to another link with a new username: github.com/username_New-N/repo_N. Sounds cool from your DevOps experience side!

However, 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 downloads 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. 

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 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, 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 an effective security strategy for your GitHub ecosystem, 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:

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.

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. 

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. 

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.

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.