🔥 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,
, 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
. 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.
Only one function appeared to have been changed,
. 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.
afd.sys version 10.0.22621.608
afd.sys version 10.0.22621.1105
This change shown above is the only update to the identified function. Some quick analysis showed that a check is being performed based on
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
, 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
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
value and a pointer to the unknown structure as the first and third arguments respectively.
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.
A single call to the vulnerable function is made in
We repeat the process, looking for cross-references to
. We find no direct calls to the function, but its address appears above a table of function pointers named
This table contains the dispatch routines for the AFD driver. Dispatch routines are used to handle requests from Win32 applications by calling
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
. By calculating the distance between the start of this table and where the pointer to
is stored, we can calculate the index into the
which shows the control code for the function is
It’s worth noting that it’s the last input/output control (IOCTL) code in the table, indicating that
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
, 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.
Now, refer back to the function prototype for
, through which we call into the AFD driver from user space. One of the parameters,
, 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
as the fourth parameter, and into
as the third parameter.
At this point, we don’t know how to populate the data in
, which we’ll call
, in order to pass the checks required to reach the vulnerable code path in
. 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
This check tells us that the size of the
should be equal to
bytes, otherwise the function fails with
The next check validates values in various fields in our structure:
At the time we didn’t know what any of the fields correspond to, so we pass in a
Afterward, we reach a loop whose counter was one of the values from our struct:
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
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 (
) and field
dwLen = 1
(so that the total size passed to
is equal 0x20), and the checks pass.
Finally, the last check to pass before reaching the target code is a call to
which must return 0 (
This function will block until either:
A completion record becomes available for the
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
, which manually increments the I/O pending counter on an
. Calling this function on the
we created earlier ensures that the call to
Triggering Arbitrary Write-Where
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
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
. We speculated that the return value of
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
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
and is shown below.
Note that the kernel object has two fields,
, 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.
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.
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.
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,
, instead of calling into the
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
gets the number of times
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
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.