Malware abused the build process on GitHub
ANALYSIS GitHub has published an informative post-mortem of a real-world open source software supply chain attack.
NetBeans repositories on GitHub were used as a delivery point to serve the Octopus Scanner malware, a backdoor specifically designed to infect NetBeans projects.
As a result of the attack, the open source build process was compromised, and 26 open source projects were affected.
The attack went far deeper than the more commonplace problem of the GitHub platform being abused as part of a command and control (C2) infrastructure.
GitHub learnt of the security breach on March 9, via a tip off from an independent security researcher who warned that a set of GitHub-hosted repositories were actively serving malware.
Untangling the tentacles
Subsequent investigations confirmed that the Octopus Scanner malware was capable of cataloguing NetBeans project files before embedding malicious payload both in project files and build JAR files.
The affected repository owners were most likely completely unaware of the malicious activity, and sorting out the mess was a challenge because simply blocking or banning maintainers wasn’t a good option.
GitHub Security Lab had to work out how to properly remove the malware from infected repositories, without having to shut down user accounts.
A detailed technical analysis by GitHub’s Alvaro Muñoz explains how the security team, with no small amount of difficulty, accomplished this process.
RELATED GitHub showcases new code-scanning security tools at virtual event
Many questions about the attack remain – not least why the malware authors targeted NetBeans build process, a comparatively unfashionable Java IDE.
“If malware developers took the time to implement this malware specifically for NetBeans, it means that it could either be a targeted attack, or they may already have implemented the malware for build systems such as Make, MsBuild, Gradle and others as well and it may be spreading unnoticed,” said Muñoz.
“Even though the malware C2 servers didn’t seem to be active at the time of analysis, the affected repositories still posed a risk to GitHub users that could potentially clone and build these projects.”
Brian Fox, CTO at open source software security specialist Sonatype, commented that what makes Octopus Scanner so dangerous is that infects developer tools that subsequently infect all of the projects they are working on, impacting their team or community of open source users.
“The Octopus Scanner malware validates the importance of analysing binaries within your code and not taking the word of the manifest,” Fox said.
“What makes Octopus so dangerous is that it has the capability to infect other JAR files in the project, so a developer ends up using and distributing the mutated code to their team or community of open source users.
“We’ve seen over 20 one-off attempts at malicious code injection within OSS projects, but this is a new form of attack. This attack infects developer tools that subsequently infect all of the projects they are working on.”
Supply chain attack
In response to questions from The Daily Swig, Nico Waisman, head of GitHub Security Lab, explained that the “goal of the Octopus Scanner was to insert backdoors into artefacts built by NetBeans, so that the attacker could then use these resources as part of a command and control server”.
“There was no evidence that the 26 open source projects were actually targeted by the malware,” Waisman added.
“The malware’s primary goal was to infect a developer’s computer and spread through NetBeans projects. As a consequence of the developer’s infection, they unintentionally uploaded backdoored code to their repositories.”
Software dependencies are pervasive, so it’s become normal for projects to use hundreds or even thousands of open source dependencies. Attackers are taking advantage of this to craft attacks, Waisman warned.
“Although open source is easy for developers, it also means it’s easy for attackers,” Waisman said. “Attackers are pursuing supply chain compromises because they can have widespread reach. A single compromise vector gives them access to multiple targets.”
Check your system and dependencies
Although supply chain compromises like this are scary, they remain rare, Waisman concluded.
“The primary issue in supply chain security is unpatched software,” Waisman told The Daily Swig. “It’s much easier for an attacker to take advantage of an unpatched, known vulnerability in a dependency, than to insert a new vulnerability into your code.
“For a developer, the primary challenges are then knowing your dependencies, and knowing when they need to be patched. On GitHub, Dependency Graph helps you understand your project’s dependencies,” he concluded.
YOU MIGHT ALSO LIKE Open source tool searches for leaked secrets in GitHub commits
