Security news that informs and inspires

Malware Infects NetBeans Projects In Software Supply Chain Attack

The Octopus Scanner malware has compromised 26 open source projects hosted on GitHub in a new supply chain attack, GitHub Security Lab said.

The investigation began on March 9 when security researcher “JJ” notified GitHub’s Security Incident Response Team about GitHub repositories actively serving malware. The malware was designed to compromise NetBeans projects, and all affected projects were serving backdoored code, GitHub’s security researchers found. The project owners were unaware their projects had been compromised.

"The malware is capable of identifying the NetBeans project files and embedding malicious payload both in project files and build JAR files," JJ wrote.

The developer’s computer would be infected by Octopus Scanner after the developer forked or cloned a compromised repository, said GitHub security researcher Alvaro Muñoz in a blog post describing the investigation. The malware executed only on machines where the developer used the NetBeans IDE (a cross-platform integrated development environment used to write Java applications), and did nothing if no NetBeans projects could be found. The first thing the malware did on the machine was to look for the NetBeans directory in order to enumerate all the projects in that directory. The malware then changed the configuration file to ensure that the payload—a dropper—was injected into the resulting JAR binary every time a project was built.

Executing the resulting JAR file on the machine would give the malware “local system persistence” on the developer’s machine, and the dropper would install a remote access Trojan (RAT) to communicate with the command-and-control server to receive further instructions. The malware’s command-and-control servers were already unavailable by the time GitHub began its investigation, so the research team was unable to determine the type of tasks the attackers performed on the compromised developer machines.

By infecting NetBeans projects, the malware inserts backdoors into previously clean projects. The malware spreads when developers release the code, or commit the code to repositories and other developers pick up that code.

GitHub identified four samples of the malware during the course of its investigation. The initial version may have been submitted to VirusTotal back in August 2018, and was designed to “only spread through tainted repository cloning and building.” The later versions came with new features and capabilities, including the ability to “spread when any of the resulting build artifacts are loaded and used.”

Octopus Scanner prevented new builds from replacing the compromised one by keeping malicious build artifacts.

"Infecting build artifacts is a means to infect more hosts since the infected project will most likely get built by other systems and the build artifacts will probably be loaded and executed on other systems as well," Muñoz said.

By directly targeting developers, the attackers behind the Octopus Scanner malware could potentially access proprietary information, such as details about the projects the developers were working on, specifics about the production environments, and sensitive information such as database credentials. Once the developers committed the backdoored code into their repositories, the attackers would have access to critical systems within the organization.

The fact that the malware targeted NetBeans suggests this may have been a targeted attack against specific developers, since NetBeans is not really widely used among Java developers. Alternatively, the attackers may have already implemented the malware for more popular build systems such as Make, MsBuild, and Gradle, and was expanding the malware's footprint to include all other build systems.

"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," Muñoz said.

Supply chain attacks undermine the integrity of components used. A software supply chain introduces the malicious code by injecting it into the tools used to create the application. It also gives attackers wider reach, because anyone who uses the modified tool winds up helping the malware’s spread. A software supply chain attack affects the integrity of the entire software development and delivery ecosystem. If the integrity of any one of the steps is weakened, the entire ecosystem is affected.

Attackers have in the past introduced backdoors in compiled code by distributing a tampered version of Apple's XCode development environment, tampering with software updates, or directly hijacking the update utility itself. There have been many examples of attackers uploading a malicious library with a name similar to a well-known package to a package managers such as npm and pypi.

The method Octopus Scanner used to compromise the build process is “both interesting and concerning,” said Muñoz. It gives the malware an "effective means of transmission" since the affected projects will get cloned, forked, and used on many different systems. "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," he said.

However, software supply chain attacks tend to be rare. It is far easier for attackers to target unpatched vulnerabilities in software than to go after developer tools.