Technical Evaluation of CVE-2021-1732 | McAfee Blogs

Introduction

In February 2021, the corporate Dbappsecurity found a pattern within the wild that exploited a zero-day vulnerability on Home windows 10 x64.

The vulnerability, CVE-2021-1732, is a win32k window object sort confusion resulting in an OOB (out-of-bounds) write which can be utilized to create arbitrary reminiscence learn and write capabilities inside the Home windows kernel (native Elevation of Privilege (EoP)). Reminiscence exploitation usually requires a learn, write, and execute primitive to bypass trendy exploit mitigations comparable to DEP, ASLR and CFG on hardened working techniques comparable to Home windows 10. A data-only assault requires solely a learn and write primitive because it doesn’t search to execute malicious code in reminiscence, however fairly manipulates knowledge buildings utilized by the working system to its benefit (i.e., to realize elevated privileges).

Kernel exploits are often probably the most refined assault as they work together immediately with the Home windows kernel. When such assaults are profitable, they’re essential as a result of they supply excessive privileges to the attacker, which can be utilized to extend the impression of the general exploit chain. On this case the exploit is a Native Privilege Escalation (LPE) that targets 64-bit Home windows 10 model 1909. The unique pattern found was compiled in Could 2020 and reported to Microsoft in December 2020. Whereas looking for extra findings we went by a public exploit printed in March of 2021 by a researcher. Having this code publicly accessible could elevate the potential for added risk attackers. Whereas we now have not discovered clear proof demonstrating malicious use of the proof-of-concept (POC), we did uncover some variants being examined and uploaded to VirusTotal.

On this weblog put up, McAfee Superior Menace Analysis (ATR) carried out a deep dive into the evaluation of the vulnerability, to determine the primitives for detection and safety. The exploit is novel in its use of a brand new win32k arbitrary kernel reminiscence learn primitive utilizing the GetMenuBarInfo API, which to the very best of our information had not been beforehand identified publicly.

CVE-2021-1732 Deep Dive

Exploitation of CVE-2021-1732 might be divided into six levels with the top aim of escalating a course of’ privileges to System. The next diagram reveals the levels.

Earlier than we dive into the main points, we should give some background to win32k exploitation primitives that are used within the exploitation of CVE-2021-1732.

Win32K Background

Win32k is a Graphical (GUI) element of the Microsoft Home windows Subsystem, most of which exists within the kernel for efficiency causes. It’s used for graphical print of the Home windows OS desktop. Nonetheless, because of the win32k structure, the kernel element of win32k nonetheless wants to have the ability to make calls to consumer mode by user-mode callback features to facilitate window creation and administration.

Kernel user-mode callbacks have been effectively researched way back to 2008 and 2010, with a really complete evaluation in 2011 by Mandt. A win32k kernel operate comparable to xxxCreateWindowEx will make a callback operate comparable to xxxClientAllocWindowClassExtraBytes by the consumer course of PEB KernelCallbackTable.

When the user-mode callback has accomplished, NtCallbackReturn executes and passes the anticipated return parameter again to the kernel. Because of the stateless nature of those callbacks, many vulnerabilities have been found associated to the locking mechanisms on the objects resulting in use-after-free (UAF) exploitation.

Win32k has been one of the exploited elements within the Home windows kernel accounting for 63% of vulnerabilities from 2010 to 2018, as a consequence of its giant assault floor of syscalls relative to ntdll syscalls. Win32k vulnerabilities are usually changed into data-only assaults utilizing a learn/write kernel primitive through the use of a desktop object often called a tagWND knowledge construction.

There are two elements to data-only assaults:

1. Discovering a vulnerability.
2. Leveraging current or new learn/write primitives utilizing particular OS APIs on object fields comparable to tagWND.cbWndExtra.

The tagWND knowledge construction has two fields which make it a chief goal for studying/writing inside kernel reminiscence; tagWND.cbWndExtra and tagWND.ExtraBytes. When a window is created utilizing CreateWindowEx, it’s potential to request extra bytes of reminiscence immediately after the tagWND object in reminiscence by the cbWndExtra subject within the WNDCLASSEXA construction when registering the window class.

The variety of additional bytes is managed by the cbWndExtra subject, and the allotted extra reminiscence deal with is situated on the ExtraBytes subject. The learn/write primitive is created as follows:

1. Uncover a vulnerability comparable to a UAF, which is able to will let you write to a tagWND object in reminiscence known as WND0.
2. Allocate one other tagWND object known as WND1 close to the beforehand corrupted WND0 in reminiscence.
3. Overwrite WND0.cbWndExtra to a big worth comparable to 0xFFFFFFF.
4. Name an API comparable to SetWindowLongPtr on WND0 which is able to write OOB to fields inside WND1.

Win32k kernel user-mode callbacks have been exploited many occasions by leveraging tagWND learn/write capabilities inside the Home windows kernel for escalation of privileges comparable to CVE-2014-4113, CVE-2015-0057, MS15-061, CVE-2016-7255 and CVE-2019-0808.

Win32k Exploit Primitives

A number of primitives have been noticed within the CVE-2021-1732 exploit utilized by the attackers; moreover, it’s value mentioning that a few of them are new and never beforehand seen within the wild.

Previous to Home windows RS4 it was trivial to leak tagWND kernel addresses utilizing a number of strategies, comparable to calling HMValidateHandle to repeat tagWND objects from the kernel to consumer desktop heap. The newest model of Home windows 10 has been hardened towards such trivial strategies.

Nonetheless, utilizing the spmenu kernel deal with leak method and relative tagWND desktop heap offsets, as soon as a vulnerability is found to overwrite a tagWND.cbWndExtra subject, it’s potential to realize kernel learn/write capabilities with out leaking the precise tagWND kernel addresses. The spmenu method on this exploit was used right here and right here, however we’re not conscious of the GetMenuBarInfo API ever getting used earlier than in a win32k exploit.

The next diagram reveals the primitives utilized in CVE-2021-1732.

Current Home windows OS Mitigations

Nice work has been performed to harden the safety of win32k towards EoP assaults with new and improved mitigations by the Microsoft OSR workforce, Mandt, Google Undertaking Zero, Schenk and Dabah.  These mitigations embody:

1. Kind isolation (all identical sort objects tagWND getting used).
2. Win32k filtering (restricted to Edge browser and never course of large however since this analysis there have been many enhancements on win32k API filtering capabilities such because the addition of _stub_UserSetWindowLong and _stub_UserSetWindowLongPtr _stub_UserGetMenuBarInfo in win32k.sys).
3. Fragmenting kernel desktop heap and elimination of kernel addresses within the consumer desktop heap (can use relative offsets inside consumer and desktop heaps described later within the weblog).
4. Elimination of knowledge sort symbols from win32k drivers (obfuscation fairly than mitigation).

Within the context of a malicious course of exploiting CVE-2021-1732, the above mitigations present no safety. Nonetheless, it doesn’t impression Google Chrome as it disallows win32k calls (Home windows 8 and better), or Microsoft Edge because it applies win32k filtering on the related APIs.

Triggering the Vulnerability and Patch Evaluation

When a window is created utilizing CreateWindowEx API, a tagWND object is created by the Home windows working system. This window, as defined above, might be created with a parameter to allocate additional reminiscence utilizing cbWndExtra.

Throughout the home windows creation course of (CreateWindowEx API) a callback named xxxClientAllocWindowClassExtraBytes is triggered to allocate house within the consumer mode desktop heap for the tagWND.ExtraBytes (offset 0x128) per the tagWND.cbWndExtra (offset 0xc8) worth measurement (see determine 3 and 4 beneath for WND1).

The situation of this reminiscence is saved as a consumer mode reminiscence pointer to the desktop heap and positioned at tagWND.ExtraBytes. It’s then potential to transform the traditional window to a console window utilizing NtUserConsoleControl which is able to convert that consumer mode pointer at tagWND.ExtraBytes to an offset worth which factors into the kernel desktop heap (see determine 5 beneath for WND0). It’s this modification in worth at tagWND.ExtraBytes (window sort confusion) that may be exploited for an OOB write through the xxxClientAllocWindowClassExtraBytes callback window.

Per determine 6 above the next steps are required to set off the vulnerability:

1. Get a pointer to the HMValidateHandle inline operate inside user32.dll.
2. Hook xxxClientAllocWindowClassExtraBytes inside the PEB KernelCallBack desk.
3. Create a number of home windows (we are going to simply use the primary two WND0 and WND1 created), utilizing the CreateWindowEx API, in order that two home windows are created in shut reminiscence proximity.
4. Name HMValidateHandle on WND0 and WND1 which is able to copy their objects from the kernel desktop heap to consumer desktop heap. At tagWND+0x8 an offset is saved into the desktop heap; this offset is identical for the consumer and kernel desktop heaps. The exploit makes use of these offset values to calculate the relative distance between WND0 and WND1 within the kernel desktop heap which is required later for studying and writing OOB. Per desk 1 beneath, through the use of these offsets there is no such thing as a requirement to leak the precise WND0 and WND1 kernel addresses since learn and writes might be performed relative to the offsets (consumer and kernel desktop heaps have the identical offsets).

5. WND0 is then transformed to a console window by calling NtUserConsoleControl which converts WND0.ExtraBytes from a consumer desktop heap pointer to an offset inside the kernel desktop heap. That is wanted later in order that WND0 can write OOB to WND1.

6. Create malicious window WND_Malicious utilizing the CreateWindowEx API

• • Throughout the window creation the callback xxxClientAllocWindowClassExtraBytes API is executed to request consumer mode to allocate reminiscence for WND_Malicious.cbWndExtra and move the consumer desktop heap pointer again to the kernel operate win32kfull!xxxCreateWindowEx.
  • xxxClientAllocWindowClassExtraBytes has now been hooked and we do the next earlier than returning to win32kfull!xxxCreateWindowEx:
    • Name NtUserConsoleControl to transform WND_Malicious to a console window so changing its WND_Malicious.cbWndExtra from a consumer desktop heap pointer to an offset inside the kernel desktop heap.
    • Lastly name NtCallbackReturn which completes the callback and returns a single worth to xxxClientAllocWindowClassExtraBytes. As an alternative of passing the consumer desktop heap pointer as anticipated by xxxClientAllocWindowClassExtraBytes again to the kernel we move the worth at WND0+0x08 which is the kernel desktop heap offset to WND0 per determine 7 beneath. Now anytime we name SetWindowLongW on WND_Malicious we might be writing to WND0.

Patch Evaluation

The vulnerability lies in the truth that win32kfull!xxxCreateWindowEx doesn’t test whether or not the window sort has modified between the time it initiates the xxxClientAllocWindowClassExtraBytes and will get the response from NtCallbackReturn.

After we name NtUserConsoleControl with WND_Malicious within the hook above, xxxConsoleControl checks if tagWND+0xE8 flag has been set to 0x800 to point a console window per determine  beneath. As WND_Malicious was created as a standard window, xxxConsoleControl allocates reminiscence at an offset inside the kernel desktop heap after which frees the consumer desktop heap pointer current at WND_Malicious.ExtraBytes (0ffset 0x128). It then locations the offset to this new allocation within the kernel heap at WND_Malicious.ExtraBytes (0ffset 0x128) and units the tagWND+0xE8 flag to 0x800 to point it’s a console window.

After coming back from the callback after we issued NtCallbackReturn above, xxxCreateWindowEx doesn’t test that the window sort has modified and locations the WND0+0x08 at WND_Malicious.ExtraBytes per determine 9 beneath. The RedirectFieldpExtraBytes checks the WND_Malicious.ExtraBytes initialized worth however it’s too late as WND0+0x08 has already been written to WND_Malicious.ExtraBytes (offset 0x128).

The patched win32kfull.sys has up to date xxxCreateWindowEx to now test the ExtraBytes initialized worth earlier than writing the returned worth from consumer mode to tagWND. ExtraBytes (offset 0x128) per determine 10 beneath.

Determine 11 beneath reveals that tagWND. ExtraBytes is initialized to zero inside xxxCreateWindowEx throughout regular window creation.

Determine 12 beneath reveals that tagWND. ExtraBytes is initialized to the brand new offset worth within the kernel desktop heap inside xxxConsoleControl throughout console window creation. RedirectFieldpExtraBytes merely checks this initialized worth to find out if the window sort has modified. As well as, Microsoft have additionally added telemetry for detecting modifications to the window sort flag within the patched model.

tagWND OOB Write

The vulnerability inside the xxxCreateWindowEx API allowed the WND_Malicious.ExtraBytes subject be to set to a worth of WND0 offset inside the kernel desktop heap. Now any time SetWindowLongW is named on WND_Malicious it is going to write to WND0. By supplying an offset of 0xc8, the operate will overwrite the WND0.cbWndExtra subject to a big worth of 0XFFFFFFF per figures 13 and 14 beneath.

