Schrodinger’s vulnerability

Using exploitability to avoid chasing phantom risk

By Alex Haynes, Head of Information Security, CDL

I recently laid eyes on a pentesting report which had the gravest of warnings. ‘The host may be vulnerable to remote code execution’. Dear lord, did they get system access on a host? Nope. Was there a public exploit available for that version of the software that enabled remote code execution? No again. Well, why would someone make such a vague alarmist recommendation? When I queried this, their logic was that even though there was no public exploit available for that version of the software, someone somewhere might have developed one but was keeping it secret. Also, since it’s a secret exploit that no one knows about, it could also be remote code execution because that’s the most common exploit right?

This is a tongue in cheek analysis of what has reached critical mass in the pentesting industry and is now dubbed ‘Pentester syndrome’, the act of making things worse than they appear. You are now delivered reports full of junk risk without any kind of proof of concept with far-fetched contrived scenarios that will never occur (and have never befallen any company at all). Among other things this has led to the rise of crowdsourced security, with many of the world’s biggest brands ditching pentesting entirely – as it only delivers actionable vulnerabilities with proof of concept due to the nature of their reward models (researchers are only paid if they can exploit a working vulnerability and deliver a proof of concept).

But back to the original issue. Is out of date software automatically vulnerable? Hardly. Many software version upgrades stem from functionality changes, not security updates. Even those that are for security reasons are for patching specific flaws in the code, or a readily available public exploit. When you trawl through an exploit database, the exploits often refer to very specific vectors that can only be delivered if the configuration of the asset in question is of a particular kind. Many of them require some kind of privileged access already and as I alluded to earlier, remote code execution is exceedingly rare.

This brings us to Schrodinger’s vulnerability, a play on the oft used trope of Schrodinger’s cat, which to paraphrase implies that until you look in the box, the cat is both alive and dead. A more contemporary reference would be the response that former Secretary of Defense Donald Rumsfeld once blurted out in reference to ‘known knowns’, ‘known unknowns’ and ‘unknown unknowns’ with the latter being the riskiest.

Let’s map this to an information asset today and call-back the alarmist reference I started this article with on. This information asset that is out of date but might have a vulnerability even there are none publicly available is going into the region of ‘unknown unknowns’. We know there are no publicly available vulnerabilities but there may be a vulnerability that exists that we just don’t know about. So how probable is this? Fortunately, there’s no need to speculate since there’s plenty of research to draw conclusions from. ‘Zero days, Thousands of Nights: The Life and Times of Zero-Day vulnerabilities and their Exploits’ is a piece of research by Lillian Ablon and Andy Bogart that focuses on this very issue. They found that if a zero-day existed and was hoarded by an entity but kept from public view, it would stay that way for an average of 7 years.

What this means for us is that regardless of what version of the software you are on, there may be a zero-day that exist (however improbable) but no one will know about it and it will stay that way for an average of 7 years. What’s worse is that if you update your software to the latest version, then that version too may also contain this zero-day, even though you are ‘fully patched’, simply because the code refactoring in the new version has not taken into the account the zero-day by virtue of the fact that it’s still an unknown. The research does make a distinction for the end of life software, since this will never be patched again, so if a new zero-day is discovered then it effectively becomes ‘immortal’ since the vendor will never release a new patch to cover this.

Using exploitability for defense

Combining a few approaches can stave off junk risk and avoid you chasing contrived scenarios that will never materialize:

• Switch from pentesting to crowdsourced security for external assets: Pentesting methodology is starting to be considered a legacy approach to offensive security testing. It does not emulate a hacker in any way – it only gives you a frozen snapshot of security posture at a specific point in time, nothing more. Crucially, crowdsourced also gives you actionable threats with proof of concept and their methodology maps more realistically to how attackers behave (for example, no time limit on testing), while pentesting focuses on theoretical threats.
• Having out of date software doesn’t mean you’re automatically vulnerable! While this may shock some individuals, if the specific threat vector that your version of the software is vulnerable to isn’t exposed in its current configuration, then you are safe.
• Practically all attacks focus on known vulnerabilities so updating your software to the latest version to protect against ‘zero-day’ attacks is irrelevant. The new version is as likely to be vulnerable since no code has been refactored to account for the zero-day, hence its unknown status. Updating software is for known threats, not unknown ones.
• Even if you are exposed to a vulnerability, what are the steps needed for it to materialize? The likelihood of many vulnerabilities drops to almost zero once you factor in the first two variables required: Someone has to want to hurt you and someone has the skill level to exploit that vulnerability. The former is more common than the latter, as an offensive security skillset is still so rare nowadays even in professionals who work within information security.
• Examine your threat model and know who your bad actors are. Are you protecting against nation-state attackers or script kiddies with the slap? Many vulnerabilities that focused on a contrived chain of attacks or any kind of physical proximity (think Bluetooth and Wi-Fi vulnerabilities for example) will never materialize unless you are subjected to a specifically targeted attack that requires the physical deployment of malicious attackers to your geographical location. Aside from nation-state attackers, this has never occurred so chase things that are likely to occur (remote attacks on your assets exposed to the internet) rather than those that won’t (Someone taking over your Alexa with a Bluetooth vulnerability to pivot into your network).

Naturally, I’m not advocating not updating your systems. It’s a good practice to get into but for many operational and human reasons, many systems are just left behind in the scrum. When you have limited resources a view on ‘exploitability’ rather than ‘vulnerability’ can help manage risk far better than chasing down every single vulnerability that exists on your assets. If you take into consideration your threat model, and then sift through your external assets first viewing vulnerabilities through the lens of ‘exploitability’ you will be able to make your infrastructure far safer than chasing Schrodinger’s vulnerability.

About the Author

Alex Haynes is CISO at CDL. He has a background in offensive security and is credited for discovering vulnerabilities in products by Microsoft, Adobe, Pinterest, Amazon Web Services, IBM and many more. He is a former top 10 ranked researcher on Bugcrowd – a vulnerability disclosure platform with over 400 vulnerabilities to his name.