The 0-day Blues
First Published: SC Magazine

As with any technical consultancy, there is no escape from technical presales activities – no matter what your position may be. Consequently, after a prospective client has waded through the reams of online service offerings and navigated their way around the sales man, I often find myself involved in the technical presales phases of scoping the security offering and proposing the jobs requirements.

One of the key questions raised during a scoping meeting is “how far would you like us to go?” – as in, how invasive should the penetration test be, are we allowed to compromise vulnerable hosts, and do you wish us to use any possible remote means; including the use of zero-days?

Depending upon the nature of the clients business and their overall technical security capability, there may be scope for inclusion of zero-days (0-days) during the testing. In general, security aware organisations trying to evaluate their “insider threat” or targeted external attack scenarios will often ask for the inclusion of 0-day exploits and related attack vectors.

If a client doesn’t really understand what a 0-day exploit is, or hasn’t expressly stated that this is a level of testing they require, my consultants will not typically use 0-day’s to compromise the target hosts during a pentesting engagement. The same goes for conducting denial of service attacks – unless you tell the consultant otherwise, it’s assumed that they too are normally out of scope.

Some people reading this may question whether the consultants are providing the best level of service by not dipping into their repository of 0-day exploits to compromise a system. My answer to this is in several parts.

Firstly, by definition, a 0-day vulnerability is a security flaw that the associated software or hardware vendor is either not aware of or is currently working on a fix, and no patch or product update is publicly available to protect against the exploitation of it. Consequently if the vulnerable product is installed and accessible to the consultant – they can exploit it. Any other protection devices, including rigorous host hardening practices through to installing top-drawer perimeter defences with some kind of sophisticated anomaly detection algorithm, will simply mitigate the impact of the exploitation - not prevent it.

Secondly, based upon the fact that my company has perhaps some of the most well known and feared/respected vulnerability researchers in the world (after all, who hasn’t heard of the “Litchfield brothers”?) which maintain a rolling catalogue of several hundred software vulnerabilities that are in various states of patch development and remediation by their respective vendors, all my consultants have access to over 100 0-days as a matter of course. Thereby, like locksmiths with a van full of master keys, the consultants can probably gain entry in a way most professional hackers can only dream of. So, by dipping into this catalogue of undisclosed vulnerabilities the consultant is no longer replicating how a typical hacker would go about their business.

Finally, assuming that the consultant uses the 0-day to gain access, how are they going to report the finding to the client without either scaring them (E.g. “sorry, but there is currently no known fix – to protect against this vulnerability until a vendor fix is available you will have to block all access to port 80 and 443 on your web server”) or providing too much information – information that could be dangerous if it fell into the wrong hands? (E.g. a posting to the bugtraq mail list from an unsuspecting system administrator along the lines of “…what does ‘Stack overflow in the ABC register of the DEF component within version 2.34 of the GHI application’ mean?”).

Some clients say they would like to include 0-days within the testing regime as it will help them understand how resilient their environment is to an unknown attack. If that’s the case, my recommendation is that they forgo the 0-day test and just practice the disaster recovery plan pretending that they have already been hacked - it will certainly be cheaper than paying top rate for a consultant just to run a script containing an exploit nobody has any protection against.

For those people who say that the 0-day threat is fictional, or that their security system can prevent and contain any such outbreak, my response is “dream on”. Try working in an office such as mine – knowing full well that every consultant sharing the network I am connected to could compromise my fully patched and hardened laptop through several dozen methods whenever they wanted to. I have to trust my colleagues implicitly. At least I can take comfort in the fact that they would never have gotten UK government security clearance if they couldn’t be trusted right?

The most worrying thing for me is reading new security vulnerability reports – especially the critical ones. It’s amazing just how many vulnerabilities are discovered and reported to vendors independently – some advisories acknowledge 10 or more unrelated responsible “discoverers”. The questions from me are what percentage of people that discover a critical vulnerability actually report it to the vendor? …and what do the non-reporting discoverers do with the vulnerability in the time before a patch is publicly available?

Top Tips

  1. Clearly define the objectives of a pentest – 0-days are not normally included as part of most engagements.
  2. It doesn’t matter how many 0-days the consultant has access to – if they don’t have one relevant to your environment, they can’t test for it.
  3. Responses to successful 0-day penetration tests should be seen as live practices for disaster recovery processes
  4. Not all 0-days are equal. There is always something worse out there in the hands of someone else.
    Copyright 2001-2007 © Gunter Ollmann