Microsoft fixes bypass for critical Outlook zero-click flaw patch

Microsoft fixed a new vulnerability this week that could be used to bypass defenses the company put in place in March for a critical vulnerability in Outlook that Russian cyberspies exploited in the wild. That vulnerability allowed attackers to steal NTLM hashes by simply sending specifically crafted emails to Outlook users. The exploit requires no user interaction.

The new vulnerability, patched Tuesday and tracked as CVE-2023-29324, is in the Windows MSHTML Platform and can be used to trick a security check used as part of the March Outlook vulnerability patch to think that a path on the internet is a local one, therefore evading trust zone checks. Microsoft rated the new vulnerability with 6.5 out of 10 (medium) severity score, but the security team from Akamai who found the vulnerability think it should have been rated higher.

“Our research indicates that the new vulnerability re-enables the exploitation of a critical vulnerability that was seen in the wild and used by APT operators,” the Akamai researchers told CSO via email. “We still believe our finding is of high severity. In the hands of a malicious actor, it could still have the same consequences as the critical original Outlook bug.”

The original Outlook flaw and fix

The Outlook vulnerability patched in March is tracked as CVE-2023-23397 and was rated 9.8 out of 10 on the CVSS scale. It’s described as an escalation-of-privilege flaw because attackers can trick the Microsoft Outlook email client, as well as Microsoft Exchange, to automatically reach out to a remote server on the internet using the SMB protocol, which is normally used on local networks, and leak NTLM hashes. An NTLM hash is a cryptographic representation of a user’s local Windows credentials and serves as an authentication token to access network resources.

Attackers can try to crack NTLM hashes offline to recover user passwords or use them in attacks known as NTLM relay or pass-the-hash, where the captured NTLM hash is passed to another legitimate service to authenticate as the user.

When it was patched, the flaw already had zero-day status because a threat actor known as STRONTIUM, Fancy Bear, or APT28 that’s believed to be tied to Russia’s military intelligence agency, the GRU, had already been exploiting the flaw in attacks against government, transportation, energy, and military organizations in Europe.

The exploit itself consisted of leveraging a feature in Outlook that allows users to send email reminders with custom notification sounds. The custom sound is specified as a path using an extended Messaging Application Programming Interface (MAPI) property called PidLidReminderFileParameter. Attackers crafted emails where this property was set to a specifically crafted UNC path that caused the Outlook client to try to load the file from a remote SMB server on the internet. As part of the SMB handshake, the client would then send the computer’s Net-NTLMv2 hash.

The fix to this issue consisted of using a method from the MSHTML Platform API called ​​IInternetSecurityManager::MapUrlToZone to better validate the UNC path and determine which security zone it belongs to. If the path leads to a location that’s not part of the local, intranet (local network) or trusted zones then the Outlook client will no longer fetch the custom sound file and will play the default one.

The MSHTML Platform is the HTML rendering engine from Internet Explorer 11 and while IE11 has been deprecated, the engine still exists in the Windows WebBrowser control that’s used by other applications like Outlook to display HTML content.

The MapUrlToZone bypass to Microsoft’s Outlook patch

Akamai security researcher Ben Barnea analyzed Microsoft’s March patch and saw that if MapUrlToZone determines that the UNC path falls into one of the three trusted zones, another function called CreateFile is called to access that path. To bypass the fix, he would need to find a path that MapUrlToZone determines is trusted, but which CreateFile still treats as an internet one and tries to access over SMB.

After testing he found that paths of the format ‘.UNCAkamai.comfile.wav” would pass the MapUrlToZone check but would be treated as internet paths by CreateFile. “This issue seems to be a result of the complex handling of paths in Windows,” Barnea said. MapUrlToZone and CreateFile rely on different functions to convert paths. MapUrlToZone calls the function CreateUri, which incorrectly converts the path to a path that points to a directory called UNC in the root of the C: drive, therefore a local directory. However, CreateFile uses a function called RtlpDosPathNameToRelativeNtPathName to convert the path and this function converts it to ??UNCAkamai.comfile.wav. This causes the request to be routed through the Multiple UNC Provider (MUP) driver, which will interpret it as an SMB path to the Akamai.com 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,” Barnea said in his report. “Also, we cannot rule out other issues arising in programs that call CreateUri.”

In other words, the Outlook PidLidReminderFileParameter property could be just one way to send paths to a Windows application to fetch, but might not be the only one since this new vulnerability is in MapUrlToZone.

According to Microsoft, the mitigations for Microsoft Exchange servers already prevent this bypass, but the patch for the stand alone Outlook clients does not. As a result, the company updated its mitigation guidance for the Outlook flaw to require the patches for both CVE-2023-29324 and CVE-2023-29324.