Researchers on Wednesday reported they found a “high-severity” vulnerability in GitHub that could have let an attacker take control over a GitHub repository and potentially infect all applications and other code relying on it with malicious code.
In a blog post, researchers from the Checkmarx Supply Chain Security team said using a technique known as Repo Jacking, an attacker can take control of a GitHub repository by exploiting a logical “hidden” flaw in the architecture that makes renamed users susceptible to such an attack.
The researchers said all renamed usernames on GitHub were vulnerable to this flaw, including more than 10,000 packages on the Go, Swift, and Packagist package managers.
“The practical meaning of this is that thousands of packages can immediately be hijacked and start serving malicious code to millions of users and many applications,” wrote the researchers.
This vulnerability was fixed by GitHub following Checkmarx’s report and it’s no longer exploitable, say the researchers.
Constantly evolving cyberattack methodologies
Aviad Gershon, security researcher and team leader at Checkmarx, explained that earlier this year his team witnessed attackers using the Repo Jacking technique, which demonstrates how malicious actors will continually evolve their methodologies to find the simplest ways to leverage trusted open-source packages for maximum impact.
“The security community needs to be proactively working together to find and close these gaps before the attackers do,” said Gershon. “As time-to-delivery requirements relentlessly pressure AppSec and development teams, and as low-code development becomes more common, the potential attack surface for hidden malicious code like this will grow exponentially."
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. Parkin said if they can take control of a GitHub 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.
“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,” Parkin said. “The issue reported here [involving GitHub] is potentially severe, and there have been previous examples of repositories being hijacked to spread malicious code.”
Corrupting the open-source model attractive to bad actors
In research from Blackberry also released Wednesday, more than 80% of U.S. and North American organizations reported being notified of a vulnerability or attack affecting their software supply chain in the past year, though just 10% cited open source as the biggest impact on the security of their code.
As SC Media has reported, part of the issue is the sheer volume of open-source code powering the modern internet, with 98% of applications using them, according to a report from Synopsys. Dan Lorenc, CEO and co-founder of Chainguard, likened it to an iceberg, where a little bit of the internet is floating above the water, while the rest “is the massive amount of open source beneath.”
But further enticing cybercriminals is the open-source development model itself: the collaborative approach, defined by sharing and reuse of code. Sonatype found an average 700% jump in attacks against open source projected over the last three years, while the cybersecurity community learned firsthand about the implications of open-source vulnerabilities when a flaw in Log4j, the popular Java logging package distributed under the Apache software license, was exploited.
Checkmarx's Gershon said that before the GitHub vulnerability was fixed: "The ramifications regarding some package managers ... eventually could have ended up with millions of infected end-users poisoned with whichever malicious code the attackers could think of. Specifically for GitHub, this means that any vulnerable GitHub action could have also been poisoned by exploiting this vulnerability and infecting CI/CD pipelines running them.”
Melissa Bischoping, director, endpoint security research at Tanium, added that the prevalence of open-source software as shared libraries, dependencies and integrations across enterprise tooling and custom built projects can lead to Repo Jacking attacks such as these, which could scale, rapidly if successful.
Bischoping said when developing software, it’s essential for dev teams to audit the code in those repositories, as well as create their own private fork to work, as opposed to pulling from the current public repository. Bischoping advised security teams to avoid pulling code “live” from sources such as GitHub repos that they don’t control and audit.
“Otherwise, it’s impossible to conduct proper security reviews on every single change,” Bischoping said. “If you’re a consumer of a third-party product, keep an accurate inventory via software bill of materials (SBOM) solutions to have insight into dependencies and risks. While we hope to see more software providers offer clear and transparent documentation of their dependencies and libraries, SBOMs serve as an essential tool to empower security team to understand if and when these vulnerabilities impact them.”
Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, said it’s important to understand that any GitHub attack first starts with compromising a GitHub account. Mackey said enabling two-factor authentication or the use of the GitHub Mobile registration are two important ways to reduce the potential for any GitHub account to be compromised. The next step, said Mackey, 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,” Mackey said. “Of course, responsibility for the overall lifecycle 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.”
