Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


07:00 PM
David Maynor
David Maynor

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.

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


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/14/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Lock-Pickers Face an Uncertain Future Online
Seth Rosenblatt, Contributing Writer,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-13
ABBYY network license server in ABBYY FineReader 15 before Release 4 (aka allows escalation of privileges by local users via manipulations involving files and using symbolic links.
PUBLISHED: 2020-08-13
njs through 0.4.3, used in NGINX, has an out-of-bounds read in njs_json_stringify_iterator in njs_json.c.
PUBLISHED: 2020-08-13
njs through 0.4.3, used in NGINX, allows control-flow hijack in njs_value_property in njs_value.c. NOTE: the vendor considers the issue to be "fluff" in the NGINX use case because there is no remote attack surface.
PUBLISHED: 2020-08-13
An Uncontrolled Search Path Element (CWE-427) vulnerability in SmartControl version 4.3.15 and versions released before April 15, 2020 may allow an authenticated user to escalate privileges by placing a specially crafted DLL file in the search path. This issue was fixed in version 1.0.7, which was r...
PUBLISHED: 2020-08-13
Lua through 5.4.0 allows a stack redzone cross in luaO_pushvfstring because a protection mechanism wrongly calls luaD_callnoyield twice in a row.