Won't-Fix NTLM Hash Leak in Visual Studio

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 has 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?

• Responder is run listening and providing authentication challenges on port 80?

• An attacker distributes a URL pointing to the malicious Git server (Responder) to the victim?

• The victim Git clones the repository within Visual Studio?

• The victim’s Net-NTLMv2 hash is leaked to the attacker’s server?

Disclosure timeline?

• 22 Mar 2024 at 9:44 PM report created with MSRC team?

• 23 Mar 2024 at 4:34 AM case opened ?

• 2 May 2024 at 8:52 PM ruled as not a bug by MSRC?

Author: Tomais Williamson