GitHub resolves flaw allowing attacker to take over repository, infect all applications

GitHub has addressed a vulnerability allowing attackers to take control of one of its repositories and potentially infect all applications and other code relying on it.

Researchers from security company Checkmarx approached the platform on June 13 and GitHub acknowledged the issue, classified it as “high” severity and paid them an undisclosed bug bounty. GitHub did not respond to requests for comment but Checkmarx said they worked with the platform to address the bug.

The issue centers around the “Popular repository namespace retirement” feature of GitHub. Thousands of GitHub users – including those in control of popular repositories and packages – opt to change their user names, leaving namespaces including their old user names open to exploitation.

The vulnerability, according to Checkmarx, left numerous packages susceptible to being hijacked to serve malicious code to millions of users and many applications.

Aviad Gershon, security researcher at Checkmarx, told The Record that attempts to exploit the namespace retirement feature remain attractive attack points for supply chain hackers.

“This vulnerability hits one of the links in the supply chain. Once this chain is compromised, we can expect incidents as big as the SolarWinds incident and bigger," Gershon said. 

“This can possibly lead to infection of millions of end users with malicious code ranging from information stealers to cryptominers and practically anything else the attacker decides to employ. An even more worrying possibility is malicious code inside healthcare or energy equipment for example.”

Gershon explained that their research into the issue began when their chief architect, Elad Rapoport, found the first bypass related to this issue late last year. The problem was fixed in May 2022 but not before it was abused. Rapoport began to dig for similar ways of bypassing this same protection.

Several package managers pull the code for their packages directly from GitHub, according to Gershon, who added that if an attacker were able to take control of a popular repository containing the code for a popular package, they could add their own code into it. 

“It is not a rare thing that an open-source package becomes one of the building blocks for a widely used application, which in this scenario will be poisoned as well,” Gershon told The Record. 

He cited a "similar" vulnerability used to hijack and infect two popular PHP packages in May, one of which had been downloaded more than 2.5 million times at the time of the breach.

"In this case the attacker (who later claimed he is a security researcher) tried to steal sensitive information from the victims. So, this is a totally realistic scenario and a real-world risk,” Gershon said.

Repojacking

In their report on the issue, Checkmarx researchers said threat actors could exploit the issue using the “Repojacking” technique – where an attacker hijacks a legitimate, often popular, namespace on GitHub.

The typical namespace on GitHub is the combination of the username and repository name. An example would be: example-user/example-repo. 

“A namespace is vulnerable to Repojacking in case the original name of the user was changed using the ‘user rename’ feature GitHub offers,” the researchers explained. “The change of username process is quick and straightforward. A warning lets you know that all traffic for the old repository's URL will be redirected to the new one.”

Once you change your username, your old username is available for anyone to claim. An attacker can open a repository under the matching name, and hijack the namespace.

To address the issue, GitHub created a feature where any repository that meets a certain criteria is considered “retired” and cannot be used by others.

Checkmarx said all renamed usernames on GitHub were vulnerable to this flaw, including over 10,000 packages on the Go, Swift, and Packagist package managers. 

While the issue has been fixed, Checkmarx recommended that GitHub users avoid using retired namespaces to minimize the attack surface because “other vulnerabilities in this mechanism may still exist.”

Despite their work with the company on the issue, their report on the bug said the protection provided by the platform to address the issue “is activated based on internal metrics and gives the users no indication if a particular namespace is protected by it or not.” 

This may leave some repositories and packages unknowingly at risk, according to the researchers. 

Several cybersecurity experts confirmed Checkmarx’s findings and said the vulnerability was significant because thousands of tools rely on open source libraries and code repositories – making attacks on them potentially catastrophic. 

Synopsys security strategist Tim Mackey said that GitHub users need to clearly define an end-of-life or transition plan for each repository that they are responsible for – which includes having trusted individuals as owners, or group accounts, and defining a GitHub successor. Users should also publish explicit end-of-life or deprecation statements. 

“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,” he said.  

Melissa Bischoping, director of endpoint security research at Tanium, echoed that point, saying issues like this are why people should avoid pulling code “live” from sources such as GitHub repositories that you don’t control and audit, she added. 

Another Tanium executive, Jim Kelly, said the problem is not much different from other supply chain issues they’ve seen historically, while Inversion6 CTO Christopher Prewitt compared it to DNS domain name takeover. 

Kelly said such attacks are becoming common vectors and will eventually require that companies using open source software repositories exercise extra care to ensure they understand what they are deploying, including inventorying using a “Software Bill of Materials” method. 

“Software Supply Chain and Software Composition will continue to be problems for years to come as software is more routinely assembled, rather than developed,” Prewitt explained.