Threat actors have been using GitHub‘s repojacking flaw to hijack and inject thousands of repositories with malicious code. Since this flaw has yet to be fixed, GitHub users will likely see more of these attacks soon.
Luckily, there are ways to prevent cybercriminals from taking advantage of this software security gap. Read on to learn more about GitHub’s repojacking vulnerability and what steps organizations can take to protect GitHub repositories from repojacking.
Also known as dependency repository hijacking, repojacking is an obscure supply chain and data security gap similar to subdomain takeover.
There are three ways repojacking can happen:
1. A GitHub user renames their account: This is the most common way a GitHub repository becomes hijackable. Anyone can register the old username whenever a repository owner changes it. Threat actors can register the old GitHub name, repopulate the repository, and use it to inject malicious code into any project that depends on it.
2. A GitHub user transfers their repository to another user and deletes their account. A redirect is created after the user transfers the repository. Once the user deletes their account, anyone can hijack the account.
3. A GitHub user deletes their account. This is the least damaging of the three. When the original user deletes their account, any project or dependency that references it will have errors when fetching the repository.
Repojacking is extremely dangerous, especially if attackers compromise popular packages with millions of downloads. Many programming languages, frameworks, software, crypto wallets, apps, and games pull packages’ code directly from version control systems like GitHub. They also use GitHub repository URLs as pointers for packages.
Impacted projects, languages, frameworks, and software include:
GitHub repojacking is widespread and impactful. Fortunately, there are ways for companies to protect their software supply chains.
First, organizations should avoid linking to GitHub repositories. GitHub repositories were — and should never be — substitute package managers. Instead, teams should use dedicated package managers, which are more secure, usable, and static.
However, this isn’t a surefire way to avoid repojacking. Users may still be vulnerable to repojacking if one of their dependencies directly links to a GitHub repository URL. Even if none of the dependencies appear to have GitHub links, some transitive dependencies may have hidden GitHub repository links.
Another way to prevent repojacking is through vendoring, which is downloading all dependencies beforehand and including them in the repository. Since all dependencies are downloaded, organizations don’t have to link to potentially corrupted GitHub repos.
Unfortunately, users can still get repojacked if they update their dependencies and one of them is tampered with. This means that vendoring only works if teams have the time and energy to monitor dependency updates closely.
Cybersecurity teams can also use version pinning to avoid GitHub repojacking.
Version pinning is tying a specific, safe version of a software or framework with a dependency to prevent package installers from installing other versions. In the GitHub repo context, version pinning usually involves a SHA1 hash, instructing package managers to only download a specific repo version. So even if that repo gets repojacked, a cybercriminal couldn’t alter the code without changing the commit hash.
A lock file is a file created by a package manager that lists version-pinned dependencies. It forces users trying to build a project to download the same version and package specified in the lock file. However, experienced hackers can bypass most major package managers’ lock files and version pinning.
Adopting cutting-edge application security tools is the only reliable way to prevent repojacking. Unlike the methods mentioned above, application security platforms:
The best application security tools comply with stringent security standards, such as Common Weakness Enumeration (CWE) and Open Web Application Security Project (OWASP). IT teams don’t have to worry about compliance when updating their codebase.
To defend themselves from repojacking, data breaches, and other cybersecurity risks, organizations should consider getting Kiuwan’s Code Security (SAST). As the best enterprise-level security solution, Code Security automatically scans codebases to spot and fix code vulnerabilities that threat actors can exploit. Powerful, reliable, and easy-to-use, Code Security integrates straight into the DevOps environment. It also offers:
Interested in learning more about Kiuwan? Sign up for a Code Security demo today. Kiuwan’s expert team will demonstrate how easy it is to initiate a scan, navigate the seamless user interface, create a remediation action plan, and manage code risks.
