In case you didn't catch it on bugtraq or full-disclosure or twitter :), please take a look at the advisory for Windows SMB NTLM Authentication Weak Nonce Vulnerability:
http://www.hexale.org/advisories/OCHOA-2010-0209.txt
It's basically a 14/17-year old vulnerability in the Windows implementation of the NLTM Authentication protocol... goes back to the Windows NT 4 days!
I´ll do a post later commenting on some of, what I think, are the most interesting and important facts said in the advisory that perhaps you didn't catch when reading it or were not clearly described.
Thank you!.
7 comments:
Hernan,
Wasn't that smbrelay stuff mentioned in your advisory fixed by MS08-068?
Hi!
This is NOT an smbrelay attack/bug/vulnerability.
This is an implementation flaw in the challenge/response NTLM authentication method.
It sounds similar to smbrelay because some of the attacks scenarios mentioned are similar, but this is not smbrelay.
This issue is not related to smbrelay, and was reported after MS08-068.
MS08-068 does not prevent this attack.
This vulnerablity has its own patch (not MS08-068) because it's a different vulnerability (MS10-012).
Thank you!,
Hernan
Yes I see. But I mentioned this just because of that part from your advisory:
An attacker A connects to system S and sends mutiple 'SMB Negotiate Protocol Request' packets with the 'Flags2' field set to 0xc001 to obtain several challenges, and stores them. The attacker A then forces a user U on system S to connect to his own specially crafted SMB server, for example by sending an email with multiple imgtags with UNC links (e.g.: img_src=\\evilserver\share\a.jpg) or a link to web server with similar IMG tags. Upon receiving the connections from system S,the attacker's SMB server will respond with the previously obtained challenges and will store the corresponding responses returned by the remote system. Attacker A has now a set of responses which are the challenges encrypted with user's U credentials.
Finally, the attacker A will perform several authentication requests to system S until it returns one of the challenges obtained at the beginning of this attack, and at that point he will replay the corresponding and previously obtained response to gain access to system S as user U.
But, according to http://blog.metasploit.com/2008/11/ms08-067-metasploit-and-smb-relay.html, for example:
Taking this further, the attacker can connect back to the victim, ask them for their challenge key, and then pass this key back to the victim's client connection. The client will then encrypt their hashed password against this key and send it to the attacker. The attacker then uses this hashed password to authenticate back to the victim, using their own credentials against them. This is the attack implemented by SMB Relay 2, the Metasploit Framework, and the one patched today in MS08-068.
...
he MS08-068 patch addresses this attack only in the case where the attacker connects back to the victim. The patch works by checking the received challenge key against a list of active keys that its own SMB service has issued. If the challenge key matches the list, the authentication process fails.
These two attacks sounds similar so looks like some contradictionns here...
Hi Toxa!,
There are no contradictions.
I understand where you are coming from and why you are seeing similarities, but again, these are two different vulnerabilities/attacks.
MS08-068 does not fix this attack because this is a different vuln. You can try it yourself.
This is not SMBRELAY.
Now, you see similarities because of SOME of the attack scenarios we mention, but these are different vulns.
However, the attack scenarios are not exactly the same either, I'm gonna describe the differences. Still, understand that these differences in the attack scenario you mention (there are other attack scenarios) are not the things that make these two attacks different attacks (they just add to the differences), these two attacks are different because they are different flaws altogether. The advisory explains in great detail where is the vulnerability, gives you pseudo-code for the vulnerable code, you can check it out yourself and understand this a different vulnerability.
Smbrelay is relaying an undergoing auth session doing MITM to take over that individual auth session. you're relaying a connection to another connection you make to the same victim (when doing reflective smbrelay).
'SMB NTLM Weak Nonce' is not relaying anything.
step 1: You make a lot of connections to get challenges, all these are *different* connections that you create and *terminate*.
step 2: *After that*, you make the client connect to you. The client makes connections to your server, you send all the challenges you obtained before, the client encrypts them. These are all *individual* connections, the client makes connection, you send challenge, client send encrypted challenge, you *close* the connection.. and then you do the same thing for all other challenges you have and other incoming connections.
step 3: at a later time, you make a *new* set of *individual* connections to the server, until you get a duplicate challenge, and that point, you replay the response obtained before.
All steps use different connections that are started and terminated. Once you have the challenges encrypted after step 3, you can use them *multiple times* because the randomness of the challenges is that bad. That means, you exploited the attack at 3am on Monday..ok, three days later, without having to make any client connect to you, you can run the exploit again and you'll get in...
Also, you can *predict* the challenges like we explained in the advisory.
Does this help understand the differences and why there are no contradictions?
I Hope it does! :)
Thank you!,
Hernan
Yes, Hernan, this helps, thanks.
I completely understand where this attack came from, I just was a bit confised with a description of attack scenario.
Now I see, as you mentioned, the key thing is that connections are in fact subjected to termination. In this case, sure, MS08-068 patch doesnt help.
Didnt have a chance to look at actual code, and description in the original advisory is not that detailed, made me think this has relay stuff involved somehow.
Thanks for clarification!
Hernan,
as it's PRNG-related weakness, it doesnt matter NTLMv1 or v2 is used, right?
Thanks.
correct. it affects both ntlmv1 and ntlmv2.
Post a Comment