Zero-Day Pen Testing Under Fire

A blog post I wrote recently about using zero-day exploits for testing seems to have ruffled some feathers: I got a flood of email about why the concept is immoral, tests like that are not valid, and a host of other problems. Rather than responding to emails individually, this post answers a few common grievances with my testing methodology.(As a side note, the majority of the complaints were from industry analysts and vendors. The CISOs, managers, and people who do security for living seemed to be fine with the concept of using 0-day in a penetration test).

Here are my responses to questions from my "The Case For Zero-Day Penetration Testing" blog: Question: Why are you encouraging people to hold on to 0-day vulnerabilities? Don't you know you are making the world less safe for everyone? Answer: If you read my blog, I am not actually encouraging anybody to do this. I simply state that with the rise of high quality 0day in the wild, overlooking this vector of attack could be costly.

Analysts and vendors have been able to coast on a magic carpet argument that nobody uses 0-day in attacks so you shouldn't use them in tests, so instead report them to the vendor and wait for a fix. While this what is best for vendors and the analysts who have staked their reputation on the 0day threat just being hype, it's not actually helping any of my customers.

Since I wrote the original blog post, there has been code released for unpatched exploits in Apple QuickTime, two in Adobe products, and one affecting Microsoft products. That averages out to a new unpatched vulnerability a week. Understanding this threat and building an environment that can handle it should be on the forefront of everybody's mind.

But you can't just stop at understanding you actually have to test. Penetration tests are designed to mimic what an actual attacker could do not just catalog a list of known vulnerabilities. In order to test an environment's response to an 0-day attack, you have to actually have 0-day -- anything else can be dismissed or trivialized. I've dealt with plenty of customers who didn't want to fix a problem until it was absolutely shown that it was exploitable and a risk. These customers won't take my word for it that an attack could happen unless it actually happens. A tester could not demonstrate the risk unless they had access to or had the ability to find 0day vulnerabilities. Question: Using 0-day exploits in a test can be dangerous! Your client could face downtime, network instability, or a zombie invasion. What do you think about that? This is a valid argument. Using 0-day exploits can lead to bad things. This is why testing should be done when downtime is acceptable. Before using unpatched vulnerabilities in a test, I get sign-off from the client, inform them of the risk, schedule a time for testing, inform them of the test, do as much recon as possible, and finally inform them of the risk before launching the attack.

There are plenty of tools used by penetration testers now that can crash devices, cause denial-of-service like conditions, and generally wreck havoc on a network. Zero-day vulnerabilities are no different than these tools, and if a client wants them to be used in a test, I inform them of potential pitfalls like I do with any other tool in my arsenal. While I take the kid gloves approach, an attacker in your network will not. Question: If you use 0-day exploits in a test you can't give a client remediation advice other than install a patch when available. Since you aren't working with the vendor to make the patch available, aren't you making yourself look bad to customers?

This is one of the most commonly asked and least understood arguments I get. You first have to take the mindset that something bad is going to happen to a computer somewhere for some reason. Even if you have all the security tools, vendor patches, and layered security you can buy, something will still get at least one of your computers.

This cold hard reality is why organizations have incident response procedures. This means that the quicker an organization can detect, isolate, and analyze the intruder, the better chance they have of containing a breach. A lot of suggestions I offer clients from 0-day findings involve policy changes, better monitoring, and network segmentation. Suggestions I make to a client are not dependent on a vendor fix, so patch schedules don't impact their security.

Those are all the questions I wanted to answer. I know some people may still disagree with me, and I will never be able to change their minds. Like it or not, 0-day exploits are being used in real-world attacks and sticking your head in the sand won't solve the problem. David Maynor is CTO of Errata Security. Special to Dark Reading