The rise and fall of 0day: A review of the year 0day was exploited in 2022

This is Google’s fourth annual review [2021, 2020, 2019] of 0day vulnerabilities exploited in the wild, and is based on the mid-2022 review. The purpose of this report is not to detail each individual vulnerability, but to analyze vulnerabilities throughout the year, looking for trends, gaps, lessons learned, and successes.

Summary

41 wild zero days were detected and disclosed in 2022, which is the second most recorded since tracking began in mid-2014, but down from the 69 detected in 2021. Although the 40% drop may seem like an obvious number to cut for improved safety, the reality is more complex. Some of our key takeaways for 2022 include:

Due to the longer patching time, N days function similarly to 0 days on Android. Across the Android ecosystem, there are multiple situations where patches are not available to users for an extended period of time. The attacker does not need a 0day vulnerability, but can use n days that act as 0days.

Zero-click exploits and new browser mitigations reduce browser zero-day vulnerabilities. Many attackers have turned to zero-click rather than one-click attacks. Zero-click usually targets components other than the browser. In addition, all major browsers have implemented new defenses that make exploiting vulnerabilities more difficult and may influence attackers to move to other attack surfaces.

The 0day vulnerabilities beyond 40% are variants of previously reported vulnerabilities. 17 of the 41 wild 0days from 2022 are variants of previously reported vulnerabilities. This continues an unpleasant trend we previously discussed in our 2020 Review Report and 2022 Interim Report. Over 20% is a variant of the wild 0day from 2021 and 2020 before.

Bug conflict is high. In 2022, reports of attackers using the same vulnerabilities as each other became more frequent, and security researchers also reported vulnerabilities that were later discovered to be used by attackers. When 0day vulnerabilities in the wild are discovered and patched against popular consumer platforms, it becomes increasingly possible to compromise vulnerabilities for other attackers as well.

Based on our analysis of 0days in 2022, we expect to see the industry continue to focus on the following areas:

  1. A more comprehensive and timely patch to resolve issues with variants and n days being used as 0 days.

  2. More platforms are following the browsers' lead and releasing broader mitigations to reduce the exploitability of entire classes of vulnerabilities.

  3. Transparency and collaboration between vendors and security maintainers continues to grow to share technical details and jointly detect exploit chains across multiple products.

From a numerical perspective

Of the 41 vulnerabilities detected and disclosed in 2022, none were found to account for a significant proportion of all detected 0day vulnerabilities. We see that they are relatively evenly distributed throughout the year: 20 in the first half and 21 in the second half. The combination of these two data points suggests that testing is more frequent and regular. We also found that the number of organizations believed to have 0days found in the wild remains high. Since 2021, 20 organizations have been recognized for 69 0day vulnerabilities detected. In 2022, 18 organizations were recognized for 41 wild zero-day events. It's promising that the number of organizations working on zero-day detection remains high, because we need as many people as possible to solve this problem.

There were 41 wild zero days detected and disclosed in 2022, down from 69 in 2021. Although it has dropped significantly from 2021, it still ranks second in 2022. All 0days we use for analysis are tracked in this spreadsheet.

The rise and fall of 0day: A review of the year 0day was exploited in 2022

 

The rise and fall of 0day: A review of the year 0day was exploited in 2022

0day quantity limit as a security indicator

The number of 0days detected and disclosed in the wild doesn't tell us much about the security posture. Instead, we use it as one of many indicators. By 2022, we believe that a combination of security improvements and regressions has resulted in a decline of approximately 40% in the number of 0-days detected and disclosed from 2021 to 2022, and a continued above-average number of 0-days that we see in 2022.

Both positive and negative changes will affect the rise and fall of the number of 0days in the wild. Therefore, we cannot use this number alone to indicate whether we are making progress in the fight to keep our users safe. Instead, we use that number to analyze which factors may have contributed to this result, and then review whether these factors are areas of success or areas that need to be addressed.

