From One Vulnerability to Another: Outlook Patch Analysis Reveals Important Flaw in Windows API
Editorial and additional contributions by Tricia Howard
Executive summary
Akamai researcher Ben Barnea found a new important vulnerability in an Internet Explorer component, assigned CVE-2023-29324 with a CVSS base score of 6.5.
The vulnerability causes a Windows API function — MapUrlToZone — to incorrectly think that a remote path is a local one.
MapUrlToZone is commonly used as a security measure. In particular, it was used to mitigate the critical Outlook vulnerability CVE-2023-23397 patched in the March Patch Tuesday.
An unauthenticated attacker on the internet could use the vulnerability to coerce an Outlook client to connect to an attacker-controlled server. This results in NTLM credentials theft. It is a zero-click vulnerability, meaning it can be triggered with no user interaction.
All Windows versions are affected by the vulnerability. As a result, all Outlook client versions on Windows are exploitable. However, according to Microsoft, Exchange servers with the March update omit the vulnerable feature, thus preventing vulnerable clients from being exploited.
The issue was responsibly disclosed to Microsoft and addressed in May 2023 Patch Tuesday.
Introduction
Among the vulnerabilities addressed as part of March 2023 Patch Tuesday was a critical Outlook vulnerability assigned CVE-2023-23397.
The vulnerability allows an attacker to coerce an Outlook client to connect to the attacker’s server. By doing so, the client sends NTLM credentials to the machine, which allows the attacker to crack the password offline, or to use it in a relay attack. This vulnerability can be exploited remotely over the internet without any user interaction (zero-click).
As assessed by Microsoft Threat Intelligence, a Russian threat actor has used the vulnerability in targeted attacks against several organizations in the European government, transportation, energy, and military sectors, for approximately a year.
As part of our analysis of the patch, we discovered a way to bypass the fix for this critical vulnerability. In this blog post, we will discuss the original vulnerability, the patch to it, and the bypass to said patch.
The original vulnerability
The Outlook vulnerability that was patched in March is triggered when an attacker sends an email containing a reminder with a custom notification sound. This custom sound is specified by the attacker as a path, using the extended MAPI property PidLidReminderFileParameter. An attacker can specify a UNC path that would cause the client to retrieve the sound file from any SMB server. As part of the connection to the remote SMB server, the Net-NTLMv2 hash is sent in a negotiation message.
To fix the issue, the code now calls MapUrlToZone to verify that the path is not referring to an internet URL. If it does, the default reminder sound is used instead of the custom one.
Bypassing the mitigation
Let's first look at the relevant code flow in Outlook. Two important functions are called as part of loading the custom sound file:
MapUrlToZone — Returns the zone of the URL; used to determine that the path is local, intranet, or trusted (and not internet)
CreateFile — Opens a handle to the sound file
Note: SearchPath is also called before CreateFile, but it handles the path similarly, so for ease of understanding we will only refer to CreateFile here.
To find a bypass, we need to find a path that MapUrlToZone would consider as local, intranet, or a trusted zone, and that CreateFile would also treat as an internet domain.
To call MapUrlToZone, we can use the following PowerShell script that invokes the function through Component Object Model (COM).
To verify that MapUrlToZone is a proper mitigation, we can test it by calling it on the same path that triggered the vulnerability — an absolute UNC path with an internet domain. MapUrlToZone returns 3, indicating the path is in the internet zone, as expected.
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\Akamai.com\file.wav')
3
We can get crafty, and tweak our UNC path by using a local device path:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\Akamai.com\file.wav')
3
As seen above, MapUrlToZone still identifies the path as an internet zone, so it would still be blocked, as the fix intended.
However, by adding another ‘\’ after the “UNC\”, MapUrlToZone now returns 0, which means a local path:
PS C:\Users\research1>[IEZones]::MapUrlToZone('\\.\UNC\\Akamai.com\file.wav')
0
So, MapUrlToZone concludes this URL is local. Now the important question is: What will CreateFile’s verdict be for this URL? Will it access a local file or download it through SMB?
Drumroll, please …
Fig. 1: Simulating a CreateFile call with the UNC path, leading to a DNS request
Neat! A DNS request was sent to retrieve the IP of Akamai.com (Figure 1). Seems like we found a path that MapUrlToZone concludes as local, yet makes CreateFile fire a request to the internet!
Now, let’s trigger the original Outlook vulnerability, this time bypassing the added mitigation.
Fig. 2: Triggering the calendar event, leading to NTLM authentication against a remote server
As you can see in Figure 2, once the reminder pops up, Outlook connects to the remote server leading to NTLM authentication.
According to Microsoft, Exchange servers with the March software update installed will drop the PidLidReminderFileParameter property, eliminating the custom sound file feature. Thus, only machines running Outlook clients with an unpatched Exchange server are vulnerable to this issue.
The root cause
This issue seems to be a result of the complex handling of paths in Windows.
MapUrlToZone calls the function CreateUri which incorrectly converts the path '\\.\UNC\\Akamai.com\file.wav' to ‘/.//UNC//Akamai.com/file.wav’.
To see what access is triggered by the latter path, we can use the ConvertDosPathToNtPath script from James Forshaw’s blog post.
PS C:\Users\research1> ./DosToRelativeNT.exe /.//UNC//Akamai.com/file.wav
Converting: '/.//UNC//Akamai.com/file.wav'
To: '\??\C:\UNC\Akamai.com\file.wav'
Type: RtlPathTypeRooted
FileName: file.wav
FullPathName: 'C:\UNC\Akamai.com\file.wav'
We can now see that this path points to a directory named ‘UNC’ on the local C: drive. This is obviously a local directory, and thus MapUrlToZone returns 0.
On the other hand, CreateFile first converts the original path from a DOS path to an NT path by calling RtlpDosPathNameToRelativeNtPathName. Once again, using the script allows us to observe the output of this conversion.
PS C:\Users\research1> ./DosToRelativeNT.exe \\.\UNC\\Akamai.com\file.wav
Converting: '\\.\UNC\\Akamai.com\file.wav'
To: '\??\UNC\Akamai.com\file.wav'
Type: RtlPathTypeLocalDevice
FileName: file.wav
FullPathName: '\\.\UNC\Akamai.com\file.wav'
Notice that this time the result does not point at a local drive. So, why is an SMB request triggered? As can be seen in the snippet above, the resulting path is '\??\UNC\Akamai.com\file.wav'. Access to this NT path will cause the object manager to route the IO request to the Multiple UNC Provider (MUP) driver. (This is because the global object directory entry for “UNC” is a symbolic link to “\Device\Mup”.) Because RtlpDosPathNameToRelativeNtPathName removed or collapsed the extra ‘\’, the path now contains only the internet domain name.
We believe this kind of confusion can potentially cause vulnerabilities in other programs that use MapUrlToZone on a user-controlled path and then use a file operation (such as CreateFile or a similar API) on the same path. Also, we can not rule out other issues arising in programs that call CreateUri.
Detection and mitigation
Microsoft published comprehensive guidance for the detection and mitigation of the original Outlook vulnerability. From our observation, all the methods specified are applicable to the new vulnerability as they are not dependent on the URL specified in the PidLidReminderFileParameter property.
Summary
This vulnerability is yet another example of patch scrutinizing leading to new vulnerabilities and bypasses. Specifically for this vulnerability, the addition of one character allows for a critical patch bypass.
We hope the feature of custom reminder sound is fully removed, as it poses more security risks than it provides value to users. It is a zero-click media parsing attack surface that could potentially contain critical memory corruption vulnerabilities. Considering how ubiquitous Windows is, eliminating an attack surface as ripe as this is could have some very positive effects.
As part of our ongoing efforts to protect our customers and the community, we will continue to analyze patches and other systems for vulnerabilities. To keep up with the latest security research from Akamai, follow us on Twitter.
We would like to thank Microsoft for their cooperation and quick response in handling this issue.
