Heartbleed has put the security community on notice: it is time to take a harder look at the security status of open source components and frameworks. After doing a little industry research on downloads from the (Maven) Central Repository, I’m sitting here with my jaw hanging open. Over 46 million Java-based open source components containing known vulnerabilities were downloaded from the Central Repository in 2013*.

Heartbleed may be the most notorious manifestation of a component vulnerability, but there are four components that have critical or severe vulnerabilities associated with specific versions that are still being actively downloaded. I want to be clear that the projects typically do a great job of responding to and fixing vulnerabilities. The issue is that users don’t respond as quickly to consume the fixes. Given that attackers are notified via the same mechanism that a vulnerability has been found and fixed, they effectively have first mover advantage because it’s generally easier to exploit than it is to update your application framework. We want to call attention to this problem.

Here are the top four downloads that should concern you the most. If you are running these component versions, you are opening yourself, and your company, to avoidable risk. If you aren’t sure if you are in fact using any of these vulnerable components, we can help with a complimentary assessment.

* Data for this article is from the National Vulnerability Database, Central Repository data analysis by Sonatype Component Lifecycle Management (CLM) and the Nexus Pro CLM Edition.

Struts

• Component/Framework: Struts
• Access Vector: Complete system compromise
• Downloaded since: July 2013
• CVE: CVE-2013-2251
• Threat Level Score: 9.3

Struts is a popular application framework. Its popularity has waned in recent years but it is still very common among older, legacy java applications. This vulnerability exists within the framework, so applications are vulnerable before a single line of custom code is executed.

Struts versions prior to 2.3.15.1 are vulnerable to CVE-2013-2251, which allows code to be uploaded anonymously and then executed as the application server user. This can lead to complete system compromise if the application server user has escalated permissions or if other vulnerabilities are chained together to escalate permissions.

“Since the disclosure in July 2013, affected versions of Struts2 components were downloaded 179,050 times from more than 4000 organizations.”

Struts version status as seen in Nexus Professional v 2.8

Bouncy Castle

• Component/Framework: Bouncy Castle
• Access Vector: Compromise decryption key and encrypted data
• Downloaded since: 2009
• CVE: CVE -2007-6721
• Threat Level Score: 10

Bouncy Castle is the most popular white-room implementation of cryptographic algorithms in Java. It’s used because the Java runtime doesn’t provide a consistent set of algorithms across every platform. The Bouncy Castle implementation can run on any platform, hence its popularity.

Certain older versions of the implementations are susceptible to a “Bleichenbacher” attack. This attack allows an attacker to compromise the encrypted data and the decryption key by observing traffic over time. This essentially makes the thing you intended to encrypt completely open.

Since March 2009, 11,236 organizations have downloaded Bouncy Castle 214,484 times.

Bouncy Castle version status as seen in Nexus Professional v 2.8

HttpClient

• Component/Framework: HttpClient 3.x
• Access Vector: Compromise decryption key and encrypted data
• Downloaded since: November 2012
• CVE: CVE-2012-5783
• Threat Level Score: 8.6

HttpClient is the most popular implementation of an http client in Java. Http is a protocol that is ubiquitous on the web. It’s what web browsers use, but also REST APIs and many other common exchanges of data on the internet. HttpClient could be used in almost any scenario where data is exchanged across networks. It is also used in Android devices to process payments. This isn’t just about big server applications, it’s about the internet of things

Since November 2012, 29,468 organizations have downloaded HttpClient 3,749,193 times.

HttpClient version status as seen in Nexus Professional v 2.8

Jetty

• Component/Framework: Jetty
• Access Vector: Network exploitable
• Downloaded since: January 2010
• CVE: CVE-2009-4611
• Threat Level Score: 10

Mort Bay Jetty 6.x and 7.0.0 writes backtrace data without sanitizing non-printable characters, which might allow remote attackers to modify a window's title, or possibly execute arbitrary commands or overwrite files, via an HTTP request containing an escape sequence for a terminal emulator, related to (1) a string value in the Age parameter to the default URI for the Cookie Dump Servlet in test-jetty-webapp/src/main/java/com/acme/CookieDump.java under cookie/, (2) an alphabetic value in the A parameter to jsp/expr.jsp, or (3) an alphabetic value in the Content-Length HTTP header to an arbitrary application.

Since its release date in January of 2010, 36,181 organizations have downloaded it 5,174,913 times.

Jetty version status as seen in Nexus Professional v 2.8

Why aren't these updated, you may ask?

One of the main problems with a vulnerability such as Heartbleed is that even when people were made aware of it, they didn’t know if the vulnerable version of openSSL was embedded in their stack. The race became, “how fast can we find vulnerable versions and fix them?”

Knowing there is vulnerability within an open source component and whether you are using a safe version of that component are two different things. Are you using any of the most popular components or frameworks with known vulnerabilities? How do you know? You may think you do, but surveys have shown that a majority of enterprises significantly underestimate the number of open source components in their applications.

Automation is the key to future management of open source development. Manually cataloging components is no longer a viable option with the speed and size of today's development environment. The only way to discover, use and manage components within your system is through an automation tool that manages the components within the development life cycle and then keeps track of them once they are deployed in production.

Doing anything less is just waiting for another "Heart" attack.

What can you do to prepare for the next HeartBleed?

What can you do to remove these vulnerable components and frameworks from your applications. Use the following checklist to quickly determine your first steps to rid your apps – both in development and production -- of vulnerable components.

1. Perform an open source application analysis to determine if you are using any components with known vulnerabilities of severity level 8 or above
2. Perform a repository health check if you are using Nexus, to highlight vulnerable components still being accessed from within your repository
3. Update existing components to the most trustworthy versions for your systems
4. Implement a component management system such as Sonatype Component Lifecycle Management (CLM), within your development environment that will automatically monitor for the use of vulnerable components both in development and in production.

If you don’t know what’s in your apps, start by finding out. We’ll help you run a quick health check to generate a “Bill of Materials” for your application or your Nexus repository which provides details of all of the OSS components used within your app, which versions of those components are being used and how to quickly remediate the most severe risks. If you have questions or want to proceed with an analysis - contact us now.

The CLM Dashboard