Example factors leading to an increase in the number of detections and disclosures of zero-days in the wild:

Security improvements - attackers need more 0days to maintain the same functionality

  • Discover and fix 0days faster

  • More entities publicly disclose known zero-day vulnerabilities

  • Add security boundaries to the platform

Safe regression - 0days are easier to discover and exploit

  • Variant analysis was not performed on the reported vulnerability

  • Exploit techniques are not mitigated

  • More exploitable vulnerabilities are added to the code than fixed

 

Examples of factors that have contributed to the decline in the number of detections and disclosures of in-the-wild zero-days:

Security Improvements - 0days require more time, money and expertise to develop and use

  • Fewer exploitable 0day vulnerabilities

  • Each new zero-day requires the creation of new exploit techniques

  • New vulnerabilities require new attack surfaces to be studied

Security regression - attackers need fewer 0days to maintain the same capabilities

  • Detecting 0days in the wild is slower, so bugs have longer life cycles

  • Extend the time for users to install patches

  • Less sophisticated attack methods: phishing, malware, n-day attacks are enough

 

Brainstorming different factors that could cause that number to rise and fall allows us to understand what's going on behind the number and draw conclusions from it. Two key factors leading to above-average organic 0day numbers in 2022 are: vendor transparency and variants. Vendors' continued work on detection and transparency is a clear win, but the high percentage of zero-day variants that make it into the wild isn't great. We discuss these variations in more depth in the Deja Vu section.

Likewise, we assess some of the key factors that may contribute to the decline in natural zero-day numbers from 2021 to 2022. Positive factors include a reduction in exploitable bugs, resulting in many attackers using different methods than one another, and negative impacts such as less sophisticated attack methods. Just as effective as 0day vulnerabilities, but slower at detecting 0days. The number of zero days in the wild alone does not tell us much about the status of wild utilization, but the various factors that affect this number are the real lessons. We'll explore these in depth in the following sections.

Do you need 0day on Android?

In 2022, throughout the Android ecosystem, we saw a series of cases where upstream manufacturers released patches for this issue, but downstream manufacturers did not accept the patches and release fixes for users to apply. Project Zero introduced one of these cases in its “Mind the Gap” blog post in November 2022.

These gaps between upstream vendors and downstream manufacturers allow n-days (well-known vulnerabilities) to act as 0-days because users have no readily available patches and their only defense is to stop using the device. While these gaps exist in most upstream and downstream relationships, they are more prevalent and longer lasting in Android.

This is a good case for attackers. An attacker can exploit a known n-day vulnerability but run it as a 0-day vulnerability because it applies to all affected devices. An example of this happening on Android in 2022 is CVE-2022-38181, a vulnerability in the ARM Mali GPU. The vulnerability was originally reported to the Android security team in July 2022 by Man Yue Mo, a security researcher at Github Security Labs. The Android security team subsequently decided that they considered the issue "unfixable" because it was "device-specific." However, the Android security department referred this issue to ARM. In October 2022, ARM released a new driver version that fixed the vulnerability. In November 2022, TAG discovered that the vulnerability was being used in the wild. Although ARM released a fixed driver version in October 2022, the vulnerability was not fixed by Android until April 2023, 6 months after ARM was first released and 9 months after it was first reported by Man Yue Mo. Found actively exploited in the wild after 5 months.

  • July 2022: Report to Android Security Team

  • August 2022: Android security marked "unfixable" and sent to ARM

  • October 2022: ARM fixes bug

  • November 2022: Vulnerabilities discovered in the wild

  • April 2023: Included in Android Security Bulletins

