Comment by tg16 | Hacker News Reader

Comment by tg16 | Hacker News Reader

Parent Full thread

I'm a Security Architect dealing with the pain of an old environment with a default NTLM configuration so i'll chime in:

- NTLM doesn't sign packets. If you can intercept an NTLM auth request you can forward that authentication attempt to another resource and impersonate the user without needing to know or crack their password. You simply MitM the challenge-response between the client and the server. This is called NTLM relaying and is a core issue of NTLM, though some protocols have additional verification such as SMB signing, which is not enforced by default.

- NTLM has relatively weak hashes, though this is far from the biggest issue with NTLM.

- NTLM (unlike Kerberos), uses a single hash for all authentication. If you can compromise this hash, you can impersonate the user anywhere. With Kerberos, each auth event generates a signed with a narrow validity period that grants access to a tuple of user, device, and resource. Meaning if you compromise a user's Kerberos tickets, you can only impersonate them on services that they already had a ticket for at the time, and for only a few hours in until those tickets expire. The NTLM hash itself is the proof-of-identity for all NTLM auth, and this can be recovered in memory or on disk for local accounts.

- NTLM, combined with older broadcast name resolution protocols (namely LLMNR, NBT-NS mDNS, and WPAD) can be very easily intercepted and abused for NTLM relaying due to the lack of signing. It is trivial in most Windows environments to run Responder.py and get an administrative session on pretty much everything. Unless the enterprise has taken steps to harden against NTLM relaying (which is difficult both for compatibility issues and the sheer number of required changes), they're going to be vulnerable to it. My current environment has top of the line network monitoring, SIEM, and EDR, but it's still very easy to slip under the radar with NTLM relaying if you know what you're doing.

This is not accurate.

NTLM provides signing and sealing using a session key. It is the responsibility of the protocol using NTLM for auth to use that key to sign or seal. The problem is that this feature is frequently turned off.

So it's actually not accurate to say "NTLM is vulnerable to relay attacks". If someone turns off signing in SMB to improve performance, that is not a problem with NTLM, that is a problem with the operator turning off signing. If a door has a lock but it's left unlocked, is that a problem with the security of the door?

NTLM also calculates a MIC over all of the NTLMSSP tokens which provides integrity protection independent of the protocol using NTLM. That MIC includes the target SPN so even if signing is turned off, it cannot be hacked.

Regarding hashes, there are two types of NTLM hashes. There are the password equivalent hashes which are only accessible through hacking system memory of a compromised machine that has access to them. It suffices to say, this is not the path of least resistance for an attacker. This is also known as "pass the hash".

Then you have what are called NetNTLMv2 hashes within the NTLMSSP tokens exchanged during authentication. These are muxed from the password and challenge using MD4 and MD5 but also RC4 if key exchange is used (session key mentioned above). This is not trivial to break. It could easily take a room full of GPUs months and maybe never depending on the generator and complexity of the password.

The problem with NTLM is not so much with the NTLM protocol itself but with the various implementations that either don't implement the necessary security features or they simply get turned off. Last I checked Windows Server domain members do not require clients to negotiate signing by default. If an acceptor required an SPN and a MIC, that would stop a relay attack even if signing wasn't used (because they would not be able to forge the MIC without the password and the MIC factors in the SPN).

Another issue is that the security community needs to find issues to justify their existence. NTLM being oldest and relatively weak crytographically naturally draws a lot of critisizm. But the facts are obscured and hyperbolized regularly. People largely regurgitate what they hear without really knowing what they're talking about. They need to to make it at least sound like they know what they're talking about. The only way anyone REALLY knows how this stuff works is to studying the documentation ([MS-NLMP].pdf), looking at captures and step through computations in code.

You admit yourself that the defaults are bad.

Because the defaults are bad, vendors have the ability to ship products that are insecure but will still work on a default / typical network.

Administrators have to make risky changes with complex monitoring systems in place to tighten the security to a reasonable level.

The larger the network the harder this is, to the point where it becomes impossible because there are too many incompatible devices.

This is the criticism of the protocol: it not only leads to a pit of failure from which each customer has to dig their own way out.

This is exactly the point i was trying to make and why i opened my comment with "default configuration environment".

I'm also not going to respond to a non-expert's plea for information with unnecessary minutiae like the differences between LM, NT, and NTLM hashes or the differences between NTLMv1/v2 and NetNTLM. My ommissions were intentional because i'm trying to make my comment approachable.

In a default, non-hardened Windows environment, NTLM is a nightmare. Yes, it can be secured. No, it is not straightforward.

Reply on news.ycombinator.com