Case Study

Continuing the series on software supply chain security is a review of a recent event, where a popular Node.js package was compromised. This event was not unique, as these sorts of attacks occur with relative frequency, however it provides a good example of how the traditional software development defense methods have gaps that may be exploited.

In this example, a commonly used Node.js package, rand-user-agent, was identified as having malware through automated scanning tools. At the point of identification the malicious versions of this software package had been live for some time, meaning any user using the latest “version” of the software now had active malware on their workstation or server.

Inspection

When this event was reviewed, the researchers found that the source code available in Github did not show any signs of the compromise or malicious code. Anybody running code scans to validate the application component to check the software dependency would not have seen any issues with the application.

In this case, researchers found new updates had been published to the Node Package Management (npm) web site that had not originated from the actual application source code. In other words, a malicious actor had created new releases of the software application with the malicious code and published these directly to npm.

Malicious Behavior

So with this compromised version of the module, what could happen? This module was simply designed to generate randomized user agent string values to be used when making web requests to servers. There are a number of reasons this may be useful, but the key is that the module was simply designed to generate a value and return it to the application for use. With this modification, the application would now:

• Install additional software components for networking and command execution
• Open a covert “command and control” connection to a remote server
• Allow the remote server to execute arbitrary commands on the machine
• Upload files to a second remote host
• Performed path manipulation to potentially compromise additional executed commands

Quite a difference between generating a string value and a full compromise of system data and arbitrary remote command execution!

Disrupted Supply Chain

This attack was orchestrated not by modifying the original source code to the plugin, which was untouched, but by compromising the authentication tokens used by the developer to publish artifacts to npm. This is a classic attack on an application supply chain where an intermediate process (publishing the artifact) was subverted and malware inserted, without the original author’s awareness or consent.

Mitigations

Unfortunately the ability to mitigate this sort of compromise is limited, as there is a push to upgrade to newer dependency versions to bring new features or to address other known vulnerabilities. A package or dependency being compromised in this manner, even for a short period, could easily impact thousands of software installations.

In this case, the scope of the damage can be limited through a limited runtime environment, both for filesystem and network access, so that even a malicious payload would be unable to access key data, or to communicate freely with external services. A secured enclave for running a software application can reduce the impacts of malicious code entering the environment, and with proper monitors, could provide a clear and early indicator of a new security threat. If an application is making new network requests ater an update, even if blocked, there is a clear possibility that new unexpected (possibly malicious) activity is occurring. A restricted runtime environment with proper monitoring can be an effective mitigation.

Even with this limitation however, the threat may still lead to additional compromises. A developer will generally run software on a machine or in a less restrictive test environment prior to release, and this backdoor would have been executed on these systems as well. With the command access and file stealing actions in this malware, it is possible that other credentials or sensitive files could be exfiltrated from these other environments, even if the production network was secured.

Next Steps

With this event serving as a concrete example of an effective software supply chain attack, the series will continue talking about software packaging and distribution in the next article, and continue on to looking at how to maintain awareness and accountability of software solutions. Security is not an absolute, but rather a goal, and securing the supply chain is an ongoing process on this path.