5 Ways Your Software Supply Chain is Out to Get You, Part 2: Exploit Third Party Applications

In Part 1 of this series, we explained how and why our software supply chain transfers an extraordinary amount of risk downstream to the organizations and users that trust and depend on it. We also presented evidence suggesting that 2021 may well be the year of the Software Supply Chain attack.

Last time we described the most sophisticated of the supply chain attack methods, a Vendor Compromise. In this post, we cover the exploitation of third-party applications.

Exploitation of Third Party Applications

Attacks targeting “zero-days,” or unpatched security bugs, in commonly used third-party applications are another example of the risks we assume from our software supply chain.

Creating software is a challenging process. Often, incomplete requirements, incorrect assumptions, and time-to-market pressures result in the delivery of less-than-perfect software. Generally speaking, software developers do a good job of eliminating software bugs that cause the program to fail in catastrophic or obvious ways. Unfortunately, security bugs don’t typically cause catastrophic system failures. They simply allow a bad actor to make the software do things it wasn’t intended to do like steal other users’ credentials or read the entire contents of a database.

The recent attacks on the Microsoft Exchange Server are just the latest examples of this type of software supply chain attack. In this case, bugs in Exchange Server allowed attackers to read emails and install a web shell. A web shell is typically an additional web page that the attacker uploads to a website. If the attacker can modify a web page on the server, the web shell may be embedded in an existing page. The additional or modified page contains code that allows the attacker to run arbitrary Operating System commands on the webserver, read files in the filesystem, install malware, etc. A web shell offers capabilities similar to a backdoor without having to establish an additional network connection to the webserver.

Compounding the problem, the rapid-fire ability of bad actors to take advantage of software vulnerability disclosures and our own justifiably cautious patch processes create an asymmetry, with predictable results. It’s rare that an organization will be able to deploy a vendor patch the moment it is made available across all of the necessary locations. Employing a Web Application Firewall to reduce the gap is a common strategy. Even the best WAFs require time to adapt, however, either with a new signature update (that must be developed, tested, and deployed) or with an adjustment to a machine learning model, or manual acknowledgment that an anomaly has been detected and should be blocked in the future. Additionally, these “virtual patches” must be tested in each organizations’ environment prior to deployment to ensure they don’t cause unwanted side effects.

The race to mitigate zero-day attacks through traditional means is increasingly difficult to win. For example, a Zoho ManageEngine Desktop Server zero-day vulnerability was broadly exploited within days of its public disclosure.

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?