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.https://twitter.com/USCERT_gov/status/1260259518862286849 …
-
-
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.
Show this thread -
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).
Show this thread -
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).
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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?
Show this thread -
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).
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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.
Show this thread -
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]
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.