In December 2022, TAG discovered another exploit chain targeting the latest version of Samsung Internet Browser. At the time, the latest version of Samsung's internet browser ran on Chromium 102, which was released seven months ago in May 2022. As part of this chain, attackers were able to exploit two n-day vulnerabilities capable of running as 0days: CVE-2022-3038 (patched in Chrome 105 in June 2022) and in the ARM Mali GPU kernel driver CVE-2022-22706. ARM released a patch for CVE-2022-22706 in January 2022, and although it was flagged as an exploit in the wild, attackers were still able to use it as a 0day 11 months later. Although the vulnerability was widely exploited in January 2022, it was not included in an Android security bulletin until June 2023.

These n days that act as 0 days fall into the gray area of whether they are tracked as 0 days. In the past, we sometimes counted these as 0days: CVE-2019-2215 and CVE-2021-1048. In the case of these two vulnerabilities, the bugs have been fixed in the upstream Linux kernel, but no CVE has been assigned according to Linux standards. We include them because they were not identified as security issues that needed to be patched in Android before they were widely discovered. In the case of CVE-2022-38181, the bug was initially reported to Android, and ARM issued a security advisory for the issue, indicating that downstream users would need to apply the patches. We will continue to try to decipher this "grey area" of errors, but welcome input on how to track them down.

What browsers are like in 2021

Similar to the overall numbers, the number of detected zero-days targeting browsers in the wild dropped by 42% from 2021 to 2022, from 26 to 15. We assess this reflects efforts by browsers to make attacks more difficult. Overall, attacker behavior is shifting away from browsers toward zero-click attacks targeting other components on the device.

 

The rise and fall of 0day: A review of the year 0day was exploited in 2022

 

Advances in top browser defenses may impact the push of other components as initial vectors in exploit chains. Throughout 2022, we see more browsers launch and improve additional defenses against exploits. For Chrome, this is MiraclePtr, v8 Sandbox and libc++ enhancements. Safari introduced a lockdown mode, and Firefox introduced a more granular sandbox. Ki Chan Ahn, a vulnerability researcher and vulnerability developer at offensive security vendor Dataflow Security, commented during a Zer0Con keynote in April 2023 on how these types of mitigations make browser exploits more difficult and drive people to look elsewhere. attack surface.

 

Browsers are becoming increasingly difficult to exploit, and exploit delivery has continued to evolve over the past few years, which explains the decline in the number of browser bugs in 2022. In 2019 and 2020, a significant portion of the 0days detected in the wild were through watering hole attacks. A watering hole attack is when an attacker targets a group of people they believe will visit a website. Anyone who visits the site will be exploited and delivered the final payload (usually spyware). In 2021, we commonly see one-click links becoming the initial attack vector. Both watering hole attacks and one-click linking use the browser as the initial vector on the device. In 2022, more attackers are turning to zero-click exploits, which are exploits that can be triggered without user interaction. Zero clicks tend to target components of the device other than the browser.

 

In late 2021, Citizen Lab captured a zero-click vulnerability (CVE-2023-30860) targeting iMessage that NSO used in its Pegasus spyware. Project Zero details the vulnerability in this two-part blog post series. While no wild 0 hits have been publicly detected and disclosed in 2022, that doesn't mean there's a lack of usage. We are aware that multiple attackers have used and are currently using 0-click exploit chains.

Zero clicks are difficult to detect because:

  • their lifespan is short

  • There are usually no obvious signs of their presence

  • Many different components can be targeted, and vendors are not always even aware of all of the components that are remotely accessible

  • Deliver directly to the target, rather than being widely available like watering hole attacks

  • Typically not hosted on a navigable website or server

 

For one-click exploits, the target must click a visible link to deliver the exploit. This means that the target or security tool may detect the link. This link is then used to host the exploit on a navigable server.

Zero-click, on the other hand, typically targets code that handles incoming calls or messages, meaning they can often run before an indicator of an incoming message or call is displayed. This also greatly shortens their lifetime and the window in which they can be detected "alive". It is likely that attackers will continue to turn to zero-click exploits, so we as defenders need to focus on how to detect and protect users from these exploits.

Deja Vu: Complete patching remains one of the biggest opportunities

