5 Ways Your Software Supply Chain is Out to Get You, Part 1: Vendor Compromise

Is 2021 the year of the software supply chain attack?

In late 2020, an incredible story broke: US government agencies, including Commerce, Treasury, and Homeland Security, had been severely compromised through a malicious backdoor surreptitiously implanted into network management software supplied by a trusted vendor, SolarWinds. Weeks later, tens of thousands of organizations were scrambling to deploy a set of emergency “zero-day” patches for Microsoft Exchange Server in an attempt to prevent another series of catastrophic compromises. A zero-day vulnerability is a previously unknown software bug or backdoor that malicious actors exploit to accomplish some malign purpose – stealing user credentials, accessing or altering data, installing Bitcoin miners, laterally moving to other servers in the infrastructure, etc.

As incredible as those events have been, software supply chain attacks are neither new nor surprising.

The US Department of Homeland Security had even established a joint public-private partnership to advise on Information and Communication Technology supply chain threats, two years before the SolarWinds hack was made public. The National Counterintelligence and Security Center (NCSC) even launched a campaign in 2019 designating April as the National Supply Chain Integrity Month to “raise awareness about growing threats to the supply chains of the private sector and U.S. Government, and to provide resources to help mitigate these risks.”

In fact, the evidence has been staring us in the face for the past two decades. As an example, the Mitre Corporation has maintained the Common Vulnerabilities and Exposures (CVE) system since 1999. Since its inception, there have been over 150,000 reported CVEs – zero-day vulnerabilities – in commonly used software applications and components. Of the 150,000 CVEs, more than 11,500 of them are of critical severity like the SolarWinds and Exchange Server vulnerabilities. And those CVEs are just the issues that have gone through the disclosure process (either intentionally via security researchers or unintentionally in the aftermath of a notable security breach), the vast majority of software vulnerabilities remain unreported.

The key lesson is that our software supply chain transfers an extraordinary amount of risk downstream to the organizations and users that depend upon it.

Criminals, hacktivists, state-sponsored espionage groups, and others with less honest intent, know this and use a number of common supply chain attack methods to take advantage of the trust we place in our software supply chain.

These supply chain attack methods are:

Vendor Compromise.
Exploit Third Party Applications.
Exploit Open Source Libraries.
Dependency Confusion.
Hostile Take-Over.

In this blog series, we will examine each of these supply chain attack methods individually.

Vendor Compromise

Arguably the most sophisticated of the supply chain attack methods, a Vendor Compromise typically starts with a reconnaissance phase to understand which organizations use the vendor’s software, where it’s installed, and what types of information, privileges, and systems it may have access to. Next, the bad actor attempts to gain valid vendor employee credentials via social engineering, phishing, or other more technical means. After establishing a toe-hold in the vendor’s infrastructure, the malicious operator attempts to laterally move to the software build environment in order to modify the source code of the application that the vendor provides to its users.

While almost any malware could be placed into the vendor’s application, the typical malware is a backdoor or remote connection point which provides maximum flexibility for the bad actor once the vendor’s tainted software has been installed. The backdoor code allows the attacker to establish network connectivity directly with the victim’s server in order to execute Operating System commands to disable Endpoint Protections, download additional malware, read sensitive data, etc. In the case of SolarWinds, it’s estimated that it took at least six months to go from the initial “test” insertion to the final tainted update that was delivered to thousands of customers.

Backdoors in trusted vendor programs are tricky to detect through traditional means including security testing tools, Web Application Firewalls, and Endpoint Protection. Why? Bad actors know all about our typical defensive strategies. The malware code they write is carefully written to obfuscate its purpose making it difficult to detect with security testing tools. The backdoor code is often not triggered by external stimuli making it impossible to detect by watching the traffic inbound to the compromised application. Finally, the malicious code is usually designed to disable or bypass endpoint protections.

Imperva RASP

Imperva Runtime Application Self-Protection (RASP) offers a compelling way forward. Delivered as a lightweight software plugin, RASP attaches to virtually any type of application whether a third party, open-source or bespoke. Tightly coupled with the application and requiring no external connectivity, RASP protections are consistently applied regardless of where the application is deployed today or in the future. Using a positive security approach, RASP mitigates risk from supply chain attacks by neutralizing malicious software activity including unauthorized network calls, file system access, and execution of commands on the underlying host operating system.

Perhaps this is why the National Institute of Standards and Technology recommends the use of RASP in Special Publication 800-53, section SI-7(17), Security and Privacy Controls for Information Systems and Organizations?