GitHub repojacking attack: 10 lessons for software teams – Security Boulevard

The Home of the Security Bloggers Network
Home » Security Bloggers Network » GitHub repojacking attack: 10 lessons for software teams
Software supply chain attacks are on the rise because of their reach. Here are 10 valuable lessons from the recent GitHub namespace attack.
Hijacking code repositories, or repojacking, wasn’t new when security researchers discovered a serious vulnerability in the mechanism GitHub uses to retire namespaces, but the flaw in the development hub made the software community painfully aware of how defenseless it could be in the face of such software supply chain attacks.
Repojacking targets a legitimate namespace in GitHub. The architecture of the hub allows user names to be changed through a renaming feature. After a change, traffic to the old name is redirected to the new name. The flaw discovered by security firm Checkmarx in October could allow adversaries to use the feature to send users of renamed repositories to malicious destinations and put at risk thousands of software packages.
GitHub is the most popular code hosting platform in the world, with 90 million users and 330 million projects — putting a target on its back, said Om Vyas, chief product officer and co-founder of Oak9, a cloud-native infrastructure security provider.
“GitHub, being a central repository for developers to host their open-source software for others to consume, is a prime target to spread malware at an exponential rate.”
Om Vyas
Naomi Buckwalter, product security director at Contrast Security, said that if a threat actor can discover and exploit a vulnerability in a popular project, which also happens to be used in hundreds and thousands of applications around the world, then chances are that it’d be much, much easier to successfully attack multiple organizations at once.
“This is a huge return on investment for threat actors. Hack once, pwn everywhere. Hijack just one popular Github repository, and you can have a backdoor into multiple organizations. What threat actor wouldn’t like to try that?”
Naomi Buckwalter
Now that the dust has settled around the GitHub namespace flaw, here are 10 valuable lessons for software development teams.
Using open-source software is now standard operating procedure on most, if not all, modern development teams, Buckwalter said. “A single vulnerability in a popular open-source library can cause havoc. Just look at the fallout from Log4Shell.”
Henrik Plate, a security researcher at the dependency management company Endor Labs, said monitoring open source is key. “Rather than relying on automated redirects—and related protection mechanismsto work properly, you should update those resource references to the new locations,” Plate said.
Melissa Bischoping, director and endpoint security research specialist at Tanium, said auditing was paramount. “Avoid pulling code ‘live’ from sources such as GitHub repos that you don’t control and audit. Otherwise, it’s impossible to conduct proper security reviews on every single change,” said Bischoping.
Use SBOMs to give you insight into dependencies and risks, Bischoping suggested. “While we hope to see more software providers offering clear and transparent documentation of their dependencies and libraries, SBOM serves as an essential tool to empower the users of third-party software 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. “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,” Mackey said.
Mackey said ownership and management of repos is key. “That 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.
Mackey said that anyone choosing a new project shouldn’t be looking at the historical popularity of a project, but instead for evidence that the project is actively maintained and is healthy. Healthy projects can be determined by the project’s GitHub Insights and its Code Contributors and Code Frequency data. 
“If the project is popular, and there is limited activity or activity is limited to a handful of contributors, then that project isn’t as healthy as its popularity might indicate,” said Mackey. “Unhealthy, but popular, projects are precisely the types of projects that attackers will gravitate towards, as unauthorized changes to the code or configuration are more likely to fly under the radar screen for an extended period of time,” he added.
Buckwalter noted that asset management comes down to three things: Knowing what open-source libraries are currently used in your environment, their true source locations, and their known vulnerabilities.
“There is a saying in information security: ‘You can’t protect what you don’t know about,’” Buckwalter said. “The same holds true for supply chain attacks via Github. Keep an accurate asset inventory of your open-source libraries and make sure they always point to their true source locations — not the location that’s been redirected — and keep the libraries themselves up-to-date.”
Software supply chain attacks have become a never-ending story, said Scott Gerlach, co-founder and CSO of StackHawk, an API security testing provider.
“All of the light being shined on the issue should drive developers to actively check in on the public packages and repos they use,” Gerlach said. “But that’s the problem. Repos and package services like npm, composer and PyPi, are run by volunteers in their free time. If we really expect these widely-used resources to become more secure, people will have to start contributing more time and money into maintaining them.”
John Campbell, director of content engineering at Security Journey, an application security education firm, said security must be muscle-memory to developers and those who support the software development lifecycle (SDLC).
“Security education fills the gaps in higher education programs for many professional software developers,” Campbell said. “A solid, ongoing secure code training program establishes security principles that developers can rely on to make good, proactive decisions and provide prescriptive actions to improve the organization’s security posture.”
By understanding security principles, developers can implement supply chains and build pipelines that are protected against attacks, Campbell said.
“We can reduce the attack surface by implementing processes that maintain software components by pinning them to specific component versions, while using private vendors to control them and avoiding direct links to repos like Github.”
John Campbell

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by John P. Mello Jr.. Read the original post at:
More Webinars
Security Boulevard Logo White



Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top

Adblock Detected

Please consider supporting us by disabling your ad blocker

Refresh Page