Downgrade of NTLM Authentication



  • I have been experimenting NTLM and its different relay mitigations, including MIC and channel bindings.

    In my understanding:

    1. ntlm auth starts with a negotiation packet sent by the client. In this negotiation packet, the client describes which versions it supports.
    2. according to that, the server chooses which version to use (rejecting in case of mismatch)
    3. server sends the challenge

    My question is, which flags indicate the version support for NTLM by the client? And also, is it possible to relay clients who support both ntlmV1 and ntlmV2 while forcing it to use ntlmV1?



  • The NTLM protocol is documented by Microsoft. In § 2.2.2.5, the flags are described that outline which version of the protocol is to be used. There are several variants that can be selected, including the variants we normally refer to as NTLMv1 and NTLMv2.

    When the server selects the version based on the client value, if it accepts any authentication that does not involve integrity checking of the initial negotiate message, then it is vulnerable to a downgrade attack to force it to use less secure protocols. This means that NTLM must be used only over secure connections (e.g., TLS) with trusted, properly configured servers.

    Note that you don't ever want to use NTLMv1. NTLMv1 uses DES, which has a 56-bit key, and the security of that user's credentials is downgraded to 56 bits if any NTLMv1 exchange is ever exposed; the entire password hash can be recovered. The cost to conduct this attack is USD 20, assuming you're willing to wait a little bit, so any reasonably bored teenager can afford to compromise your systems.

    Of course, since all versions of NTLM involve unsalted MD4 and either single DES or MD5, you'd want to avoid them altogether in favor of something more secure, since all of those constructions have been known to be completely insecure for over a decade and a half. Using a randomly-generated plaintext credential over TLS means that you can store the password more securely on the server side, or, if you need compatibility with Windows's built-in authentication, you can use Kerberos. Note that Kerberos supports forwardable and proxiable tickets if you need to use the client's credentials to access something on their behalf.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2