How Code Vulnerabilities Can Lead to Bad Accidents

When a car manufacturer discovers a faulty part, it is obliged to issue a recall and notify its customers of the damaged product. The problem is that all these cars are already on the road driving around with a recalled part, causing immense amounts of liability for all parties involved.

Building a Web application or API with open source components has direct parallels to building a car. Anyone using open source components must be aware that there will be vulnerabilities. And whether you’re building a car or software, your product is only as good as the components you use. Frankly, cars these days are basically software on wheels, but our software supply chain is full of holes.

You may not realize that a modern Web application is built using hundreds of these components that usually include many millions of lines of code. According to data from Contrast Security spanning almost 10,000 applications totaling over 8 billion lines of code, the average application is 79% library code, and only 21% custom code. Just over 76% of applications contain at least one vulnerability, and 34% containing four or more vulnerabilities. These are shocking failures of the software supply chain.

Earlier this year Apache released a patch for the Struts2 framework. The patch was designed to fix an easy-to-exploit vulnerability that allows attackers to execute arbitrary code on the application server. The patch announcement quickly attracted hackers who figured out how to exploit the vulnerability. Within hours, widespread exploitation attempts were launched from China, India, Hong Kong, and more. Here’s a real example of this attack blocked by Contrast:

CVE-2017-5638 Event from 119.28.21.109
When: 06/27/2017 08:43 AM

We observed an attack against CVE-2017-5638 enter the application through the HTTP Request Header "content-type:"

Common Occurrences
A few times every year, a special vulnerability like Struts2 is released. These are easy to exploit, so widespread, and so powerful that they make very lucrative targets for cybercriminals. Knowing this, organizations are left with the question: How do we respond?

You can't simply deploy a new version of Struts2 because it will break applications. This is exactly like the problem the industry faced back in the 90s with operating system software updates. At large enterprises, there used to be dedicated teams who would manually update the OS and test for problems. Over the past 15 years, operating system vendors have dramatically improved their notification and update infrastructure to automate updates.

However, we don't have automatic update in the application space. So, nobody ever knows that their components are broken, and even if they did, there's no way to update without going all the way back to development, which could take months and might affect large numbers of applications. As Struts2 demonstrates – this is a huge a problem. Attacks start within hours of a new vulnerability release. Without automated notification of vulnerabilities in components, and a fast way for organizations to respond across their entire portfolio, there is simply no way for organizations to get in front of this threat.

Every industry goes through a supply chain transformation as they mature. Look at the automobile industry or the pharmaceutical industry, for example. At some point, it becomes critical to take responsibility for the quality of the components that are part of the product. This is way overdue in enterprise software, which has reaped the benefits of using open source components without taking appropriate steps to ensure their security. So, what can we do?

Most organizations take a long time, months or years, to respond to new vulnerabilities in their software components, even when those components are easily exploited and result in catastrophic breaches. Most do not have a program to identify exactly what components they are using across their application portfolio. And they lack a program to monitor for new security vulnerabilities and evaluate whether the vulnerable components are in use in the organization.

Fortunately, there's a promising alternative called Runtime Application Security Protection (RASP) that can help. Organizations can deploy RASP directly into their Web applications and APIs to protect themselves against these software supply chain risks. Unlike Web application firewalls (WAFs), RASP works from inside the application, where it has all the context necessary to protect applications accurately at high speed. With this approach, RASP elegantly solves two problems that have plagued organizations for years.

First, RASP continuously shows you exactly where you have vulnerable open source code across your application portfolio. This is "A9" in the OWASP Top Ten. RASP products continuously report exactly what applications are running on which servers, including exactly what open source components are in use. As it turns out, simply knowing exactly what code is running is a major challenge for most organizations. RASP also pinpoints any components that have known vulnerabilities, indicating exactly what applications they are part of and which servers they are running on. In this way, RASP provides a "big data" approach to the "secure composition analysis" problem.

Second, RASP products provide "CVE Shields" that automatically protect these vulnerable components so that flaws cannot be exploited. These shields don't necessarily remove the vulnerability from the library, but simply prevent attacks from reaching their target. In some ways this is similar to runtime defenses in operating systems and compilers, such as ASLR, that make vulnerabilities difficult or impossible to exploit. These CVE shields can be deployed quickly across an entire application portfolio without rewriting code and redeploying.

In the future, every application needs the capability to report its own "bill of materials" to make it easy for enterprises to identify where component vulnerabilities might lurk. Further, every application must have the ability to receive CVE shields that prevent component vulnerabilities from being exploited. 

We can't wait weeks or years to respond to new vulnerabilities. Every organization needs the capability to respond in a matter of hours when a new vulnerability is discovered. The attackers certainly aren't waiting.

Black Hat USA returns to the fabulous Mandalay Bay in Las Vegas, Nevada, July 22-27, 2017. Click for information on the conference schedule and to register.

Related Content: