Attacker Value
High
(1 user assessed)
Exploitability
Moderate
(1 user assessed)
User Interaction
None
Privileges Required
Low
Attack Vector
Local
5

CVE-2021-1732

Disclosure Date: February 25, 2021
Exploited in the Wild
Add MITRE ATT&CK tactics and techniques that apply to this CVE.
Privilege Escalation
Techniques
Validation
Validated

Description

Windows Win32k Elevation of Privilege Vulnerability This CVE ID is unique from CVE-2021-1698.

Add Assessment

5
Ratings
Technical Analysis

A very interesting vulnerability in win32kfull.sys on Windows 10 devices up to and including 20H2. Although the exploit in the wild specifically targeted Windows 10 v1709 to Windows 10 v1909, as noted at https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/, the researchers noted that the vulnerability could be modified to work on Windows 20H2 with minor modifications.

From my perspective this is rather significant, particularly given this is a win32kfull.sys bug we are talking about here. Most of the primitives that made win32k exploitation easier were entirely wiped out by Microsoft which prompted a lot of researchers who previously spoke publicly about such primitives in conference talks and similar to go quiet. Whilst rumor has been that there were other primitives one could use for exploitation, they were considered closely guarded secrets due to the difficulty in finding them and the fact that Microsoft would be likely to patch them very quickly.

The new primitive that is used here appears to be setting tagMenuBarInfo.rcBar.left and tagMenuBarInfo.rcBar.top and then calling GetMenuBarInfo(), which allows one to perform an arbitrary read in kernel memory. This has not been discussed before but is similar to another concepted discussed in the paper “LPE vulnerabilities exploitation on Windows 10 Anniversary Update” at ZeroNights which mentioned using two adjacent Windows and then setting the cbwndExtra field of the first window to a large value to allow the first window to set all of the properties of the second window. By chaining this together the attacker could achieve an arbitrary read and write in kernel memory.

The bug itself stems from a xxxClientAllocWindowClassExtraBytes() callback within win32kfull!xxxCreateWindowEx. Specifically when xxxCreateWindowEx() creates a window object with a cbwndExtra field set, aka it has extra Window bytes, it will perform a xxxClientAllocWindowClassExtraBytes() callback to usermode to allocate the extra bytes for the Window.

You may be wondering why such callbacks are needed. Well a long time ago Windows used to handle all its graphics stuff in kernel mode, but then people realized that was too slow given increasing demands for speed, so they made most of the code operate in usermode with key stuff handled by kernel mode. This lead to a big rift and is the reason we have callbacks. Thats the nutshell version anyway but go read up on http://mista.nu/research/mandt-win32k-slides.pdf and https://media.blackhat.com/bh-us-11/Mandt/BH_US_11_Mandt_win32k_WP.pdf if you want to learn more. Its a fascinating read :)

Anyway back on topic. Since xxxClientAllocWindowClassExtraBytes() is a callback that is under the attackers controller, the attacker can set a hook that will trigger when a xxxClientAllocWindowClassExtraBytes() callback is made and call NtUserConsoleControl() with the handle of the window that is currently being operated on. This will end up calling xxxConsoleControl() in kernel mode which will set *((tagWND+0x28)+0x128) to an offset, and will AND the flag at *((tagWND+0x28) + 0xE8) with 0x800 to indicate that the value of the WndExtra member is an offset from the base address of RtlHeapBase. Unfortunately, whatever value is returned by the hooked xxxClientAllocWindowClassExtraBytes() callback (aka whatever value the attacker chooses) will be used as the value of WndExtra, since remember we are meant to be allocating the address of this field at the time due to the earlier xxxCreateWindowEx() call needing to allocate memory for WndExtra.

Once this is done, the callback will be completed, execution will return to usermode, and a call to DestroyWindow() will be made from usermode. This will cause xxxDestroyWindow() to be called in kernel mode which will call xxxFreeWindow(), which will check if *((tagWND+0x28) + 0xE8) has the flag designated by 0x800 set, which it will due to the alterations made by xxxConsoleControl(). This will then result in a call to RtlFreeHeap() which will attempt to free an address designated by RtlHeapBase + offset, where offset is the value of WndExtra (which is taken from the xxxClientAllocWindowClassExtraBytes() callback and therefore completely controlled by the attacker).

This subsequently results in the attacker being able to free memory at an arbitrary address in memory.

I’ll not dive into a full detailed analysis of the rest of the exploitation steps as the article at https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/ is very comprehensive but I will say from what I’ve read there, there is enough detail that people of a decent skill level could probably recreate this exploit. It certainly isn’t an easy exploit to recreate but the exploit goes into a lot of detail about the various mitigation bypasses that were used to make this exploit possible, which could help an attacker more readily recreate this bug.

Again, this exploit was exploited in the wild so it is possible for this bug to be recreated, it just might take some time for people to work out a few of the specifics needed to get a working exploit. If you are running Windows 10, it is highly advised to upgrade as soon as possible: everything I am reading here points to signs that this will be weaponized within the coming few weeks or months.

Additionally it should be noted that this exploit was noted to be capable of escaping Microsoft IE’s sandbox (but not Google Chrome’s) so if you are running Microsoft IE within your environment, its even more imperative that you patch this issue to prevent an attacker from combining this with an IE 0day and conducting a drive by attack against your organization, whereby simply browsing a website could lead to attackers gaining SYSTEM level privileges against affected systems.

CVSS V3 Severity and Metrics
Base Score:
7.8 High
Impact Score:
5.9
Exploitability Score:
1.8
Vector:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector (AV):
Local
Attack Complexity (AC):
Low
Privileges Required (PR):
Low
User Interaction (UI):
None
Scope (S):
Unchanged
Confidentiality (C):
High
Integrity (I):
High
Availability (A):
High

General Information

Vendors

  • Microsoft

Products

  • Windows,
  • Windows Server,
  • Windows 10 Version 1909 for 32-bit Systems,
  • Windows 10 Version 1909 for x64-based Systems,
  • Windows 10 Version 1909 for ARM64-based Systems,
  • Windows Server, version 1909 (Server Core installation),
  • Windows 10 Version 2004 for 32-bit Systems,
  • Windows 10 Version 2004 for ARM64-based Systems,
  • Windows 10 Version 2004 for x64-based Systems,
  • Windows Server, version 2004 (Server Core installation),
  • Windows 10 Version 20H2 for x64-based Systems,
  • Windows 10 Version 20H2 for 32-bit Systems,
  • Windows 10 Version 20H2 for ARM64-based Systems,
  • Windows Server, version 20H2 (Server Core Installation)

Exploited in the Wild

Reported by:
Reported: February 09, 2021 6:45pm UTC (2 months ago)
Technical Analysis