CreateRCE — Yet Another Vulnerability in CreateUri
Executive summary
Akamai researcher Ben Barnea found a critical vulnerability in Microsoft Windows, which was assigned CVE-2023-35628.
An attacker on the internet can trigger the vulnerability against Outlook clients without any user interaction (zero-click).
The vulnerability lies in the parsing of a path by the CreateUri function. We are currently aware of two ways to trigger this vulnerability: (1) by sending a crafted email to an Outlook client, or (2) by enticing a user to navigate File Explorer to a folder containing a malicious downloaded file.
The vulnerability was responsibly disclosed to Microsoft and addressed on December 2023’s Patch Tuesday.
Windows machines with the December 2023 software update installed are protected from this vulnerability. Additionally, Outlook clients that use Exchange servers patched with March 2023 software update are protected against the abused feature.
Introduction
The omnipresence of Microsoft in the enterprise and beyond makes it a large (and lucrative) target for attackers. As such, we have done extensive research into the suite of products and protocols — finding both vulnerabilities and building tools to assist with detection and mitigation.
As part of this research, we discovered a new remote code execution (RCE) vulnerability in the WinAPI function CreateUri that is called as part of the patch for the original vulnerability CVE-2023-23397. While the previous RCE vulnerability chain needed to chain together two vulnerabilities to achieve a zero-click RCE primitive, this vulnerability can do so on its own. In addition to Outlook, we’ll also show you how to trigger the vulnerability in File Explorer.
The vulnerability saga
Among the vulnerabilities addressed as part of the March 2023’s Patch Tuesday was a critical Outlook vulnerability discovered by Microsoft themselves (assigned CVE-2023-23397) which was exploited in the wild by a Russian state-sponsored threat actor called Forest Blizzard.
In December 2023, Microsoft and the Polish Cyber Command published that they had seen recent exploitation attempts of the vulnerability by the same threat actor. The vulnerability allowed an attacker to coerce an Outlook client to connect to the attacker’s server. As part of this connection, the client sends their NTLM credentials to the attacker, who can then crack them offline, or use them in a relay attack. This vulnerability could be exploited remotely over the internet without any user interaction (zero click).
After the patch for this vulnerability was released, we found two bypasses along with a sound parsing vulnerability. Chaining both the bypass and the parsing vulnerabilities could lead to a full zero-click RCE primitive on the Outlook client.
MapUrlToZone
As part of the patch for the Outlook vulnerability CVE-2023-23397, the code that is responsible for handling a custom reminder sound adds a call to MapUrlToZone. The call checks that the provided URL, specified through the extended MAPI property PidLidReminderFileParameter, does not point to an internet resource.
Although this mitigates the initial vulnerability, it adds a new attack surface — the function MapUrlToZone itself; we control the path that is being passed to MapUrlToZone.
As part of the parsing done by MapUrlToZone, it calls CreateUri. CreateUri creates an IUri object representing a Uniform Resource Identifier (URI). To create the object, the function knows to parse both URLs and some of the DOS Windows paths.
When CreateUri is called with a file path (e.g., using file:// scheme, or a Windows path pointing to a file/directory), the function CrackUrlFile is called. This is also the function that contained the bypasses described in the previous blog post.
The new vulnerability
At the beginning of CrackUrlFile, if it receives a URL rather than a Windows path, it creates a copy of the input, and then transforms the URL copy to a Windows path using PathCreateFromUrlW. The working buffer is marked as dynamically allocated, so it would know to free it later on. If the function receives a Windows path, it directly works on the input path, and thus it doesn’t need to free the pointer.
During the parsing of the working buffer, the buffer can be advanced; e.g., if it’s a local device path (begins with “\\.\” or “\\?\”), the function advances the pointer by four characters. Then, if the device name is “UNC\”, it advances by four more characters. If there are multiple backslashes, the function also advances the buffer past the duplicated backslashes.
As part of our reversing of the patches to the bypasses, we noticed new code added in CrackUrlFile in July 2023, which seemed to be unrelated to our bypasses (Figure 1).
Fig. 1: Decompilation of newly added code
As part of the parsing of the path, the function checks whether the path component is of either a drive path or rooted path. If yes, it marks the path as local. The new code overrides the original buffer pointer with a pointer to the path component (the advanced buffer) if the path is a drive path.
This is the origin of the bug: The pointer that was advanced is saved. Later on, the original buffer pointer (PPWorkingBuffer in Figure 1) is retrieved and freed if it was dynamically allocated. Since it was overridden with the advanced pointer, a call to free() happens with a pointer that was not returned by malloc. This gives an attacker a primitive to provide the memory allocator with a malicious chunk’s metadata.
For the vulnerability to be triggered, we first need to specify a file scheme URL, with a UNC path. Then, we need to mark the path as a drive path, so we must use a share (C:). The full path to trigger the vulnerability will look like this:
file://./UNC/C:/Akamai.com/file.wav
The fixed code now copies the bytes of the path component using RtlMoveMemory, instead of saving the pointer.
Triggering through Explorer
Although it was out of the scope of our research to find such places, we made one quick attempt: Triggering it through Windows Explorer.
To do so, we created a shortcut (.lnk file) pointing to the vulnerable path. Once the victim views the directory in which the shortcut file resides, the vulnerability is triggered in Explorer, which leads to an immediate crash (Figure 2).
To test if your machine is vulnerable to this issue, you are welcome to download our proof of concept (PoC) that will crash Explorer. (Carefully read the specifics and risks about the PoC in our security research repo prior to use.)
Fig. 2: Explorer crashing as a result of the PoC
Summary
This is our final blog post about the research on the potential impact of CVE-2023-23397.
In May 2023, when we discovered the first bypass, we recommended removing the abused feature since using MapUrlToZone adds a new attack surface. We also mentioned that exposing a sound parsing attack surface to a remote attacker in a zero-click manner, without any sandbox, presents more dangers to users than value.
In our subsequent research, we managed to exactly prove that by finding two bypasses, finding a sound parsing issue, and, finally, finding a Windows path parsing memory corruption.
We hope you learned new things about Windows paths, sound codecs, and different vulnerabilities via thes posts. We encourage other researchers to look at patches and think how they can be bypassed. We can not rule out that more MapUrlToZone bypasses exist.
Want more?