Threat actors have been using GitHub‘s repojacking flaw to hijack and inject thousands of repositories with malicious code. This flaw has yet to be fixed, meaning 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 that has some similarities with 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. Whenever a repository owner changes their username, anyone can register the old username. 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 that have 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:
Clearly, 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 of the 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 has been tampered with. This means that vendoring only works if teams have the time and energy to closely monitor dependency updates.
Cybersecurity teams can also use version pinning to avoid GitHub repojacking.
Version pinning is the practice of 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, which instructs package managers to only download a specific repo version. So even if that repo gets repojacked, a cybercriminal wouldn’t be able to alter the code without changing the commit hash.
A lock file is made by a package manager that lists out version-pinned dependencies. It forces users trying to build that 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 also comply with stringent security standards, such as Common Weakness Enumeration (CWE) and Open Web Application Security Project (OWASP). This means IT teams don’t have to worry about compliance every time they update 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:
– The ability to detect and fix a broad range of vulnerabilities, including repojacking, cross-site request forgery, format string vulnerability, directory indexing, return pointer to local, and application misconfigurations
– Tailored reports and automatic action plans for remediating security gaps and managing technical debt
– The ability to customize the importance of different vulnerabilities
– An Action Plan dashboard to track progress towards goals and avoid deviations
– Full compliance with leading information technology (IT) standards, including OWASP, CWE, PCI, and NIST
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.
