Open Source Code: Trojan Horse for Attacks?


On June 2, it was revealed that Octopus Scanner malware had infected at least 26 open source code repositories on GitHub. Once downloaded, the malware specifically targets the Apache NetBeans Java Integrated Development Environment (IDE), which is used to build applications from modular components, and runs a Remote Access Trojan (RAT) to obtain full control of the target machine. By infecting developer tools, malware can quickly escalate access to any projects, production environments, and additional password databases the developer has access to.

This attack is not the first to target the software supply chain. In April, more than 700 Ruby code libraries hosted on RubyGems, the popular code repository and package manager, were found to contain malicious cryptojacking software. Crypto jacking attacks such as this hijack the target’s computational resources (in this case, the application executing the malicious code) to mine cryptocurrency for the hacker without the target’s consent. A similar attack reported last year also exposed thousands of RubyGems users to malicious cryptomining software.

These attacks through the software supply chain work like a Trojan horse. Hackers modify popular open source software, add their malicious code, and publish the code library with an almost identical name. Unsuspecting developers then import and integrate the infected code into their application. It performs the same function as the original code, but also performs additional activities including cryptomining, data exfiltration, and denial of service attacks.

The problem is undoubtedly much broader than the Octopus Scanner and RubyGems crypto jacking attacks. Over 57% of the code in commercial applications comes from open source libraries, giving attackers ample opportunity to smuggle their code into applications through the software supply chain.

Of course, there are source code scanners designed to detect malicious code in the software supply chain. But these tools will not detect malicious code until the source code profile is identified and added to their databases. And because attacks like cryptojacking run in the background, it can take weeks or even months for the wrong code to be discovered.

By the time source code scanners detect malicious code, it is often far too late. Containers may have already been built and deployed with infected code and may be running in production environments. That’s why it’s important for builders and operators of cloud native applications to strengthen the depth of their defenses through workload execution security monitoring and network segmentation.

If the source code analysis is the club’s bouncer, then the workload execution security monitor is the security guard who watches for suspicious activity from within. It will detect when a container tries to communicate with one or more blacklisted sites, block the attempt and alert security teams. The owner of the response can then quickly sort out the security issue, working with the engineering team to examine the changes that introduced the malicious activity and remove the offending code libraries.

Execution monitoring works with network segmentation. In Kubernetes, network segmentation policies allow security teams to set precise rules about which microservices and resources containers are allowed to communicate with. Kubernetes native network policies are ideal for segmenting east-west traffic (within the cluster) but are quite limited and, in many cases, irrelevant for segmentation of cluster egress routes. For advanced network security, runtime security monitoring is required to detect unauthorized communications both inside and outside the cluster, such as communicating with a crypto mining location or a data exfiltration attack.

Keep in mind that execution monitoring and source code analysis looks for threats from two different angles. Source code analysis and other component analysis tools examine our application code at build time, while workload runtime security examines our application while it is running. These capacities are complementary and help to establish a broad safety net. The combination of the two measures enables a multi-layered defense against supply chain attacks.

The decision to use one, the other, or both really boils down to a team’s budget, prioritization of risk management, and the ability to leverage the insights highlighted by management tools. security. But to comprehensively manage the risks associated with production environments, runtime security monitoring is essential.

The more cloud-native developers rely on open source code, the more hackers will want to exploit it. Now is the time to take a closer look at the software supply chain and implement robust security measures to keep hackers out.


Leave A Reply