🔥 PoC https://github.com/sinsinology/CVE-2023-20887 for CVE-2023-20887 VMWare Aria Operations for Networks (vRealize Network Insight) unauthenticated RCE This vulnerability allows a remote unauthenticated attacker to execute arbitrary commands on the underlying operating system as the root user. The RPC interface is protected by a reverse proxy which can be bypassed.
Original text by By Valentina Palmiotti co-authored by Ruben Boonen
‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.
However, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can be introduced. By honing in on this newly introduced code, we demonstrate that vulnerabilities that can be trivially weaponized still occur frequently. In this blog post, we analyze and exploit a vulnerability in the Windows Ancillary Function Driver for Winsock,
afd.sys
, for Local Privilege Escalation (LPE) on Windows 11. Though neither of us had any previous experience with this kernel module, we were able to diagnose, reproduce, and weaponize the vulnerability in about a day. You can find the exploit code here.
Patch Diff and Root Cause Analysis
Based on the details of CVE-2023-21768 published by the Microsoft Security Response Center (MSRC), the vulnerability exists within the Ancillary Function Driver (AFD), whose binary filename is
afd.sys
. The AFD module is the kernel entry point for the Winsock API. Using this information, we analyzed the driver version from December 2022 and compared it to the version newly released in January 2023. These samples can be obtained individually from Winbindex without the time-consuming process of extracting changes from Microsoft patches. The two versions analyzed are shown below.
AFD.sys / Windows 11 22H2 / 10.0.22621.608 (December 2022)
AFD.sys / Windows 11 22H2 / 10.0.22621.1105 (January 2023)
Ghidra was used to create binary exports for both of these files so they could be compared in BinDiff. An overview of the matched functions is shown below.
Figure 2 — Binary comparison of AFD.sys
Only one function appeared to have been changed,
afd!AfdNotifyRemoveIoCompletion
. This significantly sped up our analysis of the vulnerability. We then compared both of the functions. The screenshots below show the changed code pre- and post-patch when looking at the decompiled code in Binary Ninja.
is zero (indicating that the call originates from the kernel) a value is written to a pointer specified by a field in an unknown structure. If, on the other hand,
is called to ensure that the pointer set out in the field is a valid address that resides within user mode.
This check is missing in the pre-patch version of the driver. Since the function has a specific switch statement for
PreviousMode
, the assumption is that the developer intended to add this check but forgot (we all lack coffee sometimes !).
From this update, we can infer that an attacker can reach this code path with a controlled value at
field_0x18
of the unknown structure. If an attacker is able to populate this field with a kernel address, then it’s possible to create an arbitrary kernel Write-Where primitive. At this point, it is not clear what value is being written, but any value could potentially be used for a Local Privilege Escalation primitive.
The function prototype itself contains both the
PreviousMode
value and a pointer to the unknown structure as the first and third arguments respectively.
Figure 5 — afd!AfdNotifyRemoveIoCompletion function prototype
Reverse Engineering
We now know the location of the vulnerability, but not how to trigger the execution of the vulnerable code path. We’ll do some reverse engineering before beginning to work on a Proof-of-Concept (PoC).
First, the vulnerable function was cross-referenced to understand where and how it was used.
table as we expected. From Steven Vittitoe’s Recon talk slides, we discovered that there are actually two dispatch tables for AFD. The second being
AfdImmediateCallDispatch
. By calculating the distance between the start of this table and where the pointer to
AfdNotifySock
is stored, we can calculate the index into the
AfdIoctlTable
which shows the control code for the function is
0x12127
.
Figure 8 — afd!AfdIoctlTable
It’s worth noting that it’s the last input/output control (IOCTL) code in the table, indicating that
AfdNotifySock
is likely a new dispatch function that has been recently added to the AFD driver.
At this point, we had a couple of options. We could reverse engineer the corresponding Winsock API in a user space to better understand how the underlying kernel function was called, or reverse engineer the kernel code and call into it directly. We didn’t actually know which Winsock function corresponded to
AfdNotifySock
, so we opted to do the latter.
We came across some code published by x86matthew that performs socket operations by calling into the AFD driver directly, forgoing the Winsock library. This is interesting from a stealth perspective, but for our purposes, it is a nice template to create a handle to a TCP socket to make IOCTL requests to the AFD driver. From there, we were able to reach the target function, as evidenced by reaching a breakpoint set in WinDbg while kernel debugging.
Figure 9 — afd!AfdNotifySock breakpoint
Now, refer back to the function prototype for
DeviceIoControl
, through which we call into the AFD driver from user space. One of the parameters,
lpInBuffer
, is a user mode buffer. As mentioned in the previous section, the vulnerability occurs because the user is able to pass an unvalidated pointer to the driver within an unknown data structure. This structure is passed in directly from our user mode application via the lpInBuffer parameter. It’s passed into
AfdNotifySock
as the fourth parameter, and into
AfdNotifyRemoveIoCompletion
as the third parameter.
At this point, we don’t know how to populate the data in
lpInBuffer
, which we’ll call
AFD_NOTIFYSOCK_STRUCT
, in order to pass the checks required to reach the vulnerable code path in
AfdNotifyRemoveIoCompletion
. The remainder of our reverse engineering process consisted of following the execution flow and examining how to reach the vulnerable code.
Let’s go through each of the checks.
The first check we encounter is at the beginning of
AfdNotifySock
:
Figure 10 — afd!AfdNotifySock size check
This check tells us that the size of the
AFD_NOTIFYSOCK_STRUCT
should be equal to
0x30
bytes, otherwise the function fails with
STATUS_INFO_LENGTH_MISMATCH
.
The next check validates values in various fields in our structure:
. This function takes the first field of our input structure as its first argument.
Figure 12 — afd!AfdNotifySock call nt!ObReferenceObjectByHandle
The call must return success in order to proceed to the correct code execution path, which means that we must pass in a valid handle to an
IoCompletionObject
. There is no officially documented way to create an object of that type via Win32 API. However, after some searching, we found an undocumented NT function
Afterward, we reach a loop whose counter was one of the values from our struct:
Figure 13 — afd!AfdNotifySock loop
This loop checked a field from our structure to verify it contained a valid user mode pointer and copied data to it. The pointer is incremented after each iteration of the loop. We filled in the pointers with valid addresses and set the counter to 1. From here, we were able to finally reach the vulnerable function
, the first check is on another field in our structure. It must be non-zero. It’s then multiplied by 0x20 and passed into
ProbeForWrite
along with another field in our struct as the pointer parameter. From here we can fill in the struct further with a valid user mode pointer (
pData2
) and field
dwLen = 1
(so that the total size passed to
ProbeForWrite
is equal 0x20), and the checks pass.
Figure 15 — afd! Afd!AfdNotifyRemoveIoCompletion field check
Finally, the last check to pass before reaching the target code is a call to
IoRemoveCompletion
which must return 0 (
STATUS_SUCCESS
).
This function will block until either:
A completion record becomes available for the
IoCompletionObject
parameter
The timeout expires, which is passed in as a parameter of the function
We control the timeout value via our structure, but simply setting a timeout of 0 is not sufficient for the function to return success. In order for this function to return with no errors, there must be at least one completion record available. After some research, we found the undocumented function
Now that we can reach the vulnerable code, we can fill the appropriate field in our structure with an arbitrary address to write to. The value that we write to the address comes from an integer whose pointer is passed into the call to
IoRemoveIoCompletion
.
IoRemoveIoCompletion
sets the value of this integer to the return value of a call to
In our proof of concept, this write value is always equal to
0x1
. We speculated that the return value of
KeRemoveQueueEx
is the number of items removed from the queue, but did not investigate further. At this point, we had the primitive we needed and moved on to finishing the exploit chain. We later confirmed that this guess was correct, and the write value can be arbitrarily incremented by additional calls to
NtSetIoCompletion
on the
IoCompletionObject
.
LPE with IORING
With the ability to write a fixed value (0x1) at an arbitrary kernel address, we proceeded to turn this into a full arbitrary kernel Read/Write. Because this vulnerability affects the latest versions of Windows 11(22H2), we chose to leverage a Windows I/O ring object corruption to create our primitive. Yarden Shafir has written a number of excellent posts on Windows I/O rings and also developed and disclosed the primitive that we leveraged in our exploit chain. As far as we are aware this is the first instance where this primitive has been used in a public exploit.
When an I/O Ring is initialized by a user two separate structures are created, one in user space and one in kernel space. These structures are shown below.
The kernel object maps to
nt!_IORING_OBJECT
and is shown below.
Figure 19 — nt!_IORING_OBJECT initialization
Note that the kernel object has two fields,
RegBuffersCount
and
RegBuffers
, which are zeroed on initialization. The count indicates how may I/O operations can possibly be queued for the I/O ring. The other parameter is a pointer to a list of the currently queued operations.
you get back an I/O Ring handle on success. This handle is a pointer to an undocumented structure (HIORING). Our definition of this structure was obtained from the research done by Yarden Shafir.
If a vulnerability, such as the one covered in this blog post, allows you to update the
RegBuffersCount
and
RegBuffers
fields, then it is possible to use standard I/O Ring APIs to read and write kernel memory.
As we saw above, we are able to use the vulnerability to write
0x1
at any kernel address that we like. To set up the I/O ring primitive we can simply trigger the vulnerability twice.
In the first trigger we set the
RegBufferCount
to
0x1
.
Figure 20 — nt!_IORING_OBJECT first time triggering the bug
And in the second trigger we set
RegBuffers
to an address that we can allocate in user space (like
0x0000000100000000
).
Figure 21 — nt!_IORING_OBJECT second time triggering the bug
All that remains is to queue I/O operations by writing pointers to forged
nt!_IOP_MC_BUFFER_ENTRY
structures at the user space address (
0x100000000
). The number of entries should be equal to
RegBuffersCount
. This process is highlighted in the diagram below.
Figure 22 — Setting up user space for I/O Ring kernel R/W primitive
One such
nt!_IOP_MC_BUFFER_ENTRY
is shown in the screenshot below. Note that the destination of the operation is a kernel address (
0xfffff8052831da20
) and that the size of the operation, in this case, is
0x8
bytes. It is not possible to tell from the structure if this is a read or write operation. The direction of the operation depends on which API was used to queue the I/O request. Using
results in an arbitrary kernel read.
Figure 23 — Example faked I/O Ring operation
To perform an arbitrary write, an I/O operation is tasked to read data from a file handle and write that data to a Kernel address.
Figure 24 — I/O Ring arbitrary write
Conversely, to perform an arbitrary read, an I/O operation is tasked to read data at a kernel address and write that data to a file handle.
Figure 25 – I/O Ring arbitrary read
Demo
With the primitive set up all that remains is using some standard kernel post-exploitation techniques to leak the token of an elevated process like System (PID 4) and overwrite the token of a different process.
Exploitation In the Wild
After the public release of our exploit code, Xiaoliang Liu (@flame36987044) from 360 Icesword Lab disclosed publicly for the first time, that they discovered a sample exploiting this vulnerability in the wild (ITW) earlier this year. The technique utilized by the ITW sample differed from ours. The attacker triggers the vulnerability using the corresponding Winsock API function,
ProcessSocketNotifications
, instead of calling into the
afd.sys
driver directly, like in our exploit.
The official statement from 360 Icesword Lab is as follows:
“360 IceSword Lab focuses on APT detection and defense. Based on our 0day vulnerability radar system, we discovered an exploit sample of CVE-2023-21768 in the wild in January this year, which differs from the exploits announced by @chompie1337 and @FuzzySec in that it is exploited through system mechanisms and vulnerability features. The exploit is related to
NtSetIoCompletion
and
ProcessSocketNotifications
,
ProcessSocketNotifications
gets the number of times
NtSetIoCompletion
is called, so we use this to change the privilege count.”
Conclusion and Final Reflections
You may notice that in some parts of the reverse engineering our analysis is superficial. It’s sometimes helpful to only observe some relevant state changes and treat portions of the program as a black box, to avoid getting led down an irrelevant rabbit hole. This allowed us to turn around an exploit quickly, even though maximizing the completion speed was not our goal.
Additionally, we conducted a patch diffing review of all the reported vulnerabilities in
afd.sys
indicated as “Exploitation More Likely”. Our review revealed that all except two of the vulnerabilities were a result of improper validation of pointers passed in from user mode. This shows that having a historical knowledge of past vulnerabilities, particularly within a specific target, can be fruitful for finding new vulnerabilities. When the code base is expanded – the same mistakes are likely to be repeated. Remember, new C code == new bugs . As evidenced by the discovery of the aforementioned vulnerability being exploited in the wild, it is safe to say that attackers are closely monitoring new code base additions as well.
The lack of support for Supervisor Mode Access Protection (SMAP) in the Windows kernel leaves us with plentiful options to construct new data-only exploit primitives. These primitives aren’t feasible in other operating systems that support SMAP. For example, consider CVE-2021-41073, a vulnerability in Linux’s implementation of I/O Ring pre-registered buffers, (the same feature we abuse in Windows for a R/W primitive). This vulnerability can allow overwriting a kernel pointer for a registered buffer, but it cannot be used to construct an arbitrary R/W primitive because if the pointer is replaced with a user pointer, and the kernel tries to read or write there, the system will crash.
Despite best efforts by Microsoft to kill beloved exploit primitives, there are bound to be new primitives to be discovered that take their place. We were able to exploit the latest version of Windows 11 22H2 without encountering any mitigations or constraints from Virtualization Based Security features such as HVCI.