Malware in GitHub-hosted projects crafted to spread to open-source devs

Twenty-six open-source projects hosted on GitHub repositories were found to be infected with malware and capable of serving up weaponized code to potential developers in a potential supply chain attack, the GitHub Security Lab has disclosed.

An investigation into the incident turned up what GitHub described as a first: “malware designed to enumerate and backdoor NetBeans projects, and which uses the build process and its resulting artifacts to spread itself.” NetBeans is an integrated development environment (IDE) for the Java programming language.

A more typical software supply chain attack might involve stealing a developer’s credentials or typosquatting popular package names, but this latest attack is notable because, from an open-source perspective, “it gives the malware an effective means of transmission since the affected projects will presumably get cloned, forked and used on potentially many different systems,” explains GitHub staff security researcher Alvaro Muñoz in a company blog post. “The actual artifacts of these builds may spread even further in a way that is disconnected from the original build process and harder to track down after the fact.”

GitHub says that it first learned of the affected repositories on March 9 from the security researcher “JJ.” The keepers of the affected repositories were likely not aware that the open-source NetBeans projects within were potentially dispensing malware to additional users who may have cloned and further built upon these projects, Muñoz notes. This presented a challenge for GitHub, as it looked for ways to expediently remove the malware — dubbed Octopus Scanner — without entirely shutting down the impacted user accounts.

When the malware identifies a NetBeans directory within a particular repository, it embeds a payload in the project files located within. But the malware also infects JAR files — including dependencies — with a dropper that maintains persistence and communicates with C2 servers via a remote administration tool, Muñoz states in the blog post. Additionally, the malware attempts to stop any new project builds from overwriting the malicious build.

From there, additional GitHub users can become infected if they build from an infected repository or if they use any of the weaponized artifacts that stem from a compromised build. This means that attacks could over time gain access to a multiple of open-source developers’ projects, production environments and more, GitHub notes.

“There is a huge potential for escalation of access, which is a core attacker objective in most cases,” writes Muñoz.

“This is a good example of how malicious packages tend to make headlines even when their impact was relatively small,” said Rhys Arkins, director of product management at open-source security and license compliance management platform WhiteSource. “Such cases are intimidating because most developers know it could have happened to them, and it could have been much worse.” However, Arkins noted that developers must not allow such malware incidents to distract them from more ubiquitous, known threats such as open-source vulnerabilities that require “much less effort for an attacker to exploit.”

Comments are closed.