Open Source Code: Trojan Horse for Attacks?

On June 2, it was revealed that the 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 create applications from modular components, and executes a remote access trojan (RAT) to gain full control of the target’s machine. By infecting developers’ tools, the malware can rapidly escalate access to any additional projects, production environments and password databases the developer has access to.

This attack is hardly the first to target the software supply chain. In April, more than 700 libraries of Ruby code hosted on RubyGems, the popular code repository and package manager, were found to contain malicious cryptojacking software. Crypto jacking attacks such as this one hijack the computational resources of the target (in this case the application running 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 illicit cryptomining software.

These attacks via 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 in their application. It serves the same function as the original code but also performs extra activities, including cryptomining, data exfiltration and denial-of-service attacks.

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

Of course, there are source code scanners designed to catch malicious code in the software supply chain. But these tools won’t detect malicious code until the source code profile is identified and added to their databases. And because attacks such as cryptojacking work in the background, it could take weeks or even months before the bad code is discovered.

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

If source code scanning is the bouncer at the club, then workload runtime security monitoring is the security guard watching for suspicious activity from the inside. It will detect when a container attempts to communicate with one or more blacklisted sites, block the attempt and alert security teams. The response owner can then quickly triage the security issue, working with the engineering team to review the changes that introduced the malicious activity and removing the offending code libraries.

Runtime monitoring works together with network segmentation. In Kubernetes, network segmentation policies enable security teams to set fine-grained rules on which microservices and resources that containers are allowed to communicate with. Kubernetes’ native network policies are great for segmentation of 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 communication both within and outside the cluster, such as communication with a crypto mining location or a data exfiltration attack.

Keep in mind that runtime monitoring and source code scanning look for threats from two different angles. Source code scanning and other component analysis tools look at our application code at build time, whereas workload runtime security looks at our application while they are running. These capabilities are complementary and help to establish a wide security net. Combining both measures enables a multilayered defense against supply chain attacks.

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

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

Featured eBook
Managing the AppSec Toolstack

Managing the AppSec Toolstack

The best cybersecurity defense is always applied in layers—if one line of defense fails, the next should be able to thwart an attack, and so on. Now that DevOps teams are taking  more responsibility for application security by embracing DevSecOps processes, that same philosophy applies to security controls. The challenge many organizations are facing now ... Read More
Security Boulevard

Gadi Naor

Gadi Naor, CTO and co-founder of Alcide, has over 15 years experience in leading and developing some of the key cyber security products used in data centers today.

gadi-naor has 1 posts and counting.See all posts by gadi-naor