If an exploit falls in the forest, does anyone hear it being patched?

Recently, Tenable added exploitability reporting for Nessus. After performing a scan, results can be filtered to see which vulnerabilities have exploits available for them. In the report, you can even see which common exploitation tools have payloads for these vulnerabilities. This is a great way to help prioritize which vulnerabilities to fix first. However, it is not a great way to manage your network or decide whether to patch a system or not. Consider the following conversation that represents many I’ve had on this topic: 

IT Auditor: Ron, we love the new exploit filtering feature in Nessus!

Ron: That’s very cool. What do you like about it?

IT Auditor: We don’t have to patch as many servers as before!

Ron: Really, why is that?

IT Auditor: If an exploit isn’t available for the vulnerability, why should we worry about it?

Below is a screen shot of a Nessus 4.4 report which shows the specific exploit packages that can be used to compromise a host that has a known vulnerability:

Having reports and filters available like this can help prioritize vulnerabilities to be fixed, but they can also cause a laser focus to issues while ignoring more systemic matters. For example, doctors are getting better and better at detecting cancer at earlier stages, but still urge people to quit smoking as the primary deterrent. Fixing critical vulnerabilities is an excellent short-term approach to network security, but broader measures are required in order for you to have defense in depth and a network that is manageable.   

Just because an exploit isn’t public doesn’t mean one doesn’t exist. I’ve seen this argument used many different ways. I used to have Solaris administrators tell me their Solaris x86 systems weren’t vulnerable to the same issues their SPARC systems were. In the 90’s, exploits were coded against SPARC platforms and x86 exploits weren’t found often. The longer a vulnerability exists publicly, the more likely someone will write an exploit for it, or port an existing exploit to a different architecture. New exploits are added to commercial and open source exploit platforms and packages all the time. These are often written at the request of customers who need to demonstrate security issues with certain pieces of software. In addition, there are many organizations that pride themselves on their extensive list of private exploits.

Similarly, some vulnerabilities are minor in nature, yet could be the only method an attacker uses to compromise a target. For example, one of my favorite vulnerabilities that illustrate this concept is with old copies of wget. This Unix application allows quick scripting of web jobs that download some sort of content on a regular basis. It has its share of client-side vulnerabilities such as authentication overflows and arbitrary local file creation. However, it isn’t the sort of application that gets the same level of attention as a client-side vulnerability in Adobe Acrobat or a Chrome web browser. Because of this, exploits aren’t published for wget even though legitimate attack vectors exist for it.

Some vulnerabilities are really issues with technologies, frameworks, common APIs or operating systems. These are serious vulnerabilities but are often not exploitable by themselves. For example, there could be a generic issue with .NET input filtering that makes SQL injection possible. You may never see a specific exploit for such a generic issue, yet this is critical to patch. Other vulnerabilities of this type could result in IDS evasion, covert channels, encryption downgrades  and other attacks that don’t have a particular pre-canned exploit available.Finally, some vulnerabilities don’t result in exploitation – they result in a denial of service. There are many applications that are easily DOSed, but don’t have tools or exploits written to specifically take advantage of this situation.

The ability to exploit vulnerabilities is useful for risk prioritization and predictive attack analysis. You should always assume that any application can be compromised and design accordingly to mitigate the risk. However, this does not scale well. The ability to position your defenses against a known set of attack techniques can make you more prepared than trying to defend against all attacks. For example, a Tenable customer was able to figure out that certain types of exploits allowed file creation as a non-privileged user and was able to tighten up file system permissions accordingly.

It is important to educate managers and end users who aren’t familiar with the vulnerability life cycle that there are many undiscovered vulnerabilities in all of their existing applications and some of these will have exploits written for them. Otherwise, they will focus on the past and only chase patching security issues that have already been disclosed or exploits written for them. Moving forward, it's important to understand that all software and deployments have potential security issues that can be exploited. A proactive defense is to audit networks and configurations for all potential risks and not just those that can be conveniently exploited through known vulnerabilities.