Freigeben über

Stop using LAN Manager and NTLMv1!

  • Artikel

When performing Security checks in customer environments I often find out that LAN Manager or NTLMv1 is still allowed. Most customers don't know that this setting leaves the environment highly vulnerable to attacks targeting their authentication methods.

Why you should not use LAN Manager and NTLMv1 anymore you will read in this article.

What's the problem with LAN Manager?

LAN Manager is the 'grandpa of authentication' in Windows Systems. It was implemented in 1987 and nowadays it is old and deprecated. And yes of course, it can be broken easily.

This protocol is still used by Windows-NT based operating systems to store Password Hashes. And due to backward compatibility issues it is still in use: If a password is stored, which is shorter than fifteen Characters, a LM-Hash is generated and used.

A LM-Hash is NOT case-sensitive: Before creating the hash, all characters are being casted to uppercase characters. So it does not matter if upper or lower characters were used when creating the password.

But there is also another vulnerability, caused by the first implementation of this protocol

In the earliest implementation, it was supposed that a password will never be longer than seven characters. Therefore the initial length of passwords could not exceed seven characters. Eight bytes were used to store it: seven bytes for the password plus one parity byte.

When computer systems became faster and stronger, Brute-Force attacks became an issue to those "secure" eight byte passwords. They could easily be guessed, so it was decided to add more characters to the passwords.

But since everyone was using a password which was generated with the old recommendations and the old protocol, the new password authentication mechanism had to be backward compatible to avoid business disruption.

Therefore a new mechanism was built: eight more bytes (again seven bytes for the password, one parity byte) were added to the password to enable passwords up to fourteen characters. To maintain the usability of the old passwords, the new bytes were concatenated to the old half.

Both halves were hashed and concatenated: That's how the actual LM password hash was created.

It was considered that this hash will not be broken that easily. But that was not the truth...

There is still a risk after the fix

This mechanism is still risky: if a password is shorter than fourteen characters, all unfilled bytes will be filled with NULLs. So if a password is shorter than 8 characters, the second half (the new half) will remain empty and will be filled with those zero values.

Both halves - again - will be hashed and concatenated. But since the second half only contains zeroes, a hash over those zeroes is created.

So every time the second half is filled with zeroes, the same hash value will be used for the second part of the password.

If the password is split in two halves an attacker could compare the second half with the default hash for a password containing only zeroes. If it matches, the attacker can be sure that the password has less than eight characters.

Breaking the hash of the first half is easy: the attacker only needs to brute-force the eight byte hash, which can be achieved in under 6 hours.

NTLM

To understand why you should not use NTLMv1 anymore, you have to understand how this protocol works. NTLM is a challenge/response-based authentication protocol. It is the default authentication protocol of Windows NT 4.0 and earlier Windows versions.

How NTLM basically works

  1. When logging on, the client sends the plaintext user name to the server.
  2. The server generates a random number ("challenge" or "nonce") and sends it back to the client.
  3. The hash of the user's password is used to encrypt the challenge received from the server and returns the result back to the server ("response").
    • Using NTLMv1, the client takes the challenge "as it is", adds the client nonce (client nonce + server nonce), encrypts it using DES and sends it back.
    • Using NTLMv2, the client adds other parameters to the challenge: (client nonce + server nonce + time stamp + username + target) before hashing it with HMAC-MD5 and sending it back. These additional parameters protect the conversation against a replay-attack, an attack where data is repeated or delayed.
  4. The server sends the following three items to the domain controller to verify that the requesting user is allowed to log on:
    • User name
    • Challenge (which was sent to the client)
    • Response (which was received from the client)
  5. The domain controller looks up the user name and gets the corresponding password hash out of the Security Account Manager database and uses it to encrypt/hash the challenge.
  6. The domain controller compares the encrypted/hashed challenge it computed earlier with the response computed by the client. If both are identical, the authentication is successful.

Why you should not use NTLMv1 anymore...

