|
tl;dr In 2023, Varonis Labs discovered (https://www.varonis.com/blog/outlook-vulnerability-new-ways-to-leak-ntlm-hashes) that a Net-NTLMv2 hash could be received from a victim by tricking them into opening a calendar in Outlook. CVE-2023-35636 was issued and was subsequently fixed in December 2023. By leveraging a technique commonly used in SSRF (Server-Side Request Forgery), and redirecting a HTTP request to a UNC path, we were able to bypass Microsoft’s fix and obtain a Net-NTLM-v2 hash. Microsoft patched this as part of the July 2024 Patch Tuesday and issued CVE-2024-38020 (https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2024-38020). Introduction This is part two of a five-part blog post series focusing on NTLM-related research that was presented as part of the DEF CON 32 presentation 'NTLM - the last ride'. After hearing the news that Microsoft is planning to kill off NTLM (New Technology Lan Manager) authentication in Windows 11 and above, we decided to speedrun coercing hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. For more detail about what NTLM is, please see our first blog post in this series (https://www.privsec.nz/releases/nuget-package-manager) Outlook Outlook is Microsoft’s email client, widely used throughout the world. It comes in multiple flavours and variants, from the Windows desktop client (classic), the browser client, to the (new) desktop client which is built using WebView 2. Outlook allows for sharing and receiving emails, calendars, invitations and other event and message types between different users of different organisations. Microsoft security controls The security controls Microsoft implement for externally provided content often take the form of a warning dialog box, letting the user know that if they choose to interact with external content that is not trusted they may be about to do something dangerous or fun. The vulnerability The original CVE (CVE-2023-35636) leveraged two headers that can be included in an email, which can be specified by the sender. Email headers are hidden parts of an email that can contain information about the sender, and how the message is routed and authenticated. The following Outlook-specific headers were used: Content-Class: x-sharing-config-url: When the value of `Content-Class` was set to “sharing”, this instructs Outlook that the received message is for sharing content. When the `x-sharing-config-url` was set to a file URL or UNC path containing an ICS (calendar) file, Outlook would helpfully format the top of the email with a call to action for the user to add the calendar to their own:  This vulnerability was a one-click, no warning Net-NTLMv2 hash leaker, and was classed as Important and fixed in January 2024. The initial fix Microsoft added a dialog warning to any `x-sharing-config-url` that started with the `file:\\\` handler, letting the user know that by clicking the dialog they may be exposing themselves to risk:  Bypassing the fix We noticed that Outlook was only popping up a dialog box on a UNC/File path link, and that HTTP connections were not providing the same warnings. This was a reasonable assumption for the fix, as Windows generally doesn’t send authentication on port 80/443 unless it is to a trusted location, such as an internal network. However, by reframing this problem to be more like a SSRF (Server-Side Request Forgery), we were able to apply a redirection technique, and subsequently capture a Net-NTLMv2 hash on port 445. Using a basic Python script, we would redirect any incoming web (HTTP) requests to a UNC path:  This is a common technique in SSRF to bypass filter protections, or turn a web-only SSRF into a file read exploit, by forcing a protocol change from http:// to file:// The new flow can be roughly summarised below:
Reproduction steps To reproduce this issue, we have created the following PowerShell script that you are able to run on a Windows machine with Outlook installed:  This issue was patched as part of July 2024 Patch Tuesday, and CVE-2024-38020 was assigned.
Disclosure timeline: 17 April 2024: Reported to the MSRC 18 April 2024: Case opened by the MSRC 27 April 2024: Further reproduction steps provided, including the above PowerShell script 30 April 2024: MSRC confirms that they are able to reproduce 17 May 2024: MSRC confirms that this vulnerability is classed as Important and will be sent for immediate servicing 18 May 2024: MSRC downgrades this issue to a Moderate. 09 July 2024: Patched as part of Patch Tuesday, CVE-2024-38020 assigned. Comments are closed.
|