2023/6/6 15:52
Project Zero: 2022 0-day In-the-Wild Exploitation…so far
More
4b5f5f4b@gmail.com
Dashboard
Sign Ou
Project Zero
News and updates from the Project Zero team at Google
Search This Blog
T h u r s d a y, J u n e 3 0 , 2 0 2 2
Search
2022 0-day In-the-Wild Exploitation…so far
Pages
Posted by Maddie Stone, Google Project Zero
About Project Zero
This blog post is an overview of a talk, “ 0-day In-the-Wild Exploitation in 2022…so far”, that I gave at the
FIRST conference in June 2022. The slides are available here.
Working at Project Zero
0day "In the Wild"
0day Exploit Root Cause Analyses
For the last three years, we’ve published annual year-in-review reports of 0-days found exploited in the wild.
The most recent of these reports is the 2021 Year in Review report, which we published just a few months
Vulnerability Disclosure FAQ
ago in April. While we plan to stick with that annual cadence, we’re publishing a little bonus report today
looking at the in-the-wild 0-days detected and disclosed in the first half of 2022.
Archives
As of June 15, 2022, there have been 18 0-days detected and disclosed as exploited in-the-wild in 2022.
When we analyzed those 0-days, we found that at least nine of the 0-days are variants of previously patched
vulnerabilities. At least half of the 0-days we’ve seen in the first six months of 2022 could have been
prevented with more comprehensive patching and regression tests. On top of that, four of the 2022 0-days
are variants of 2021 in-the-wild 0-days. Just 12 months from the original in-the-wild 0-day being patched,
attackers came back with a variant of the original bug.
Product
2022 ITW 0-day
Variant
Windows win32k
CVE-2022-21882
CVE-2021-1732 (2021 itw)
iOS IOMobileFrameBuffer
CVE-2022-22587
CVE-2021-30983 (2021 itw)
Windows
CVE-2022-30190 (“Follina”)
CVE-2021-40444 (2021 itw)
Chromium property access
interceptors
CVE-2022-1096
CVE-2016-5128 CVE-202130551 (2021 itw) CVE-20221232 (Addresses incomplete
CVE-2022-1096 fix)
Chromium v8
CVE-2022-1364
CVE-2021-21195
WebKit
CVE-2022-22620 (“Zombie”)
Bug was originally fixed in
2013, patch was regressed in
2016
Google Pixel
CVE-2021-39793*
Linux same bug in a different
subsystem
* While this CVE says 2021, the bug
was patched and disclosed in 2022
Atlassian Confluence
CVE-2022-26134
CVE-2021-26084
Windows
CVE-2022-26925 (“PetitPotam”)
CVE-2021-36942 (Patch
regressed)
So, what does this mean?
When people think of 0-day exploits, they often think that these exploits are so technologically advanced that
there’s no hope to catch and prevent them. The data paints a different picture. At least half of the 0-days
we’ve seen so far this year are closely related to bugs we’ve seen before. Our conclusion and findings in the
2020 year-in-review report were very similar.
Many of the 2022 in-the-wild 0-days are due to the previous vulnerability not being fully patched. In the case
of the Windows win32k and the Chromium property access interceptor bugs, the execution flow that the
proof-of-concept exploits took were patched, but the root cause issue was not addressed: attackers were
C
able to come back and trigger the original vulnerability through a different path. And in the case of the
WebKit and Windows PetitPotam issues, the original vulnerability had previously been patched, but at some
point regressed so that attackers could exploit the same vulnerability again. In the iOS IOMobileFrameBuffer
https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html
1/3
2023/6/6 15:52
Project Zero: 2022 0-day In-the-Wild Exploitation…so far
bug, a buffer overflow was addressed by checking that a size was less than a certain number, but it didn’t
check a minimum bound on that size. For more detailed explanations of three of the 0-days and how they
relate to their variants, please see the slides from the talk.
When 0-day exploits are detected in-the-wild, it’s the failure case for an attacker. It’s a gift for us security
defenders to learn as much as we can and take actions to ensure that that vector can’t be used again. The
goal is to force attackers to start from scratch each time we detect one of their exploits: they’re forced to
discover a whole new vulnerability, they have to invest the time in learning and analyzing a new attack
surface, they must develop a brand new exploitation method. To do that effectively, we need correct and
comprehensive fixes.
This is not to minimize the challenges faced by security teams responsible for responding to vulnerability
reports. As we said in our 2020 year in review report:
Being able to correctly and comprehensively patch isn't just flicking a switch: it requires investment,
prioritization, and planning. It also requires developing a patching process that balances both
protecting users quickly and ensuring it is comprehensive, which can at times be in tension. While we
expect that none of this will come as a surprise to security teams in an organization, this analysis is a
good reminder that there is still more work to be done.
Exactly what investments are likely required depends on each unique situation, but we see some
common themes around staffing/resourcing, incentive structures, process maturity,
automation/testing, release cadence, and partnerships.
Practically, some of the following efforts can help ensure bugs are correctly and comprehensively fixed.
Project Zero plans to continue to help with the following efforts, but we hope and encourage platform security
teams and other independent security researchers to invest in these types of analyses as well:
●
Root cause analysis
Understanding the underlying vulnerability that is being exploited. Also tries to understand
how that vulnerability may have been introduced. Performing a root cause analysis can help
ensure that a fix is addressing the underlying vulnerability and not just breaking the proof-ofconcept. Root cause analysis is generally a pre-requisite for successful variant and patch
analysis.
●
Variant analysis
Looking for other vulnerabilities similar to the reported vulnerability. This can involve looking
for the same bug pattern elsewhere, more thoroughly auditing the component that contained
the vulnerability, modifying fuzzers to understand why they didn’t find the vulnerability
previously, etc. Most researchers find more than one vulnerability at the same time. By finding
and fixing the related variants, attackers are not able to simply “plug and play” with a new
vulnerability once the original is patched.
●
Patch analysis
Analyzing the proposed (or released) patch for completeness compared to the root cause
vulnerability. I encourage vendors to share how they plan to address the vulnerability with the
vulnerability reporter early so the reporter can analyze whether the patch comprehensively
addresses the root cause of the vulnerability, alongside the vendor’s own internal analysis.
●
Exploit technique analysis
Understanding the primitive gained from the vulnerability and how it’s being used. While it’s
generally industry-standard to patch vulnerabilities, mitigating exploit techniques doesn’t
happen as frequently. While not every exploit technique will always be able to be mitigated,
the hope is that it will become the default rather than the exception. Exploit samples will need
to be shared more readily in order for vendors and security researchers to be able to perform
exploit technique analysis.
Transparently sharing these analyses helps the industry as a whole as well. We publish our analyses at this
repository. We encourage vendors and others to publish theirs as well. This allows developers and security
professionals to better understand what the attackers already know about these bugs, which hopefully leads
to even better solutions and security overall.
Posted by Google Project Zero at 6:00 AM
C
No comments:
https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html
2/3
2023/6/6 15:52
Project Zero: 2022 0-day In-the-Wild Exploitation…so far
Post a Comment
Newer Post
Home
Older Post
Subscribe to: Post Comments (Atom)
Powered by Blogger.
C
https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html
3/3