The Ankle Biters of the Application Security World

The playing field isn't exactly level, and ankle biters (aka script kiddies and hackers) know it. While businesses and organizations are triaging their vulnerabilities and fixing them as they can, script kiddies don't need to focus on The OWASP Top Ten and Beyond, they only need to know one vulnerability. If they know it well, they can use the same attack on as many websites as possible.

So I'm from the Java world primarily, where Struts and Spring are the favorite poster child of this problem. They've each had a major [I own your server level] vulnerability in the past three years. In fact, Struts had four major vulnerabilities in the last three months of 2013. So they issued a new release that fixed all four at the same time.

In fact, the day of the new Struts release, some major websites got owned within just a few hours of the release coming out. The bad guys say, "Oh, new release to fix that CVE. Great. Let's reverse engineer the difference between the two versions, find the vulnerability, scan the internet for anyone using a still-vulnerable version of Struts, hack into those servers, game over." 

When Scott Thurm from the Wall Street Journal asked Ted Schlein of Kleiner Perkins Caufield & Byers if he could foresee a time when organizations could feel like they're winning the cyber-security battle, Schlein replied: 

"I don't think it's a battle you necessarily win. I think it's one you try and just get to a draw on. Your best days are when the bad guys go elsewhere....I'm a firm believer [that] there are only two kinds of companies -- Those that have been breached and know it, and those that have been breached and don't know it. Most of what we do in security is around prevention, prevention, prevention. Great. Just know it won't work."

“...there are only two kinds of companies -- Those that have been breached and know it, and those that have been breached and don't know it.”

Which Vulnerable Web Applications Should I Fix First?

So when you find out a vulnerability has been fixed in a library you're using, you have to figure out a few things: A: How severe is the vulnerability? B: How critical are the applications that are using it? C: Are my apps using or exposing the library component that was patched? The answer to these questions should tell you how important it is for you to upgrade that library. In the case of the Struts vulnerability example, ALL applications using the unpatched version of Struts are vulnerable because Struts itself directly exposes the vulnerability to all users of the application, regardless of how the application is using Struts.

Once you've decided you really need to upgrade, there are a few other questions related to how hard will this be. A: Did the library's behavior or APIs change? and B: How many versions out of date am I? If I'm one or two versions behind, it's probably no big deal. Drop in a new one. Probably okay. But a lot of times you stop paying attention. And it has been 12, 18, or 24 months since you've upgraded. Now you're 12 versions behind. Now you want to upgrade and you're, like, "Oh crap. All kinds of stuff has changed in the last 12 months or 24 months. I might not want to risk the upgrade."

If you don't get and stay on top of this, this gets pretty hard in a hurry. So how do you manage vulnerabilities in the open source components you use? Are you ignoring this issue at the moment, like many others? Do you analyze things once in a while to try to make yourself safe? First off, if you are going to use open-source frameworks and libraries, step one is to avoid downloading libraries with known vulnerabilities so you don't make the problem worse. Step two is to update what you are using as soon as is practical when patched or new versions of those libraries become available. When new versions of libraries become available, in general I think you're better off just upgrading even if no known CVEs are patched in a new release, because developers frequently make security fixes without acknowledging them publicly at all, or by making vague comments like "and a few minor security improvements" in the release notes.

So what can you do to make this process less painful? Ideally, step one is knowing which libraries are known vulnerable, and knowing if your skill set is up-to-date to handle them. So hopefully you have automation that says, "You have these 37 libraries in your project, and these are the 17 of the 37 that are out of date, and one of them hasn't been updated in three years. The rest are only six months old. They're not so bad." Whoops. This one has a known CVE in it. You better fix that right away. Without some kind of automation, you'd have to do this by hand, which simply isn't feasible or practical. Without automation, what do you do? Are you going to go to the CVE site periodically and go, "Oh, the Struts issue. I wonder if I'm using that?"

“If you are going to use open-source frameworks and libraries, step one is to avoid downloading libraries with known vulnerabilities so you don't make the problem worse. Step two is to update what you are using as soon as is practical when patched
or new versions become available.”

So what we need is an ecosystem. We need an ecosystem where CVEs get reported on libraries. That data ends up in a central repository, and then when you download the library it says what CVEs did it fix, or it says, "Hey, this library has a CVE on it, by the way. You probably don't want to use it." We need something that is continuously updated and something that can constantly monitor the libraries you are already using, because an annual scan will only find problems, well, annually. What if I told you something similar already exists? It's called Contrast™.

Contrast to the Rescue

Let's be honest, though. You don't care about all of the application security vulnerabilities across the web. You only care about those that affect you, your applications, and your organization's code.

Contrast analyzes the application's code at run time, by monitoring and analyzing all the code you are exercising whether you have access to the code or not. Yes, that's right. Including libraries and frameworks, as well as proprietary or third-party applications. For libraries and 3rd party code, provides two levels of analysis.

1. Contrast reports known vulnerabilities in the libraries YOUR applications are using, and also tells you how many of the classes in this libraries your application actually uses.
2. Contrast can also find unknown vulnerabilities in the open source and 3rd party code your organization is relying on because Contrast monitors ALL the executing code, not just the code your team wrote. This is identical to Contrast finding unknown vulnerabilities in your custom code, which is the primary purpose of Contrast.

“Contrast avoids the limitations that static analyzers have with libraries by analyzing the running code, and if issues are found it points out exactly where in the code the issue occurred, all without direct access to the original source code.”

And better than just telling you that Contrast just discovered a new problem in the library you are using, Contrast can tell you the exact line of code where the vulnerability exists. This allows you to not only prove to the 3rd party or library code owner that there is indeed a problem, but exactly where the problem is so they can fix it quickly. This allows your open source and 3rd party code providers to not only much more quickly validate the security issues you report to them, but also speeds their ability to fix the problem and provide you with patched software that you can deploy to reduce your risk of using this 3rd party provided code.

As depicted below, Contrast not only tells you which version of each library you are using, it also includes when it was originally released, the most recent version that is available, when that version was released, and how much of that library you actually use.

Contrast also lets you know when any of these libraries contain any known vulnerabilities and provides you with full details about such vulnerabilities, including their severity, and the nature of the vulnerability. Based on the age of the library, and any known vulnerabilities identified, Contrast produces a score for each library your applications are using. This allows you to triage and upgrade the libraries you are using on a timely basis, making it much easier for you to avoid the use of libraries with known vulnerabilities and old libraries that probably contain unpatched unpublished vulnerabilities that have been fixed in later releases. Contrast can constantly monitor your library usage throughout your application portfolio, making it quick and easy to identify which applications are using libraries with known vulnerabilities. When all is said and done, Contrast ranks all of those variables and gives the library a grade in easy to understand colors to help you set your priorities. All of this is modern technology designed to counter modern threats.

At the end of the day, the script kiddies of the application security world have it easy. They get to focus on one vulnerability and work it until exhaustion, then they get to move on to their next vulnerable application target. So let's you and I make a pact right now that says two things:

1. "I will avoid using libraries with known vulnerabilities." 
2. "I will demo Contrast so I can see which of my current applications are using vulnerable libraries and components."

Developing a robust application security program does not need to be a daunting task...

Perhaps, all it takes is rethinking your existing program and moving to one that leverages a continuous application security (CAS) approach. Organizations practicing CAS quickly determine how a new risk affects them, design a defense strategy, and measure their progress to 100% coverage. By implementing eight functions within an enterprise you can assemble an effective application security program.