This implies it could write past its tagWND construction and ExtraBytes in kernel reminiscence to fields inside WND1. As well as, WND0.ExtraBytes can be overwritten with the offset to itself so calls to SetWindowLongPtrA on WND0 will write to an offset in kernel desktop heap relative to the beginning of WND0.

Kernel Handle Leak

Now that the WND0.cbWndExtra subject has been set to a really giant worth (0xFFFFFFF), anytime SetWindowLongPtrA is named on WND0 it is going to write into the adjoining WND1 in kernel reminiscence per determine 15 beneath. By writing to particular fields in WND1 we will create a kernel deal with reminiscence leak as follows:

1. Write a worth of 0x400000000000000 to WND1 model subject to briefly change it to a baby window per figures 15 and 16 beneath.
2. Calling SetWindowLongPtrA API on WND0 with a worth of -12 (GWLP_ID) now permits the spmenu subject (sort tagMENU) of WND1 to be overwritten with a pretend spmenu knowledge construction since we now have modified it to be a baby window per determine 15 and 17 beneath.
3. Per SetWindowLongPtrA API documentation, the return worth will give us the unique worth on the offset overwritten, i.e., the spmenu knowledge construction pointer which is a kernel reminiscence deal with. So, we now have leaked a pointer to a spmenu (sort tagMENU) knowledge construction in kernel reminiscence and changed the pointer in WND1.spmenu with a pretend spmenu knowledge construction inside consumer desktop heap per determine 17 beneath.

Kernel Arbitrary Learn

Utilizing the spmenu knowledge construction kernel pointer leaked beforehand we will use the structure of this knowledge construction and the GetMenuBarInfo API logic to show it into an arbitrary kernel reminiscence learn per figures 18,19 and 20 beneath.

As you’ll be able to see from the xxxGetMenuBarInfo operate in figures 21 and 22 beneath, by inserting our leaked kernel deal with on the proper location in our pretend spmenu knowledge construction we will create an arbitrary kernel reminiscence learn when calling GetMenuBarInfo.

Kernel Arbitrary Write

An arbitrary kernel write primitive might be simply achieved now by writing our vacation spot deal with to WND1.ExtraBytes subject by calling SetWindowLongPtrA on WND0 which is able to write OOB to WND1 relative to the offset we specify per determine 23 beneath

On this case the offset is 0x128 which is ExtraBytes. Then merely calling SetWindowLongPtrA on WND1 will write a specified worth on the deal with positioned within the WND1.ExtraBytes subject. The arbitrary write is achieved as a result of WND1 is a standard window (has not been transformed to a console window like WND0 and WND_Malicious) and so will write to no matter deal with we place in WND1.ExtraBytes.

Knowledge Solely Assault

The arbitrary kernel learn and write primitives might be mixed to carry out a data-only assault to overwrite a malicious course of EPROCESS token with that of PID 4 which is System for an escalation of privilege (EoP).

The unique spmenu kernel deal with leaked beforehand has a pointer to WND1 at offset 0x50 per figures 24 and 25 beneath. By a number of arbitrary reads utilizing the GetMenuBarInfo on our pretend spmenu knowledge construction with this WND1 kernel deal with we will finally learn the PID 4 System EPROCESS token.

By inserting the vacation spot deal with (malicious course of EPROCESS token) at WND1.ExtraBytes then the next name to SetWindowLongPtrA will write the worth (PID 4 – System EPROCESS token) to that deal with per figures 26 and 27 beneath.

The exploit then restores overwritten knowledge construction values as soon as the EoP is full to forestall a BSOD (Blue Display screen of Dying).

Conclusion

On this report, we undertook a deep evaluation of CVE-2021-1732 which is a Native Privilege Escalation on Home windows 10. Home windows kernel data-only assaults are troublesome to defend towards, as as soon as a vulnerability is found they use authentic and trusted code by particular APIs to govern knowledge buildings in kernel reminiscence.

The win32k element has been hardened by nice work by Microsoft towards learn/write primitives, however there are nonetheless alternatives for exploitation as a consequence of its giant assault floor (syscalls and callbacks) and lack of win32k filtering on a process-wide foundation. It could even be nice to see a system large win32k filtering coverage functionality inside Home windows 10.

Patching is all the time the very best resolution for vulnerabilities, however a robust protection technique comparable to risk looking can be required the place patching is probably not potential, and to detect variants of vulnerabilities/exploits being utilized by campaigns.