GitHub Flaw Underscores Risks of Open Source, RepoJacking

A GitHub vulnerability was recently discovered that lets attackers seize control of a GitHub repository and infect all the applications and code that depend on it with malicious code. This vulnerability is a wake-up call for those who rely on open source packages, which are now at risk.

“This is not much different than the other supply chain issues we’ve seen historically. It’s becoming a common attack vector, and it is going to require that companies that are leveraging open source software repositories exercise extra care to ensure they understand not only what they are deploying, but that they are inventorying this in a software bill of materials (SBOM) that will allow them to more readily identify and remediate when malicious or suspicious payloads have been identified,“ said Jim Kelly, RVP, endpoint security at Tanium.

AWS Builder Community Hub

“If not explicitly tended, all renamed usernames on GitHub were vulnerable to this flaw, including over 10,000 packages on the Go, Swift and Packagist package managers. This means that thousands of packages could have been hijacked immediately and started serving malicious code to millions of users,” according to a blog post penned by researchers from the Checkmarx supply chain security (SCS) team that discovered the vulnerability.

Because GittHub repositories are linked to usernames, when users renamed their accounts, GitHub supports the rename, posts a warning and redirects traffic from the previous repository’s URL to the new one. To keep things operating for users unaware of this username change, Checkmarx said, redirect rules are automatically set up from the old repository URLs to the new URLs.

“A GitHub repository is vulnerable to RepoJacking when its creator decided to rename his username while the old username is available for registration,” the researchers wrote.

“We have shown the coupling in the repository URLs between the repository name and the creator username, and this means attackers can create a new GitHub account having the same combination to match the old repository URL used by existing users,” they said. “Whenever attackers do this, the default redirect is disabled, and all existing traffic is immediately routed to the attacker’s malicious GitHub repository.”

GitHub took measures to protect against that kind of harmful behavior by including a ‘popular repository namespace retirement’ protection measure: Any repository with more than 100 clones at the time its user account is renamed is considered “retired” and cannot be used by others,” Checkmarx pointed out.

But that also was found to be vulnerable and “remains an attractive attack point for supply chain attackers in the future,” they said, noting “this isn’t the first vulnerability found in this mechanism; earlier this year, an attacker used a similar vulnerability to hijack and poison popular PHP packages with millions of downloads.”

“Thousands of projects with millions of end users rely on open source libraries and code repositories, which makes the repositories a very attractive target for threat actors,” said Mike Parkin, senior technical engineer at Vulcan Cyber.

“If they can take control of the repository and insert malicious code into a trusted and widely used project, they can potentially infect tens of thousands to potentially millions of hosts with little additional effort,” said Parkin. “This is especially true for older projects that may still be widely used but are not as actively maintained, as there are fewer eyes on the code so a malicious insertion could go unnoticed.”

This latest vulnerability, which GitHub has fixed, should underscore that companies should take extensive security measures when using open source. “The prevalence of open source solutions such as shared libraries, dependencies and integrations across enterprise tooling as well as custom-built projects can lead to RepoJacking attacks such as these, which could scale, rapidly if successful,” said Melissa Bischoping, director, endpoint security research, at Tanium.

“It’s important to understand that any GitHub attack first starts with compromising a GitHub account. Enabling two-factor authentication or the use of the GitHub Mobile registration are two key options to reduce the potential for any GitHub account to be compromised,” said Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center.

“The next step is for GitHub users to clearly define an end-of-life or transition plan for each repo that they are responsible for. This includes having trusted individuals as owners or group accounts and defining a GitHub successor–in addition to publishing explicit end-of-life or deprecation statements,” said Mackey. “Of course, responsibility for the overall life cycle of any open source project includes the consumers of that code, so anyone choosing any new project shouldn’t be looking at the historical popularity of the project, but instead should be looking for evidence that the project is actively maintained and is healthy.”

To gauge the health of a project, organizations should go by “the project’s GitHub Insights and look at the Code Contributors and Code Frequency data. If the project is popular and there is limited activity or the activity is limited to a handful of contributors, then that project isn’t as healthy as its popularity might indicate,” Mackey advised.

“Unhealthy but popular projects are precisely the types of projects that attackers will gravitate toward as unauthorized changes to the code or configuration are more likely to fly under the radar for an extended period of time,” he said. “Ultimately, if an attacker wishes to take over an account, they’re in control of their methods and objectives. They could simply take over the account, or they could rename it during a takeover. Either way, what the code is doing becomes suspect and it’s up to the consumer of that code to validate that what they have is what they expect to have.”

That’s something Bischoping agreed with. “If developing software, it is essential to audit the code in those repositories, as well as create your own private fork to work (as opposed to pulling from the current public repository),” she said. “Avoid pulling code ‘live’ from sources such as GitHub repos that you don’t control and audit. Otherwise, it’s impossible to conduct a proper security review on every single change.”

Consumers of a third-party product should “keep an accurate inventory via software bill of materials (SBOM) solutions to have insight into dependencies and risks,” said Bischoping.  “While we hope to see more software providers offer clear and transparent documentation of their dependencies and libraries, SBOM serves as an essential tool to empower you to understand if and when these vulnerabilities impact you.”


Avatar photo

Teri Robinson

From the time she was 10 years old and her father gave her an electric typewriter for Christmas, Teri Robinson knew she wanted to be a writer. What she didn’t know is how the path from graduate school at LSU, where she earned a Masters degree in Journalism, would lead her on a decades-long journey from her native Louisiana to Washington, D.C. and eventually to New York City where she established a thriving practice as a writer, editor, content specialist and consultant, covering cybersecurity, business and technology, finance, regulatory, policy and customer service, among other topics; contributed to a book on the first year of motherhood; penned award-winning screenplays; and filmed a series of short movies. Most recently, as the executive editor of SC Media, Teri helped transform a 30-year-old, well-respected brand into a digital powerhouse that delivers thought leadership, high-impact journalism and the most relevant, actionable information to an audience of cybersecurity professionals, policymakers and practitioners.

teri-robinson has 185 posts and counting.See all posts by teri-robinson