17 of the 41 0days discovered in the wild in 2022 were variants of previously disclosed vulnerabilities. We published relevant content for the first time in the 2020 review report "Deja vu-lnerability", pointing out that 25% in the wild 0days since 2020 is a variant of a previously disclosed bug. This number continues to rise, possibly due to:

  • Defenders are getting better at identifying variants,

  • Defender improves on detecting zero-day variants in the wild,

  • Attackers are leveraging more variants, or

  • The vulnerability fixes are not comprehensive enough, so more variants exist.

The answer is probably a combination of all of the above, but we know that the number of zero-day variants that can be exploited by users is not decreasing. Reducing the number of exploitable variants is one of the biggest areas of opportunity in the technology and security industries, forcing attackers to work harder to exploit zero-day vulnerabilities.

Not only are the 2020 wild 0day variants exceeding 40%, but the bugs exceeding 20% are all variants of previous wild 0days: 7 in 2021 and 1 in 2020. 0day is caught in the wild and it is a gift. Attackers don’t want us to know what vulnerabilities they have and the exploit techniques they are using. Defenders need to exploit this gift as much as possible and make it as difficult as possible for attackers to exploit 0day vulnerabilities again. This involves:

  • Analyze errors to find the true root cause, not just the way the attacker chose to exploit it in this situation

  • Look for other locations where the same error may exist

  • Evaluate any other paths that could be used to exploit the bug

  • Compare the patch to the true root cause and determine if there are any workarounds

We only consider a patch complete if it is both correct and comprehensive. A correct patch is one that fixes the bug with complete accuracy, meaning that it no longer allows the vulnerability to be exploited. A comprehensive patch applies everywhere the fix needs to be applied, covering all variants. When a single vulnerability or bug is exploited, there are often multiple ways to trigger the vulnerability, or multiple paths to access the vulnerability. Too often, we see vendors only block the paths shown in proof-of-concept or exploit examples, rather than fixing the vulnerability as a whole. Likewise, security researchers often report bugs without following up on how the patches work and exploring related attacks.

While the idea that incomplete patches make it easier for attackers to exploit zero days may make people uncomfortable, the flip side of this conclusion can give us hope. We have a clear path to making zero-days more difficult. If more vulnerabilities are patched correctly and comprehensively, it will be more difficult for attackers to exploit zero days.

We have listed all identified vulnerability variants in the table below. For a fuller look at how in-the-wild 0-day is variant, check out the presentation from the FIRST conference [video, slides], the slides from Zer0Con, the presentation from OffectiveCon [video, slides] CVE- 2022-41073, and this blog post about CVE-2022-22620.

Product

2022 ITW CVEs

Variant

Windows win32k

CVE-2022-21882

CVE-2021-1732 (2021 itw)

iOS IOMobileFrameBuffer

CVE-2022-22587

CVE-2021-30983 (2021 itw)

WebKit “Zombie”

CVE-2022-22620

Bug was originally fixed in 2013, patch was regressed in 2016

Firefox WebGPU IPC

CVE-2022-26485

Fuzzing crash fixed in 2021

Android in ARM Mali GPU

CVE-2021-39793 CVE-2022-22706

CVE-2021-28664 (2021 itw)

Sophos Firewall

CVE-2022-1040

CVE-2020-12271 (2020 itw)

Chromium v8

CVE-2022-1096

CVE-2021-30551 (2021 itw)

Chromium

CVE-2022-1364

CVE-2021-21195

Windows “PetitPotam”

CVE-2022-26925

CVE-2021-36942 – Patch was regressed

Windows “Follina”

CVE-2022-30190

CVE-2021-40444

(2021 itw)

Atlassian Confluence

CVE-2022-26134

CVE-2021-26084 (2021 itw)

Chromium Intents

CVE-2022-2856

CVE-2021-38000 (2021 itw)

Exchange SSRF “ProxyNotShell”

CVE-2022-41040

