3

I am trying to figure out if NTLMv2 is vulnerable to a reflection attack. I cannot find a citation that clearly states NTLMv2 as being vulnerable. NTLMv1 is horribly insecure so there really is not point in even discussing the security of NTLMv1. No client should initiate NTLMv1 and no server should accept it.

The reason I have doubts is that NTLMv2 has "Target Information" that includes the name of the server the client is initiating to. Here is a screenshot of this Target Info from a typical NTLMv2 over HTTP authentication:

enter image description here

If an attacker tried to reuse this challenge by sending it back to the server over a separate authentication instance, the server could clearly see the target information was simply not correct. And you can't change the target information because it's factored into final token so the hash would come out wrong.

So can some explain to me precisely how a reflection attack would work with NTLMv2?

UPDATE:

Ok, then let's talk about this "SMB Relay Attack" which several people have mentioned. I am interested in any NTLMv2 exploit.

Specifically, the links posted by markgamache are not clear about NTLMv2. It does not explain the precise mechanism. Yes, a man-in-the-middle is easy with the NTLMv1 NTLMSSP_AUTH hash (not to be confused with the password equivalent hash obtained from something like meterpreter> hashdump). But NTLMv2 is different. It was specifically designed to thwart MITM types of attacks. My understanding is that it uses the "Target Info" block which contains the "DNS computer name" and "NetBIOS computer name" of the target (see screenshot above). This block of data is factored into the computation of the NTLMSS_AUTH hash. Therefore I would think that either the client or the server would detect if this information is incorrect (with or without signing).

Unfortunately it seems like a lot of the documented exploits are 90% about NTLMv1 and then they just casually claim that NTLMv2 is equally vulnerable without providing the details. It makes me wonder if they are mixing up unrelated concepts. For example, if an attacker obtains the raw password equivalent hashes, they can be used with NTLMv1 or NTLMv2. But of course this requires either Administrative credentials (to insert code into lsass.exe to dump passwords) or brute force NTLMSSP_AUTH hashes which is difficult.

UPDATE 2:

After a lot of web searching, I think this link (provided indirectly by atdre) is the best description of the Reflection / Relay issue which are largely the same:

Protecting Privileged Domain Accounts: Network Authentication In-Depth

Regarding the Target Information block, I can only conclude that clients simply do not try to verify that the name matches the target for whatever reason.

squarewav
  • 179
  • 1
  • 5
  • I'm confused. NTLMv2 is not vulnerable to this type of attack, but you want us to tell you how it is vulnerable to this type of attack? Or how it *could* be? What about all that "challenge" overhead in your screenshot? – schroeder Mar 13 '17 at 15:19
  • As stated in the first sentence of the question, I am trying to figure out if NTLMv2 is vulnerable to a reflection attack. I doubt that is because of the "Target Info" so I'm hoping someone can explain precisely how a reflection attack would work with NTLMv2. Could it be that all of the talk about NTLM reflection attacks are specific to NTLMv1? – squarewav Mar 13 '17 at 15:31
  • I think you are referring to "pass the hash", which is a type of reflection. which makes your screenshot not applicable. Yes, NTLMv2 is vulnerable to pass-the-hash, and that is well-documented. – schroeder Mar 13 '17 at 15:41
  • No. Pass-the-hash involves first obtaining the raw password-equavalent hash of the target. Natrually, there no defense against that. What I am asking about is a Reflection Attack which involves sending the challenge back to the target using a separate authentication thereby tricking it into answering it's own challenge. This is known as a "Reflection Attack". – squarewav Mar 13 '17 at 17:28
  • I'm trying to find some support for your statements in your question, and I really can't find any. Every source talking about NTLM reflection also appears to affect v2 as well, but they are all mitigated. So, on one hand, if you want to know how it works, then you already have that info. But on the other, it's been fixed, except for the well-known WEBDAV vuln (which has mitigations). So, I want to conclude that I'm still not sure what you are asking, or you haven't researched enough, but I can't tell which. – schroeder Mar 13 '17 at 17:53
  • What source indicates that it "appears to affect v2 as well"? That is precisely the information I seek. Everything I have looked at does not explicitly state NTLMv2 is affected. When they leave out such an important bit of information, I cannot help but be suspicious. Meaning they want to give the audience the impression that they have found an important vulnerability when in fact it was only lowly NTLMv1. – squarewav Mar 13 '17 at 18:14
  • First, v2 was introduced in 1998 and supported by default in Win2k. Second, articles I'm finding specifically mention v2: https://pen-testing.sans.org/blog/2013/04/25/smb-relay-demystified-and-ntlmv2-pwnage-with-python – schroeder Mar 13 '17 at 19:58

3 Answers3

2

Reflection? Not unless the system has failed to patch MS08-068.

Relay? Yes, NTLMv2 is vulnerable because of SMBv1/v2. Here are details on that attack -- https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/november/introducing-chuckle-and-the-importance-of-smb-signing/

The SMB Relay and NTLM Relay attacks are thwarted if SMB signing is enabled, if Enhanced Protection for Authentication is enabled, or if all clients are Win10 while all servers (including domain-functional level) are Server 2012 R2 or higher. See more in this answer -- https://security.stackexchange.com/a/139578/140

atdre
  • 18,885
  • 6
  • 58
  • 107
1

The attack is called NTLM relay, not reflection. NTLM, in any modern implementation, is immune to replay, not only a couple of implementations are immune to relay. Those that are include required NTLM signing. SMB/CIFS and LDAP can do this, not not HTTP.

Posters are correct, this is not PTH. The attacker never gets the users NTLM hash.

The key to the attack is that it happens in real time. The victim is tricked into connecting to a pwned server. That server then connects to the attack target and gets its NTLM challenge and sends it on to the victim to have the response calculated. It then receives the response and sends it on to the target system and access is granted.

https://www.owasp.org/images/1/1d/NTLM_Relay_Attacks.pdf https://pen-testing.sans.org/blog/2013/04/25/smb-relay-demystified-and-ntlmv2-pwnage-with-python https://cqureacademy.com/blog/penetration-testing/smb-relay-attack

markgamache
  • 153
  • 5
0

The first link I posted clearly states NTLMv2 is also affected. It is unclear what you are asking for, as you are not reading the sources nor trusting those who answer you.

While Pass-the-Hash does require admin rights to place the hash in lsass, this is not on your victims system. The attacker just needs admin rights on a host with access to the victim.

schroeder
  • 123,438
  • 55
  • 284
  • 319
markgamache
  • 153
  • 5
  • you can comment on your own Answer, I think – schroeder Mar 14 '17 at 14:47
  • No, they *claim* NTLMv2 is affected. They do not show how. That's a big difference. I am asking for protocol details. What is the cryptographic point-of-failure. – squarewav Mar 14 '17 at 16:22
  • There is no cryptographic failure. There is a protocol design failure. There is nothing binding the handshake to the end points, if signing is not required. When the victim takes the challenge and encrypts (V1) or HMACs (v2) it with his/her hash, the response is valid when handed off to a DC no matter who offers it. In NTLM relay, the attacker relays a legitimate NTLM challenge to the victim and then collects the response and uses it for evil rather than good. Signing binds the session from the victim to the intended server so that a rogue server cannot use the response. – markgamache Mar 14 '17 at 19:39
  • Ok. I have updated my question again with a good link. Between that an your comment I guess I have enough understanding now. I always thought the Target Information block was added in v2 specifically to thwart this type of attack. But I guess client's simply do not check it or they can't because it wouldn't work if the target was an IP or there were name canonicalization issues. I guess signing and EPA is the solution for now. – squarewav Mar 14 '17 at 20:33