By Keren Pollack, on September 12th, 2019

NTLM is Microsoft’s old mythological authentication protocol. Although new and better authentication protocol has already been developed, NTLM is still very much in use. Basically, even the most recent Windows versions support NTLM and even Active Directory is required for default NTLM implementation.

 

The NTLMv1 protocol uses a TNHash or KM hash (depending on configuration), in a challenge/response method between the server and the client. NTLM authentication flow:

  1. The user machine sends a request to connect to the server.
  2. The server generates a random nonce to be encrypted by the user.
  3. The user machine encrypts the nonce with the password hash to prove knowledge of the password.
  4. The server validates the users’ identity by ensuring that the challenge was indeed created by the correct user password. It does it either by using data in its own SAM database or by forwarding challenge-response pairs for validation in the domain controller.

 

NTLM v2 also uses this flow with a slight change. In NTLMv2 the client includes a client nonce and a timestamp. This add helps with mitigating offline replay attacks, but leave NTLMv2 exposed to other NTLMn1 vulnerabilities, thereby doesn’t provide a good solution.

Because it is so commonly used, it is important to be familiar with all of the NTLM vulnerabilities. If you use this protocol, you are fore sure exposed to attacks due to the following issues:

 

Weak cryptography:

NTLM cryptography scheme is relatively weak, making it relatively easy to crack hashes and achieve plaintext passwords. Easy enough for standard hardware to be able to crack an 8 characters password in less than a day. This is for three main reasons:

  1. The hash is based on MD4, which is relatively weak.
  2. The hash is saved unsalted in a machine’s memory before it gets salted and sent over the wire.
  3. A user must respond to a challenge from the target, which exposes the password to offline cracking. This is the worst weakness, but it is solved in NTLM v2.
No mutual authentication:

This flaw exposes the protocol to a man-in-the-middle (MITM) attack. When a client to a server, it cannot validate the servers’ identity (one wat authentication). If a malicious actor gains MITM capabilities, he could send the client malicious data while impersonating the server.

 

These flaws are considered minor when you put in mind the most critical NTLM flaw that allows NTLM relay and remote code execution attack. This is especially relevant to Active Directory environments and can cause massive damage.

 

If the attacker can hijack the connection, he can spread laterally to the entire system, doing whatever he wants while using the user’s credentials. While Microsoft has tried to develop mitigation for this issue, all of those mitigations have proved to have bypasses, thereby they do not provide an answer for this matter.

 

Mitigating relay NTLM remote code execution vulnerability

 

No NTLM version gives a solution for this issue, which means that all NTLM users (which is most likely almost all of you that have continued reading up until here) are at great risk for a devastating attack.

 

The goal of this post is to alert NTLM users about its potential damage. Our main conclusion from this situation is that the best way to protect your organization from NTLM vulnerabilities is in fact, not to use it!

 

While better solutions are already in use, the obvious question is why NTLM protocol is still here? Basically, because NTLM is a legacy protocol, it is very hard to disable it without causing damage to production. The challenge starts first with determining which machine needs this protocol for its function and which doesn’t. After mapping the usage, it is hard to determine how to move from NTLM usage to a more secure authentication protocol.

 

But there’s a solution to all the challenges evolved in NTLM abandoning. CalCom’s hardening automation solution (CHS) will provide you all the answers in one product. CHS will learn your system and will determine exactly which server can continue working without outages after disabling NTLM. It will alert about the potential impact when disabling the protocol. After you’ll decide what is your course of action according to the information produced by CHS, CHS will automatically implement your choice on the entire production environment, significantly reducing the potential for configuration drift.

 

 

 

https://blog.preempt.com/the-security-risks-of-ntlm-proceed-with-caution

https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4