This is a list of the most commonly exploited vulnerabilities between 2016 and 2019, from CISA and FBI. Unfortunately they didn't share their methodology, but let's take a closer look at the CVEs, because I think the list shows an interesting trend.
1) CVE-2017-11882 - A stack overflow in Equation Editor (EQNEDT32.EXE) that was accessible via Microsoft Office documents. Crucially, neither DEP or ASLR was enabled on this binary, meaning that the issue was trivially exploitable.
2) CVE-2017-0199 - Logic/design flaw in embedded HTA documents, exploited via Microsoft Office documents. This issue was originally exploited as a 0day by FINSPY and LATENTBOT.
3) CVE-2017-5638 - Parsing bug in Apache Struts 2. Attackers could use Object Graph Navigation Language (OGNL) to execute arbitrary commands on the target host, e.g. this issue is trivially exploitable. Here's a snippet of the payload: ".(#cmd='whoami')."
4) CVE-2012-0158 - Buffer overflow vulnerability in MSCOMCTL.OCX that was typically exploited via Microsoft Office documents. This issue was originally exploited as a 0day (e.g. "Microsoft is aware of limited, targeted attacks attempting to exploit the vulnerability.).
5) CVE-2019-0604 - Parsing bug in Microsoft SharePoint. SharePoint would deserialize XML such that attackers could control the type of the deserialized object. This issue is trivially exploitable once you know which object to instantiate to achieve remote code execution.
6) CVE-2017-0143 - This is a type confusion vulnerability in Microsoft Windows' SMB implementation, also known as EternalSynergy. This issue was originally exploited as a 0day (we can reliably infer this given the context of the disclosure).
7) CVE-2018-4878 - Use-after-free in Adobe Flash's MediaPlayer DRM Listener. This issue was originally exploited as a 0day by ScarCruft/APT37/Reaper. This issue was commonly exploited via Office documents (remember that Flash became sandboxed in Chrome in late 2016).
8) CVE-2017-8759 - Code injection vulnerability in Microsoft's SOAP WSDL parser. Again, the preferred delivery mechanism was through Microsoft Office documents. This issue was originally exploited as a 0day by BlackOasis.
9) CVE-2015-1641 - Type confusion in Microsoft Office's parsing of SmartTag elements. This issue was originally exploited as a 0day, but we don't have any attribution data available. For ASLR, the exploit used the fact that MSVCR71.DLL was loaded at a fixed address in Windows 7.
10) CVE-2018-7600 - This was a remote code execution vulnerability in Drupal, also known as Drupalgeddon. Attacker-controlled content could be evaluated as PHP. This issue was trivially exploitable, since attackers could call PHP's exec function with arbitrary parameters.
Out of the ten CVEs listed, six were originally exploited as 0day, and four were trivially exploitable (three logic bugs, and one target with no DEP/ASLR). What does this tell us?
Opportunistic attackers are either waiting for bugs that require no additional R&D (design flaws, logic bugs, other easily exploitable conditions), or waiting for fully developed and reliable exploits to become available (typically when a 0day is leaked or detected).
Importantly, attackers aren't using publicly disclosed security research in the same way that they used to, except when a bug is extraordinarily trivial to exploit. And the chances that we can stop attackers from learning about those bugs through patch analysis is very low.
Even if all security researchers globally stopped publishing technical data on their discoveries, and also agreed never to publish patch analysis or binary diffing results, attackers would still have a plentiful supply of exploits that were originally detected as 0day.
I'd quickly note that Project Zero has disclosed technical details for over 1700 bugs, and none of our issues are in the top 10. On the flip side, there is a huge defensive benefit from sharing data about how different attacks work and how to build structural defenses for them.
A lot of vendors have asked us to redact technical details from our bug reports at various points. I understand where this comes from -- fear of the unknown, fear that their users will be harmed, and fear of bad press for their product. Let's not make decisions based on fear.
Observable user harm is disproportionately coming from the fallout of 0day exploits being leaked/detected, and from a handful of trivially exploitable bugs. It's not coming from security researchers disclosing messaging app bugs, browser exploits, or kernel priv-escs.
These disclosures still have an important purpose: raising awareness about the capabilities of 0day exploits, teaching the next generation of researchers, driving change at vendors/OSS projects, motivating follow-up research/investment, etc.
But it's very rare that a vulnerability disclosure meaningfully increases attacker capability, relative to their existing capability. And compared to silent fixes or non-disclosure, the net result of vulnerability disclosure is overwhelmingly better for defensive outcomes.
So on the sweeping claims of irresponsible disclosure, emotion-driven policy making, assumptions of bad faith. Let's talk about models, data, and forecasting instead. I think we can make some very good predictions about which CVEs are likely to cause significant user harm.
Finally, let's redirect some of that energy towards the attackers who develop and deploy (often recklessly deploy) 0day exploits, which leads to many years of unintended fallout and expensive cleanups after their exploits are leaked or discovered. The damage is enormous. [END]
