Beyond SolarWinds: The “Octopus Scanner” Supply Chain Attack

Introduction

The SolarWinds exploit and subsequent breaches unfolding appears to be an incredibly sophisticated supply chain attack. Not only was SolarWinds possibly attacked through its supply chain, SolarWinds was used as a vector to distribute malicious backdoors through SolarWinds’ Orion product updates as part of SolarWinds’ customers’ supply chains. 

While this type of attack has been rare historically, supply chain attacks are on the rise. This is the first post of a series on Supply chain attacks – How and when various supply chain attacks have been executed and what we can learn from them.   

As directly attacking applications has become more difficult, attackers have turned their attention to indirect attacks that target their victims’ supply chain. In other words, many attackers now attack the tools that are used to build products and services rather than the product or services themselves.

Octopus Scanner

The Octopus Scanner, a new and especially insidious type of attack, was detected in March of 2020 when GitHub’s Security Incident Response Team (SIRT) was alerted to strange behavior coming from several customers’ source code repositories.1  As many as 26 GitHub repositories were infected by this attack. Any developer who downloaded a project from an infected repository, activated the malware in their own systems.

Octopus focused not on attacking a product, but attacking the tools products are created with, which in this case was Netbeans, a Java integrated development environment (IDE), used in developer systems.

Once in Netbeans’ directory, the malware then identified all projects associated with that IDE.  Next, it copied its payload from its own cache.dat file and inserted it into the cache.dat file, nbproject/cache.dat, belonging to the IDE to, ensuring any new Java classes and JAR files created in the IDE would include a dropper, serving as a back door. This was done by modifying the nbproject/build-impl.xml file to make sure the malicious payload is executed every time NetBeans project is built. When the infected classes in the compromised build were executed by a user’s local system, that system was then itself infected. 

The dropper created a remote access trojan (RAT) that established a network connection to the attacker’s own command and control (C2) servers.  The malware authors were even sophisticated enough to include a mechanism that ensured that no future builds could inadvertently replace the malicious code.

The following diagram illustrates the malware flow:

Conclusion

If up till now, the most common software supply chain attacks were about hijacking credentials or typosquatting popular packages.However, the “Octopus scanner” malware does it from a different angle, attacking the build environment and its artifacts to spread quickly. 

In some respects the software development industry dodged a bullet with the Octopus scanner. Imagine how much more damage could have been done if a more widely deployed IDE such as Make or Gradle had been the attack vector! 

As we’ve seen with SolarWinds, supply chain attacks are getting more sophisticated and we need to assume that tools within our own supply chains will be compromised at some point. With that in mind, we all need to be aware of this concerning trend. AppSec and DevOps team focus needs to be directed also to the development infrastructure, tools that developers are using, and the integrity of the software supply chain.

Specifically, we recommend focusing on the following areas to reduce supply chain risk within your DevOps pipeline: 

1. Harden your development & build environment – 
   1. Least privilege model making sure that only those who need access, have access
   2. Use strong authentication (MFA, SAML SSO, IP restrictions, etc.)
   3. Build pipeline must not be publicly accessible.
2. Enforce secure Development best practices
   1. Have commit signing as a mandatory configuration.
   2. Make sure static code scanning and open source scanning are enabled across your repositories.
   3. Search for repositories for hard-coded secrets earlier in the development stage prior to the build or deployment to production stages.
3. Ensure code is signed in development and validated in build and production environments to prevent tampering.

How Cycode Can Help

Crises are a time for the community to come together. As such, Cycode is offering a free code repository security assessment to any organization that is looking to harden their development infrastructure. Alternatively, if there is some other way we can help your organization, please get in touch with us.