An Information Security Community
The folks of Pauldotcom Security Weekly podcast inspired me to write something about using 0day exploits for pentesting.
The question was, whether or not it's a good idea or fair to use those in a pentest.
My take on this is like "hell yeah!". But there are some more aspects to that topic of course, otherwise I wouldn't have considered writing a blogpost on it.
So first off, let's discuss what the intention of using 0days in pentesting might be. For me personally, I think a penetration test is not merely about confirming that someone is doing patch management and knows how to configure systems in a secure and safe way. I don't even use the word penetration test. I use the word security test or operational security test.
Some folks may cry "unfair!" when you tell them you've just pwned them using an 0day exploit.
That is because they think that any bad outcome of the test could indicate that they've been doing a bad job. "How am I supposed to prevent someone exploiting a vulnerability that the vendor of the software has not yet provided a patch or workaround for?"
So it's your obligation to explain to your customer that this is not what the test is about.
It's about if the company can withstand and deal with today's threats. It's about whether or not the proper controls are in place in order to detect and mitigate an attack or security breach. It's about whether or not they are having defense in depth so that one isolated breach does have minimal impact on overall operational security.
Of course you don't just go ahead an happily exploit all the holes that you think you've found without previously giving your customer notice. Doing so will not only piss them off but could also adversely affect their operations.
A proper security test is performed in several steps like
1. discovery and enumeration
2. basic security assessment
Using 0days would be something for phase 3. All phases shall be conducted in tight coordination with the customer. It is for example very valuable to get feedback on what the admins or monitoring staff see of your activities. Of course it's another thing if it is part of the engagement not to inform the staff about when a test is going to occur because your customer wants to check if attacks would be detected in a real incident.
So then if you are going to use 0day-exploits, you'd better be damn sure where these 0day-exploits are coming from and what they are doing. You don't just go "hey, I've just found what I think is a juicy 0day vulnerability - let's go to milw0rm and fetch an exploit".
Only use 0days that you have tested before and that you are able to review.
Simple Perl-, Ruby- or shellscripts are quite easy to vet but be careful with those anyway.
But if things are getting more complex or contain cloaking and code obfuscation or if the exploit is only available in binary form, better not use it before you haven't tested it thoroughly in a lab and had it peer-reviewed by other folks in the community.
The Open Source Security Testing Methodology Manual version 3 (OSSTMMv3) defines these practices in the rules of engagement as an obligatory rule for any OSSTMM security test:
25. The Analysts are required to know their tools, where the tools came from, how the tools work, and have them tested in a restricted test area before using the tools on the client organization.
And get explicit permission to exploit a finding for each finding before doing so!
If your customer gives you a wildcard permission for exploiting any vulnerability you find without extra notice - fine. But better have this one in writing and signed by the customer before.
Further guidelines can be found in the OSSTMMv3 (www.osstmm.org).