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
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Breaches Are Inevitable, So Embrace the Chaos
Ariel Zeitlin, Chief Technology Officer & Co-Founder, Guardicore,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-2916
PUBLISHED: 2019-11-15
qtnx 0.9 stores non-custom SSH keys in a world-readable configuration file. If a user has a world-readable or world-executable home directory, another local system user could obtain the private key used to connect to remote NX sessions.
CVE-2019-12757
PUBLISHED: 2019-11-15
Symantec Endpoint Protection (SEP), prior to 14.2 RU2 & 12.1 RU6 MP10 and Symantec Endpoint Protection Small Business Edition (SEP SBE) prior to 12.1 RU6 MP10d (12.1.7510.7002), may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt t...
CVE-2019-12758
PUBLISHED: 2019-11-15
Symantec Endpoint Protection, prior to 14.2 RU2, may be susceptible to an unsigned code execution vulnerability, which may allow an individual to execute code without a resident proper digital signature.
CVE-2019-12759
PUBLISHED: 2019-11-15
Symantec Endpoint Protection Manager (SEPM) and Symantec Mail Security for MS Exchange (SMSMSE), prior to versions 14.2 RU2 and 7.5.x respectively, may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt to compromise the software applicat...
CVE-2019-18372
PUBLISHED: 2019-11-15
Symantec Endpoint Protection, prior to 14.2 RU2, may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt to compromise the software application to gain elevated access to resources that are normally protected from an application or user.