CVE-2021-34473 "ProxyShell"

Exchange RCE "ProxyNotShell"

CVE-2022-41082

CVE-2023-21529 "ProxyShell"

Internet Explorer JScript9

CVE-2022-41128

CVE-2021-34480

Windows “Print Spooler”

CVE-2022-41073

CVE-2022-37987

WebKit JSC

CVE-2022-42856

2016 bug discovered due to test failure

Exploits are not copyrighted

Unlike many commodities in the world, 0day itself is not limited. Just because one person discovers the existence of a zero-day vulnerability and develops it as an exploit does not prevent others from also independently discovering it and using it in their exploits. Most attackers who do their own vulnerability research and exploit development don't want others to do the same thing, as this reduces its value and makes it more likely to be quickly detected and fixed.

Over the past few years, we have become aware of a trend of large bug conflicts, where more than one researcher has discovered the same vulnerability. This happens between attackers who report bugs to vendors and security researchers. While bug conflicts happen all the time, and we can't measure the exact rate at which they occur, the number of different entities independently identified as the same vulnerability in security advisories, the same 0day found in two different vulnerabilities, and even the Conversations with researchers at also suggest that this is happening more frequently.

An increase in the number of false conflicts is a win for defenses because it means attackers are using fewer 0days overall. Limiting the attack surface and reducing the classes of exploitable bugs will certainly help researchers find the same bugs, but more security researchers publishing their research may also contribute. People read the same study and it sparks an idea for their next project, but it sparks similar ideas in many people. Platforms and attack surfaces are also becoming increasingly complex, requiring significant time investment to build expertise in new components or targets.

Security researchers and their vulnerability reports are helping to fix the same 0days that attackers are using, even if these specific 0days have not yet been detected in the wild, thereby compromising attackers' vulnerabilities. We hope that vendors continue to support researchers and invest in their bug bounty programs, as it helps fix the same vulnerabilities that may target users. It also highlights why it's important for security researchers to thoroughly patch known natural bugs and vulnerabilities.

What should we do now?

Looking back on 2022, our overall conclusion is that as an industry we are on the right path, but there are many areas of opportunity, the largest of which is the industry's response to reported vulnerabilities.

  • We must quickly provide fixes and mitigations to users so they can protect themselves.
  • We must perform detailed analysis to ensure the root cause of the vulnerability is addressed.
  • We must share as many technical details as possible.
  • We must take advantage of reported vulnerabilities to learn and fix as much as possible.

None of this is easy, and it’s no surprise to the security teams working in this space. It requires investment, prioritization, and development of a patching process that strikes a balance between protecting users quickly and ensuring it's comprehensive, which can be stressful at times. The investment required depends on each unique situation, but we see some common themes around people/resources, incentive structures, process maturity, automation/testing, release cadence, and partnerships.

In this post, we detail some of the efforts that help ensure bugs are properly and comprehensively fixed: including analysis of root causes, patches, variants, and exploit techniques. We will continue to help conduct these analyses, but we hope and encourage platform security teams and other independent security researchers to invest in these efforts as well.

Final Thoughts: TAG’s New Exploit Team

Looking ahead to the second half of 2023, we're excited about what's to come. You may notice that our previous reports have been posted on the Plan Zero blog. Our 0day in the wild program has moved from program zero to TAG in order to consolidate vulnerability analysis, detection and threat actor tracking expertise into one team, benefit from additional resources and ultimately achieve: TAG vulnerabilities! There's more to come, but we're very excited about what this means for protecting users from zero-day attacks and making zero-day attacks difficult.

Source: https://security.googleblog.com/2023/07/the-ups-and-downs-of-0-days-year-in.html

Original article by xbear, if reproduced, please credit https://cncso.com/en/the-ups-and-downs-of-0-days-year-in-html

Like (0)
Previous August 1, 2023 7:00 am
Next August 3, 2023 12:00 am

related suggestion