There is currently an architectural vulnerability within the Windows SMB authentication protocol that affects modern Windows Operating System.
The core of this issue is due to the presumptive nature of current SMB authentication methods. When a user accesses a file share or remote file (by typing “file://” or “” in a browser or file explorer) hashed Windows credentials from the current user are automatically sent to the remote server in attempt to authenticate and access the remote file. The default behavior of assuming the remote server is trusted allows for systems to quickly access file shares in large corporations so that users won’t need to sign in with their company credentials each time to access network resources. However, this implementation presents a significant security risk to user accounts and passwords.
As a result of Windows’ assumption to automatically send current user credentials: when accessing any remote SMB file share Windows will automatically provide the user’s hashed credentials to the remote server without any notification. The sent information includes the user’s IP, computer name, domain, username, and password hash (LM, netNTLMv1 or netNTLMv2) in cleartext, across the Internet. This happens regardless of the Active Directory settings configured or the user’s distance from the target machine on the Internet.
As an attacker there are a myriad of ways to take advantage of this issue. Admittedly, the attacker still needs to crack the collected hash; however, most organizations’ password policies still allow passwords that can be cracked in reasonable timeframes. Given enough time against a target, it is highly likely that an attacker will collect crackable hashes. Potential attack vectors include:
Physical Access
The Physical attack vector for this issue is very straightforward, but still significant. If you have access to a Windows machine that you would like to know the password to: just type in the address to your malicious SMB share in the browser, and then attempt to crack the hash. If the logged in user has administrator rights, you may even be able to grab the built in local administrator password hash. This is also the case for remote access such as RDP.
Web browsers
Internet Explorer specifically does not restrict loading SMB share resources within elements such as image tags or Javascript redirects. As a result, any webpage browsed with any version of IE (Edge included) can obtain the visiting user’s password hash. Other browsers such as Chrome and Firefox do not allow the user to mix SMB resources with online content, which protects users from HTTP injection of these malicious SMB servers. However, a user browsing to the share directly in any browser will still trigger the authentication request. Additionally, SMB links can be hidden as 1×1 pixel image links. This adds a powerful new exploitation vector to web application attack that causes the victim browser to request an image (XSS and XFS come to mind).
Mail Clients
An attacker attaching HTML content that references an SMB share resource, such as within an image tag, will also divulge credential information when opening the email. It is also possible that some spam protection utilities or services that check incoming emails could send out the credentials when reading the malicious email. This could effectively result in credential compromise without any user interaction. Disabling content auto loading is a good way to prevent this from happening. In testing this vulnerability, we discovered that in some instances when clicking a link to the SMB share in an email the client would warn the user of the external resource, but simultaneously send the hash anyway. The proof of concept below was tested in Outlook 2016.
Spoofing
Man-in-the-Middle attacks, such as ARP spoofing or Broadcast Resolution Poisoning can allow an attacker to inject SMB resources into the victim’s network traffic such as an image tag with a source of “Attacker.xyz/SHARE/evil.png”, which will also result in sending credentials to the attacker.
XSS
Any website vulnerable to reflective XSS could allow an attacker to inject a payload that loads a malicious SMB resource. Any victim browsing to that exploited site would unknowingly surrender their hashed credentials to the remote server. Browsers such as Chrome or Firefox that disallow SMB resource loading on an online page would not be susceptible to this attack vector.
There are plenty of other ways to take advantage of of this issue as well. Effectively, whenever it is possible to get a Windows machine to touch an online resource, its password can be retrieved. Thanks to standalone utilities such as Impacket, which can create rogue SMB servers, this attack vector is feasible for anyone to execute.
Why Isn’t This Fixed
Given the trivial nature of exploiting this issue, it is unsurprising that some documented cases that resemble this problem exist online. Presentations at Blackhat in 2007 and again at DEFCON in 2015 highlighted parts of this issue, but still much of the security community has yet to give ample attention to what should be considered a severe issue.
What Needs to be Done
Microsoft needs to create a configuration option to disable auto-negotiation of credentials for remote resources. This would require users to manually type account credentials, which allows users to confirm they intend to sign into a service, instead of transparently passing along credentials to a random server. Additionally, even before an authentication exchange occurs, the client should fully validate the remote server utilizing client certificates, PKI or similar technologies.
What You Can Do
Egress filtering is the best solution to prevent this vulnerability from being exploit remotely. By blocking port 445/tcp (SMB) outbound IT administrators can prevent users’ from sending hashed credentials to a remote attacker. Some Internet Service Providers, such as AT&T, block SMB outbound for home users by default. From an internal prospective this is a tricky problem to resolve unless Microsoft gives Administrators the ability to disable this automatic negotiation or restrict auto-authentication to trusted machines.
Implications
This can be leveraged to gain significant access into a company’s network or a person’s personal life. The only thing the attacker needs to do after receiving the hash is to crack it. Due to user proclivity to use weak passwords and the relatively weak netNTLM hashing mechanisms, cracking these hashes is typically easier than collecting them in the first place. The availability of current password dumps and common augmentations within those passwords also eases the job of cracking collected hashes. These hashes could also be relayed to another victim on the network for authentication without the need to crack the hashes.
