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.

Perimeter

10/13/2010
07:00 PM
David Maynor
David Maynor
Commentary
50%
50%

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Stop Defending Everything
Kevin Kurzawa, Senior Information Security Auditor,  2/12/2020
Small Business Security: 5 Tips on How and Where to Start
Mike Puglia, Chief Strategy Officer at Kaseya,  2/13/2020
Architectural Analysis IDs 78 Specific Risks in Machine-Learning Systems
Jai Vijayan, Contributing Writer,  2/13/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19325
PUBLISHED: 2020-02-17
SilverStripe through 4.4.x before 4.4.5 and 4.5.x before 4.5.2 allows Reflected XSS on the login form and custom forms. Silverstripe Forms allow malicious HTML or JavaScript to be inserted through non-scalar FormField attributes, which allows performing XSS (Cross-Site Scripting) on some forms built...
CVE-2020-1693
PUBLISHED: 2020-02-17
A flaw was found in Spacewalk up to version 2.9 where it was vulnerable to XML internal entity attacks via the /rpc/api endpoint. An unauthenticated remote attacker could use this flaw to retrieve the content of certain files and trigger a denial of service, or in certain circumstances, execute arbi...
CVE-2020-1828
PUBLISHED: 2020-02-17
Huawei NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00; and Secospace USG6600 and USG9500 versions V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, and V500R005C00 have an input validation vulnerability where the IPSec module does not validate a field in a specific message. ...
CVE-2020-1857
PUBLISHED: 2020-02-17
Huawei NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00SPC100; and Secospace USG6600 and USG9500 versions V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, and V500R005C00SPC100 have an information leakage vulnerability. Due to improper processing of some data, a local authent...
CVE-2020-1858
PUBLISHED: 2020-02-17
Huawei products NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00SPC100; Secospace USG6600 versions V500R001C30SPC600, V500R001C60SPC500, and V500R005C00SPC100; and USG9500 versions V500R001C30SPC600, V500R001C60SPC500, and V500R005C00SPC100 have a denial of service vulnerability. Att...