CDM-CYBER-DEFENSE-eMAGAZINE-March-2019
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Schrodinger’s vulnerability<br />
Using exploitability to avoid chasing phantom risk<br />
By Alex Haynes, Head of Information Security, CDL<br />
I recently laid eyes on a pentesting report which had the gravest of warnings. ‘The host may be<br />
vulnerable to remote code execution’. Dear lord, did they get system access on a host? Nope.<br />
Was there a public exploit available for that version of software that enabled remote code<br />
execution? No again. Well why would someone make such a vague alarmist recommendation?<br />
When I queried this, their logic was that even though there was no public exploit available for that<br />
version of software, someone somewhere might have developed one but was keeping it secret.<br />
Also, since it’s a secret exploit that no one knows about, it could also be remote code execution<br />
because that’s the most common exploit right?<br />
This is a tongue in cheek analysis of what has reached critical mass in the pentesting industry<br />
and is now dubbed ‘Pentester syndrome’, the act of making things worse than they appear. You<br />
are now delivered reports full of junk risk without any kind of proof of concept with far-fetched<br />
contrived scenarios that will never occur (and have never befallen any company at all). Among<br />
other things this has led to the rise of crowdsourced security, with many of the world’s biggest<br />
brands ditching pentesting entirely – as it only delivers actionable vulnerabilities with proof of<br />
concept due to the nature of their reward models (researchers are only paid if they can exploit a<br />
working vulnerability and deliver a proof of concept).<br />
But back to the original issue. Is out of date software automatically vulnerable? Hardly. Many<br />
software version upgrades stem from functionality changes, not security updates. Even those that<br />
are for security reasons are for patching specific flaws in the code, or a readily available public<br />
exploit. When you trawl through an exploit database, the exploits often refer to very specific<br />
vectors that can only be delivered if the configuration of the asset in question is of a particular