Vulnerabilities / Threats

7/10/2017
01:30 PM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
50%
50%

How Code Vulnerabilities Can Lead to Bad Accidents

The software supply chain is broken. To prevent hackers from exploiting vulnerabilities, organizations need to know where their applications are, and whether they are built using trustworthy components.

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:

 

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Cybersecurity's 'Broken' Hiring Process
Kelly Jackson Higgins, Executive Editor at Dark Reading,  10/11/2017
Ransomware Grabs Headlines but BEC May Be a Bigger Threat
Marc Wilczek, Digital Strategist & CIO Advisor,  10/12/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: What did you expect from this SOC? A unicorn....
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
The State of Ransomware
The State of Ransomware
Ransomware has become one of the most prevalent new cybersecurity threats faced by today's enterprises. This new report from Dark Reading includes feedback from IT and IT security professionals about their organization's ransomware experiences, defense plans, and malware challenges. Find out what they had to say!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.