Tech Support
Documentation
Login
Contact Us
Supply Chain Attack Inception
Joao Correia
September 26, 2023 - Technical Evangelist
There are many forms of supply chain attacks – repository hacking, developer initiated attacks, library tampering, domain hijacking, the list goes on – but an attack where the malware deliberately looks for your development software and infects other projects on your system during the build is something different.
While this is not a recent event, it showcases perfectly the advanced nature and innovation that goes into preparing attacks like these. The following story is based on a report created by the GitHub security team, available here. It happened in early 2020, but it is just as interesting today as it was then because of the unexpected twists and turns that the malware goes through to infect other unrelated pieces of software.
The Disguised Threat in the Open Source Ecosystem
GitHub’s Security Incident Response Team (SIRT) was alerted about repositories unknowingly serving malware-infected open-source projects. The malware, aptly named the “Octopus Scanner,” was uniquely designed to target and backdoor NetBeans projects. It used the build process and its resulting artifacts to propagate itself.
Let’s boil this down a bit. When you cloned and built the code contained in one of those infected repositories, the malware would actively search for installed NetBeans installations (NetBeans is a Java IDE, Integrated Development Environment). If found, it would integrate itself into the build process of any other project built inside NetBeans, so that it would include itself (the malware) inside of any build software. Since NetBeans is a developer tool, if found, it would naturally be used to write code for and build multiple different Java applications – which would each now include the malware.
This discovery was alarming not just because of the malware’s existence, but because of its potential reach. The repositories affected were open source, meaning any developer or organization could unknowingly clone the infected code and inadvertently introduce vulnerabilities into their applications or systems.
But how does this concern Java developers?
The Underlying Message: The Need for a Secure Supply Chain
As a Java developer, you might wonder how to ensure that the libraries and dependencies you use are safe. The Octopus Scanner incident underscores the importance of securing the open-source supply chain. It’s not just about patching the latest CVEs. It’s about maintaining the integrity of the entire software development and delivery ecosystem.
Enter SecureChain for Java. Imagine a service where every Java dependency and library you need has been vetted and scanned for vulnerabilities. No more second-guessing or sifting through forums to determine if a library is safe to use. Securechain for Java offers a curated repository for Java dependencies, ensuring that you’re only using libraries free from backdoors or known vulnerabilities.
Octopus Scanner: A Closer Look
The Octopus Scanner’s operation was multi-faceted:
- Identification & Infection: The malware identified the user’s NetBeans directory, enumerated all the projects, and then embedded a malicious payload in project files and build JAR files.
- Persistence: The malicious payload ensured that every time a NetBeans project was built, it would get executed, further ensuring the malware’s propagation.
- Subtlety: Unlike other malware, the repository owners were completely unaware they were committing backdoored code, making detection and mitigation even trickier.
- Flexibility: When executing, it would drop both payload and command and control software components into JAR files of other applications. This allowed for great diversification and adaptability by the malware operators, as they could change what was being deployed to infected systems should any countermeasures be deployed.
Because it was highly targeted, going specifically after Java developers, if NetBeans was not found, it would do nothing on the infected system. Unlike many other forms of malware and cyber attacks, which sometimes go for the most amount of possible targets in hopes that a small percentage of intended victims falls in the trap (like ransomware or email phishing), supply chain attacks hit end users before they even have a chance to do something about it. If the software you install is already backdoored, then no amount of security tools is going to protect you.
Rising to the Challenge
GitHub’s proactive approach in handling the Octopus Scanner incident, combined with the tools they offer for detecting vulnerabilities in dependencies, sets a benchmark for how open-source platforms should operate. Still, individual developers and organizations must also play their part by ensuring they use trusted sources for their code dependencies.
As the line between a genuine library and a backdoor becomes increasingly blurred, the need for a service like SecureChain for Java becomes paramount. It’s not just about writing efficient code; it’s about writing safe code.
Final Thoughts
The Octopus Scanner incident is a great example of the vulnerabilities present in the open-source ecosystem. It also shows how varied and advanced these attacks can be. While platforms like GitHub are doing their part, it’s up to developers to ensure they’re sourcing their dependencies from trusted, vetted sources.
With SecureChain for Java, you can confidently build your Java applications knowing that every library and dependency you use is free from vulnerabilities. In a world where code is shared freely, let’s make sure what we share is secure.
Secure your Java projects. Trust in SecureChain for Java.
