Is there a security concern exposing NTLM authentication over http or should it only be https?

Question

We are setting up a SharePoint 2010 site. Don't worry, this is not a Sharepoint question, just adding it for context. Most of the site will be anonymous, but some users are able to authenticate in and edit content. They use NTLM (users exist in AD). Is there any concern about exposing NTLM login for users that can modify content over the internet via http or should that only be exposed via https?

Solution 1

NTLM over plain HTTP is insecure. Attackers that passively sniff traffic or who perform a man-in-the-middle attack can use various methods to steal or abuse credentials. For example:

• NTLM relay attacks: when a user thinks they are authenticated to SharePoint, the attacker can instead forward the NTLM challenge of some other service (like Outlook/Exchange or an SMB share) in the domain, and gain access to that as well. Even when the second service is using HTTPS!
• Offline dictionary attacks: after observing an NTLM challenge and response, an attacker can recompute the exchange for some password P. When it matches, it means P was the user password. The attacker can keep trying P's until the password is found. The effectiveness of this attack depends on password strength, but by using standard tools, a good dictionary and stone GPU acceleration, even moderately complex passwords can be cracked.
• Session hijacking: an attacker who is just interested in SharePoint can also simply ignore the NTLM exchange and take over the users' SharePoint session (e.g. by stealing cookies or injecting JavaScript). This gives them the same read/write access as the user.
• Website spoofing: am attacker can show a fake login screen asking for AD credentials. Since users probably trust SharePoint, it's not unlikely they would fill them in and thus provide the attacker with a plaintext password.
• NTLMv1 downgrade: depending on the client configuration, an attacker may be able to get them to perform an NTLMv1 handshake. This has all the cryptographic weaknesses of NTLMv2 (i.e. vulnerability to dictionary and relay attacks) but after cracking a two DES keys (pretty cheap and fast nowadays) it gives them access to the users' raw NT hash. A dictionary attack against this is far more efficient. Furthermore, this value can be used for a pass-the-hash attack, allowing the attacker to log in as the user (against most services) without a password.

Bottom line: treat NTLM authentication the same as authentication with plaintext credentials. In this case, this means you should use HTTPS of you want to protect against attackers on your network.

Solution 2

You won't be exposing credentials in cleartext using NTLM over HTTP. You will be exposing everything else, so your data won't be secure from confidentiality or integrity breaches (eavesdropping or modification of the data "in flight").

Comments

[Admin]

FYI, NTLM is deprecated. Microsoft recommends Kerberos instead (which is safe to use over plaintext protocols).

[Admin]

And to add to what @grawity said, any users behind certain proxies and filters (squid is one I know of for sure) won't be able to log in with NTLM authentication.

[Admin]

And before you ask, one can use Kerberos over HTTP, and SharePoint supports it.

[Admin]

More clarification, we are using NTLMv2

[Admin]

@KJ-SRS: As long as a proxy supports HTTP/1.1 it won't present a problem using NTLM authentication.

[user1686]

"if you see it, it's bad" doesn't always apply. NTLM v2 is a challenge/response protocol, supposed to remain secure even in this case (the password hash sent cannot be reused). On the other hand, authentication mechanisms very often have subtle flaws unnoticeable through simple visual grep of packets. (You cannot see the difference between a chunk of AES ciphertext and a chunk of XOR ciphertext.)

[Alexandre De Bruyn]

That's okay, this is a public anonymous site. The only reason we need authentication is because it is a CMS, so certain users that have rights to edit content are able to log in via NTLMv2

[Marcin]

'If you see it it's bad' is true. 'If you don't see it then it's good' is not necessarily true however. With challenge/response protocols you gotta study the protocol of what is being asked and how the response is generated, then seeing if you can obtain all the necessary information. en.wikipedia.org/wiki/NTLM#NTLMv2 has the details of what gets used. Time can be closely estimated, user and domain names can be determined, so the only truly random bit is 8byte random nonce, so that can probably be guessed in not too many tries.

[squarewav]

This post is complete nonsense. Relay attacks do not work if SMB signing is enabled which it ALWAYS is and always has been for as long as I can remember. Offline dictionary attacks are NOT from "observing and NTLM challenge and response". It requires breaking into a machine with SYSTEM privs and using drsuapi / wmi to snarf RAW ntlm password hashes straight out of memory. You cannot "downgrade" to NTLMv1. NTLMv1 is should be completely rejected in any environment where people care about security.

[squarewav]

@Marcin - But you're not just guessing the nonce. You would have to completely recompute your dictionary of secrets for each nonce which is computationally expensive. Maybe that's something a nation state with a warehouse of graphics cards can do but otherwise, trying to reverse a typical NTLMv2 auth is not the weakest link. NTLM is not as insecure as the security companies want you to believe. They just pounce when there's a stupid code error like CVE-2019-1040 but as long as you have the patch, you should be fine.

[AardvarkSoup]

@squarewav You are completely correct that ntlm relay attacks to SMB services can be mitigated through SMB signing (or enforcing SMB3). There are also similar mitigations for other protocols (EPA, SPN binding, LDAP signing etc.). However, in my experience services without relay mitigations are still very common in many environments. Clients still supporting NTLMv1 are much more rare, though.

[AardvarkSoup]

Furthermore, it is certainly possible to perform an offline brute-force attack against NTLM handshakes (see also hashcat's NetNTLMv2 type). This is more expensive than cracking a raw NTLM hash, but still very feasible (you're basically brute-forcing a 'salted' HMAC-MD5 digest of an MD4 hash of the password).

[squarewav]

Your post is still hype. Getting to the point where you can obtain a suitable / useful netntlmv2 hash to reverse is a lot harder than you characterize. But if it makes you feel cool to recite nonsense you read on the internet, go for it. I'm not going to tear you down that much considering how many other equally hyped blogs there are about NTLM in-security.