NTLMv1 and NTLMv2 work quite similar, but the biggest difference is also the main problem why NTLMv1 should not be used anymore.

The difference lies in the challenge and in the way the challenge is encrypted:

  • While NTLMv2 provides a variable-length challenge, the challenge used by NTLMv1 is always a sixteen byte random number.
  • NTLMv1 uses a weak DES algorithm to encrypt the challenge with the user's hash. DES is designed to be a very fast algorithm. But as this sounds nice at first sight, this is also the biggest weakness, because it can be also decrypted very fast.
  • NTLMv2 uses HMAC-MD5 instead. HMAC-MD5 is a bit old, but slow. So brute-forcing this encryption method is not possible at this moment (let's wait for the quantum computers...).

This leaves NTLMv1 at a high risk and therefore you should avoid using it. For NTLM authentication you should switch to NTLMv2 (even better to Kerberos) and enforce it to allow only secure authentication methods in your environment.

How to deactivate LAN Manager and NTLMv1

Please be careful when deactivating LAN Manager and NTLMv1 - really!!!

Many old devices in your environment could still use those old authentication protocols. Some devices support NTLMv2, but only after configuring it on the device. So don't disable LAN Manager and NTLMv1 without knowing which devices still use it.

First step: Audit!

Prior to disabling those old authentication protocols: Listen to your devices - or better: Audit them!

If you don't know which devices are relying on LAN Manager or NTLMv1, you can't disable it without crashing some of your systems.

  1. Collect Audit Logs in a central log collection.
  2. Filter for Event Logs with the Event ID 4624 - An Account was successfully logged on.
  3. In this event you will find the section "Detailed Authentication Information"
    1. If the "Authentication Package" was NTLM, NTLM was used as authentication method
    2. Now have a look at "Package Name (NTLM only) ", if LM or NTLM v1 is the value of this attribute, LAN Manager or NTLMv1 was used
  4. Investigate all clients/servers where LAN Manager or NTLMv1 was used: why are they using this deprecated authentication protocol?

When you have investigated and upgraded every device to use NTLMv2, you are ready to enforce NTLMv2 globally in your environment.

Further resources on auditing and purging old authentication protocols

There are also some articles which could be really helpful when it comes to auditing and eliminating the usage of those insecure protocols. Have a look on these resources:

Enforce NTLMv2 only

So, you have audited your logon events and found out that no device is using old authentication protocols? You are ready to enforce NTLMv2? Very good! Read here how to do it.

The magical key you are looking for is called LAN Manager Authentication Level. This setting defines which authentication level is used.

You can either enforce it locally or via GPO:

  • Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network security: LAN Manager authentication level

Since there are 6 levels (from 0 to 5), that means 0 is the most insecure setting, but also the default in many domains which where set up using an earlier domain level (since Windows Server 2008 the default is 3). 5 is the most restrictive and most secure level - but hard to achieve.

If you want to set your LAN Manager authentication level as high as possible, start with Level 3: This level enables NTLMv2 as default, but still allows a fallback to LAN Manager and NTLMv1 in case the client is not able to use NTLMv2.

Then audit, audit, audit a lot to find out which devices are still using LAN Manager and eliminate them. If there is no client/server using LAN Manager anymore, you can set the level to 4.

And again: Audit, audit, audit, audit and audit once more! Is there really no device left which is using NTLMv1? Nice, you can set your LAN Manager authentication level to 5. Congratulations, you've just eliminated your old and vulnerable authentication protocols! Really good job!

Comments

  • Anonymous
    November 07, 2017
    https://en.wikipedia.org/wiki/LAN_Manager
  • Anonymous
    November 08, 2017
    Buen Articulo!
  • Anonymous
    November 08, 2017
    Excellent post!
  • Anonymous
    November 08, 2017
    Very good write-up!
  • Anonymous
    November 09, 2017
    Great article which describes the whole problem exactly!
  • Anonymous
    November 12, 2017
    This is really clear and informative, please write more similar articles!
  • Anonymous
    November 21, 2017
    Thank you!Great article!