Microsoft Live Account Credentials Leaking From Windows 8 And Above (hackaday.com) 55
An anonymous reader writes: Discovered in 1997 by Aaron Spangler and never fixed, the WinNT/Win95 Automatic Authentication Vulnerability (IE Bug #4) is certainly an excellent vintage. In Windows 8 and 10, the same bug has now been found to potentially leak the user's Microsoft Live account login and (hashed) password information, which is also used to access OneDrive, Outlook, Office, Mobile, Bing, Xbox Live, MSN and Skype (if used with a Microsoft account). The bug itself seems to be present in all Windows systems since Windows 95 / NT, although only Windows 8 and above are effectively compromised. To see if your machine is affected, you may want to check the public demonstration of the exploit, set up by the guys from [Perfect Privacy] and based on [VladikSS] original work. Basically, the default User Authentification Settings of Edge/Spartan (also Internet Explorer, Outlook) lets the browser connect to local network shares, but erroneously fail to block connections to remote shares. To exploit this, an attacker would simply set up a network share. An embedded image link that points to that network share is then sent to the victim, for example as part of an email or website. As soon as the prepped content is viewed inside a Microsoft product such as Edge/Spartan, Internet Explorer or Outlook, that software will try to connect to that share in order to download the image. Doing so, it will silently send the user's Windows login username in plaintext along with the NTLMv2 hash of the login password to the attacker's network share.
So that's what it does? (Score:1)
I always found it odd when accessing network shares between users with the same name and password that it never prompted me for one.
Re: (Score:3)
I always found it odd when accessing network shares between users with the same name and password that it never prompted me for one.
It was a great workaround back before active directory. If you didn't have access to a share, just figure out the owner's username (pre-populated on their lock screen), and create a new local user on your machine with the same username, connect to the share as that user, done.
Re:So that's what it does? (Score:5, Insightful)
It was a great workaround back before active directory. If you didn't have access to a share, just figure out the owner's username (pre-populated on their lock screen), and create a new local user on your machine with the same username, connect to the share as that user, done.
That workaround doesn't work... the password has to match as well.
Windows IE sucks again! (Score:1)
Windows IE sucks again!
Re: (Score:1)
Windows IE sucks again!
"Now with New, New, New MS Edginess!!!"
Re: (Score:2)
I would assume, perhaps wrongly, that in this instance "share" means anywhere that Outlook, IE, Edge, etc can reach...
Meaning anywhere on the internet, otherwise this vulnerability wouldn't be as big of a deal.
Re:n3rdspe4k (Score:4, Funny)
Yes, the use of the word "share" can be misconstrued in this context.
Think of it in the context of heroin users "sharing" a needle, or when a child coughs directly into your face to "share" his cold with you.
That's the problem. It's internet, Windows thinks (Score:4, Informative)
It can be over the internet.
Confusion between the local network and the internet is the source of the problem. Windows is supposed to automatically log in to LOCAL shares. Instead it will automatically log in to shares anywhere on the internet, when it sees a link to a share.
Re: (Score:3, Informative)
The critical thing that isn't getting enough attention here is that it requires IE to work. If you visit the test site in Chrome or Firefox it tells you to come back in IE. So it's not nearly as bad as it first appears.
Re:That's the problem. It's internet, Windows thin (Score:4, Insightful)
I'd prefer if it didn't do much distinction. One compromised device inside a local network shouldn't be enough to escalate it to control every device inside. If you trust devices on a basis "its in our network", then you are doing something wrong.
Re: (Score:2)
Most companies let people reach out to wherever they want.
The vast majority of filtering/firewalling is done for the opposite direction - blocking shit coming in that doesn't already have an established connection.
Re: (Score:2)
Didn't MS Plan it this way? (Score:1)
Come on!
So... (Score:3)
If I block outbound CIFS/SMB connections at the firewall, this should solve the issue, correct?
Re: (Score:3, Informative)
Have not had a chance to confirm, but from looking at the wireshark SS I would infer blocking outbound 137-139 and 445 should work. However, if you have a webdav (or w/e MS calls it these days) plugin enabled that may be another vector in which this could be used.
Re:Is this news? (Score:5, Informative)
If we had an article for every security vulnerability/backdoor found in a Microsoft product, it'd be impossible to find anything else on Slashdot.
What's newsworthy in this case is that the vulnerability remains unpatched since 1997. That is older than some of my kids. That's almost old enough to drink.
Re: (Score:2)
If we had an article for every security vulnerability/backdoor found in a Microsoft product, it'd be impossible to find anything else on Slashdot.
What's newsworthy in this case is that the vulnerability remains unpatched since 1997. That is older than some of my kids. That's almost old enough to drink.
That's not unprecedented either: http://www.bbc.com/news/techno... [bbc.com]
Re: (Score:2)
And plenty old enough to drink in Europe ;)
Re: (Score:2)
That's almost old enough to drink.
And now you've made me feel old.
Re: (Score:2)
I can see how this is one of those "it's not a bug, it's a feature" arguments.
Probably "unpatched" because some big customer of MS is using this "feature".
Though, why they wouldn't just determine the internal vs. external links by using site-and-services and/or IE zone profiles... I don't know.
Re: (Score:2)
You just answered the question. Probably the same big company using the bug is probably the same one that has many internal sites marked as external sites for whatever reason.
Re: (Score:2)
This just adds to that feeling of anger I have (Score:2)
trying to navigate all of Microsoft's many convoluted username/password schemes.
For the love of all that is holy.. consolidate some of these logins, Microsoft!
Re: (Score:3)
For the love of all that is holy.. consolidate some of these logins, Microsoft!
They did that with Microsoft Passport (also known as .NET Passport, Microsoft Passport Network, and Windows Live ID).
I'm not sure how it fared or what the overall success rate of the consolidation was.
Re:This just adds to that feeling of anger I have (Score:4, Informative)
Its "login consolidation" (specifically the move with Windows 8 and 10 to use your Live/Hotmail/Outlook/Microsoft/etc login as your desktop login) that is the cause of this bug in the first place.
Thankfully I am on Windows 7 (and would use a local login rather than a cloud login in any case even on Windows 10) so this issue doesn't affect me. (no domains, VPNs or anything else involved either, its just a local login for my desktop)
It seems to also leak Windows Domain credentials (Score:1)
(Per the results I saw with the testing tool.) That means they could get e.g. VPN or email credentials, too.
This IS configurable (Score:1)
and the defaults are horrible.
To protect yourself, goto Internet Options -> Security Tab
"Custom level...." -> scroll to bottom, change "User Authentication - Logon" setting from "Automatic login only in Intranet zone" to "Prompt for user name and password".
Repeat for all four zones. Your Internet Explorer install will no longer leak password hashes.
Then do yourself a favor and use another browser for daily browsing.
Why are firewalls not blocking this today? (Score:4, Interesting)
I'm not sure what's more pathetic here, the age of this Microsoft bug, or the fact that so many firewalls do NOT block the relevant outbound TCP ports by default.
Seems both are equally as culpable.
Re: (Score:2)
It seems a little overkill to block outbound connections to ports 80 and 443 just to prevent yourself from making a login attempt.
Further, if you don't allow ports 80 & 443 to initiate your connection, you'd have no idea if a site returned a 401 'authentication required'...It just sounds like an unworkable painfully manageable solution that basically removes "Internet access" from your users (without web that is how your users will see your firewall setup as)
I would agree with you.
Perhaps that is why the internet-facing ports I was referring to are 137-139 and 445, which hardly is an unworkable solution.
computerphile (Score:2)
here's an amusing video [youtube.com] showing how simple it is to crack password hashes. teh NTLMv2 hash is only about 4 times slower than the hash he uses in the video.
Re: (Score:2)
Wasn't part of the point of NTLMv2 (vs. NTLMv1) that it required a challenge/response with the server, to make stolen hashes less useful?
Re: (Score:2)
i think you're right: you can't replay the hashes. but the point of the video is that it's now almost trivial to brute-force the cleartext passwords from the hashes, especially if you have a huge corpus of harvested hashes. actually, the main point of the video is that generally people think their passwords are much more secure than they actually are.