In previous posts, we explained how two kinds of supply chain attack methods, Vendor Compromise and Exploit Third Party Applications, are threatening software supply chains, transferring an extraordinary amount of risk downstream to the organizations and users that trust and depend on them. In the third part of this series, we cover the exploitation of open source libraries.
Exploitation of Open Source Libraries
A close relative of the “Exploit Third Party Applications” attack vector, targeting zero-day vulnerabilities in commonly used open-source libraries or components is another frequently used tactic in the attacker’s playbook.
Nearly all software programs developed today contain open-source components. In fact, the number of open source components in a typical application is in the hundreds, in a multi-layer chain of dependencies. And recall that software programs aren’t limited to third-party packaged software like Microsoft Exchange Server. Software-as-a-service offerings, purpose-built equipment (such as routers, Internet of Things gadgets, medical devices, critical infrastructure control systems, etc.) and custom-developed in-house software also contain significant quantities of open-source software.
Unfortunately, open-source packages have the same challenges as any other software (i.e. they contain security bugs). Worse, once included in an application they can become rapidly out of date, lacking the most recent bug fixes. On top of that, open-source code is freely available to everyone, so bad actors can study and experiment with it without fear of exposing their next wave of attacks. The Apache Struts 2 framework (used in thousands of enterprise websites) is a popular target for security research for both benign and malicious purposes. It has had 13 critical-severity zero-day disclosures in the past 5 years alone.
Effective open source zero-day exploits often provide inspiration for widespread research (and attack) trends. For example, a wave of more than 500 deserialization vulnerabilities was found in dozens of open source components starting in 2016 after the technique was broadly discussed in the security research community. A deserialization vulnerability is another technique that attackers can use to inject arbitrary code into an application for execution on the victim’s server.
And finally, the economic incentive for an attacker to uncover a zero-day in a widely deployed open-source package can be significant – ranging from a few hundred to tens of thousands of dollars…or more. The combination of the broad distribution of targets, easy access to source code, and money, make finding ways to subvert zero-days in open source components an overwhelmingly attractive objective for attackers.
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?
See Runtime Application Self-Protection for yourself.
Get the latest from imperva
The latest news from our experts in the fast-changing world of application, data, and edge security.