There is some buzz surrounding today’s (November 30) “new” release of an exploit for CVE-2011-3544 by Metasploit that takes advantage of a vulnerability in the Java Runtime Environment (JRE) to execute code on a vulnerable system. Core released its own exploit for CVE-2011-3544 to IMPACT Pro customers 20 days ago which provided them with almost three weeks to pen test their defenses against possible attacks to JRE -- while they have likely waited for their admins to deploy the patch to the vulnerable systems. (The security update released by Oracle to remediate this vulnerability was available starting October 18th).  


However, it would not be fair to closely compare exploit delivery times because Core has a full-time team of highly experienced Exploit Writers who discover and write an impressive number of vulnerabilities that continuously help protect our customers’ IT infrastructures. In contrast, Metasploit relies upon the fine, hard work of public contributors who submit their code to the commercial entity that owns the open framework for inclusion.

What struck me was the 20 days that people were blind to the possibility that their defenses would not prevent an attacker from leveraging this vulnerability, and gaining both access and control of systems within their environment. It seems to me that people who were not able to replicate what this attack would look like on their network (and via their defenses) was like a zero day targeting their network undetected for 20 days. And could you imagine what an attacker could do in 20 days if they had access to your network?

The typical method for attacking this vulnerability is via a spear phishing campaign or embedding attack code into a web page that lures victims to visit. We all know how susceptible users are to phishing attacks, and if an attacker could use Search Engine Poisoning to drive users to a site they control, they don't even have to worry about avoiding Spam filters.

The need for this vulnerability falls into three buckets:

1. To prove that machines within an organization are vulnerable to this attack

Some organizations have a policy of patching vulnerabilities within a defined patch cycle (often quarterly) unless the security team can prove there is a real and present danger. Without an exploit that allows them demonstrate the exploitability in their environment these types of threats go unprotected

2. To test any compensating controls that mitigate these threats

Which is a fancy way of saying the need to know if their network or host defenses (IPS etc) will stop the attack - because this vulnerability isn't going to be patched anytime soon. Deploying an IPS and not testing if it can actually stop a real attack is like buying a car that has never undergone any crash tests but taking the dealer at their word...

3. To successfully prove or disprove a customers claim that they are secure

For those of us who provide security testing as a service, be it for internal customers or for external customers, if we are not using the latest exploits to measure their security we are not presenting them with a real world view of their security. If we cannot do that what value is the service that we provide?

So what difference does 20 days make? If you need to truly understand the security risk an organization is facing and measure their defense against it then 20 days behind is 20 days too late.

- Alex Horan, CORE IMPACT Product Manager