A Pentester’s Cache of 0-days
Much of the InfoSec would still struggles to understand the dynamics of 0-day vulnerabilities and the quandary of their widespread availability. There is a common misconception that the prolonged period between discovery and vendor patching is not only a security threat, but is also proportional to the severity of the threat.
I was lucky enough to join a couple of panels last week at the Suits and Spooks conference in Arlington, Virginia, during which one of the panels touched on the Equation Group’s tools of 2013 that exploited a 0-day (until late 2015) vulnerability in Cisco ASA devices. I can’t remember the specifics of the question that came up, but I made the comment that practically any penetration tester worth their salt sits on several dozen undisclosed vulnerabilities at any point in time. Apparently that statement made several folks uneasy – as I found out during a vendor sponsored drinks session later that evening.
Every skilled pentester I’ve ever met or had the pleasure of working with over the years sits on their own cache of undisclosed (i.e. 0-day) vulnerabilities. Many of those vulnerabilities will have been discovered during paid customer engagements or during self-initiated security research projects.
I would estimate that a senior pentester with a decade of experience in finding bugs in client engagements working for F500 and other technology companies probably has a dozen critical vulnerabilities, twenty or so high risk vulnerabilities, and another hundred or so lesser vulnerabilities buried away on hard-drives or within attack scripts that are yet to be disclosed to a vendor.
Why would a pentester be sitting on 0-days? Some common reasons (or justifications) include:
The vulnerability was discovered during a client-paid engagement. The vulnerability was disclosed to them, but they declined to inform the vendor of the discovery. Note: In this situation, the client owns the vulnerability and it’s up to them to decide on next steps as far as getting the vulnerability fixed. From past experience, for interesting and “high risk” bugs, I’d estimate that 50% of clients ask the pentester to take the lead in disclosing the vulnerability to the vendor, 20% of clients chose to alert the vendor and do so themselves, 20% of clients chose to alert the vendor but never do, and 10% of clients explicitly tell the pentester not to inform the vendor as they have other plans for the vulnerability.
The vulnerability by itself (as found within the customer environment/configuration) was not critical at the time, but needed to be chained with other bugs and attack vectors to make it a reliable exploit. Note: Parts of the 0-day discovery were done on the clients dime, but the real work was done by the pentester outside of the engagement. The original discovery may not have warranted the client caring about the vulnerability – or had other mitigating technologies that made the vulnerability a lesser or benign risk.
The pentester identified some interesting devices or software that was “out of scope” of the client, or was investigated as private research. The bugs that were uncovered are lying dormant until the pentester has an opportunity to try them against a “live” client environment in the future.
Disclosure of the vulnerability to a vendor is often an unpaid chore – and not worth the time and effort to disclose or chase. Note: Often the application or hardware in which the vulnerability was discovered is only accessible within a specific client’s environment. Vulnerable vendors will often require additional details about the bug in order to verify or proceed on developing a fix. Vendors will typically ask for patch version information, configuration files, packet captures, proof of concept code, etc. – which may not be known by the pentester or may be proprietary to the client (i.e. exploit code developed during a client engagement often belongs to the client).
Holding on to 0-day vulnerabilities leads to some common ethics questions within the InfoSec world. One that came up at the open bar was “What happens when the pentester finds the same vulnerability on another client’s infrastructure?”
I think the answer here I pretty simple. If Client B has paid the pentester to find vulnerabilities, would it be ethical for the pentester to hold back a finding because she had first discovered it during Client A’s engagement? Of course not! Each pentest and its findings are separate between clients.
Let’s hypothesize that a pentester is commissioned by Client A to find vulnerabilities in a Palo Alto Network’s firewall appliance. The pentester spends a week investigating, finds a couple of critical vulnerabilities (taking 10 hours of effort to discover, prove, and develop an exploit for each one) and the client, upon receiving the final report tells the consultant that they will decide on what the disclosure process will be by themselves (i.e. keep it quiet).
A couple months later the pentester is working on an engagement for Client B who just happens to be using the same Palo Alto Network’s firewall appliance. The pentester performs her regular investigation, but in addition also checks for the vulnerabilities she has discovered in past client engagements. That check for the two critical vulnerabilities may only take 5 minutes to assess and confirm (instead of the hours expended for the first client). In the final report to Client B, all the vulnerabilities are listed – including the two “0-days”. Client B now also owns all the findings within their report.
If Client B wishes for the two 0-days to be disclosed to the vendor (for fixing, it is assumed), then that must happen. Under no circumstances could the pentester ethically withheld those findings from the client. However, if the pentester wants to retain Client A for future work (or avoid be pursued for some kind of perceived “breach of contract”), I’ve found that informing Client A that the same vulnerabilities have been uncovered elsewhere and that other (unnamed) client is proceeding with disclosure, is generally acceptable and, as the British often say, “good form”.
One of the benefits of hiring an experienced senior pentester is precisely because they do sit on lots of “0-day” – thereby making themselves much more efficient at finding bugs and flaws in their client’s networks. Asking a pentester how may 0-days they’re sitting on is probably a good indicator of how efficient and experienced they are.
-- Gunter Ollmann, Founder/Principal @ Ablative Security
