As with any technical consultancy, there is no escape from technical presales activities – no matter what your position may be. As a result, after a prospective client has waded through the reams of online service offerings and navigated their way around the salesman, I often find myself involved in the technical presales phases of scoping the security offering and proposing the job's requirements.
One of the key questions raised in 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-day exploits?
Depending upon the nature of the client's business and their overall technical security capability, there may be scope for inclusion of zero-days during the testing. In general, security-aware organizations trying to evaluate their "insider threat" or targeted external attack scenarios will often ask for the inclusion of zero-day exploits and related attack vectors.
If a client does not really understand what a zero-day exploit is, or has not expressly stated that this is a level of testing they require, my consultants will not typically use zero-days 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 is 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 zero-day exploits to compromise a system. My answer to this is in several parts.
First, by definition, a zero-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.
As a result, 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 defenses with some kind of sophisticated anomaly detection algorithm, will simply mitigate the impact of the exploitation – not prevent it.
Second, companies such as mine, which maintain a rolling catalog of hundreds of software vulnerabilities in various states of patch development and remediation by their vendors, have access to a range of zero-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 catalog 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 zero-day to gain access, how are they going to report the finding to the client without either scaring them (for example "sorry, but there is currently no known fix – 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? For example 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 zero-days within the testing regime as it will help them understand how resilient their environment is to an unknown attack. If that is the case, my recommendation is that they forget the zero-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 zero-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.
The most worrying thing for me is reading new security vulnerability reports – especially the critical ones. It is amazing just how many vulnerabilities are discovered and reported to vendors independently – some advisories acknowledge ten or more unrelated responsible "discoverers." I just wonder 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?
