Thread by @LeaKissner

Kicking off the next session at #enigma2021 is @maddiestone with "THE STATE OF 0-DAY IN-THE-WILD EXPLOITATION"

usenix.org/conference/eni…

What do you think of when I say 0-day? Only the most elite hackers and most elite targets, that they're super hard and expensive to develop.

I started looking back over what we're really seeing in the wild, looking at all of these bugs together to look at the bugs and gaps.

It became clear that we are not requiring the most elite skills to exploit 0-days. But there are mitigations that can make it much harder.

What is a 0-day: an exploit targeting a vulnerability that the defender doesn't know about (yet).

My work is on 0-days in the wild to make it easier to defend against these and why I'm writing a year in review.

24 0-days exploits detected in the wild

6/24 (25%) are variants of previously-disclosed vulnerabilities. Only a few lines changed in some places.

3/24 were exploiting vulnerabilities which were incompletely patched.

[Oh no.]

Lesson: Across the industry, we're making it way too easy to exploit incompletely-fixed vulns

Example: Internet Explorer Jscript

Just look at that chain of reports leading to more and more CVEs because patches didn't actually... patch.

The same attacker exploited *all* of these, according to Google's Threat Analysis Group. To trigger them, usually only 1-2 lines of code needed to be changed.

It's a use-after-free vuln [please see the talk for a more detailed explanation]

And now more trivial variants!

It's not hard. Once you understand a single one of those bugs, you can just tweak and have more zero-days.

This case study in Chrome is a little different, showing incomplete patching.

At the time this Chrome bug was fixed, it wasn't known that it was a vulnerability; that came several months later when we found it being exploited in the wild.

This shows that we need to *always* patch completely, not just when we know it's a security issues.

Chrome patched, then patched better, which introduced a new issue, which then had to get patched quickly again.

This vulnerability is because the "integer" type can also be +infinity and -infinity which can cause issues where subms end up as NaN (not a number).

So first they patched it... partly.

So we have to think through what is the root cause vulnerability and make sure there are not other ways to trigger the same thing.

Arbitrary pointer dereference in Windows splwow64

This one is where something was patched, but there was still a trivial variant exploitable... and then again.

Sending a message type 0x75 will allow the attacker to control all the parameters, so can be used to read and write by the attacker. Using different messages type could still be used after patch. Then they patched by using offsets, but that didn't fix it.

We have a problem! We're not making exploiting 0-days hard enough. You don't need elite skills -- you can keep re-using vulns!

We need correct and comprehensive patches. Patch *all* the instances in the codebase, not just the one.

What do we do as researchers:
* analyze patches
* variant analysis
* offer to work with vendors on patches
* incentivize vendors for complete patches

What do we do as vendors?
* Complete and comprehensive patches
* Work with researchers to give feedback on patches before release
* fix classes not just bugs
* build mitigations into products

What do we do as users?
* hold vendors accountable
* call them!

We need correct and comprehensive patches for all 0-day vulnerabilities.

Want more? Check out these references [@maddiestone would you mind linking these here?]