SoylentNews is people
SoylentNews
Submitted via IRC for soycow1984
Microsoft has patched only recent versions Windows against a dangerous hack that could allow attackers to steal Windows NTLM password hashes without any user interaction.
The hack is easy to carry out and doesn't involve advanced technical skills to pull off. All the attacker needs to do is to place a malicious SCF file inside publicly accessible Windows folders.
Once the file has been placed inside the folder, it executes due to a mysterious bug, collects the target's NTLM password hash, and sends it to an attacker-configured server. Using publicly available software, an attacker could crack the NTLM password hash and later gain access to the user's computer.
Such a hack would allow an attacker that has a direct connection to a victim's network to escalate access to nearby systems.
Source: Bleeping Computer
(Score: 5, Informative) by choose another one on Wednesday November 08 2017, @01:13PM (2 children)
tl;dr: person who puts world-writable directory on the internet wonders WTF Microsoft were thinking when it turns out to be a security hole.
[and that was a facepalm who-the-f*** thought that was a good idea back in the _last century_ when I saw it (and the bandwidth bill for the warez...) happen to a company].
My bet is that it is not execution, but rather link-following. SCF files (similar to .LNK files, what Windows had for symlinks in the GUI before it got actual symlinks in NTFS) are text files with limited (though sparsely documented) capability. However, one thing they can contain is links to icons which may be external, this has been the source of previous known holes, for example: https://defensecode.com/news_article.php?id=21 [defensecode.com]
Note that .LNK files used to have similar functionality which was removed due to being an attack vector - why the same was left in .SCF I don't know, but this stuff is decades old, back to at least IE4 and sometime associated with utterly dead "channels" functionality, probably no one left at MS who knows what it is or was supposed to do, daren't change it because very likely stuff depends on it and will break...
What isn't clear in TFA is the lack of user interaction - in the past the icon link has been retrieved with the credentials of the user who is browsing the folder, here there is no user and yet the hack "collects the target's NTLM password hash", which target? The hash for which user? Makes no sense.
Nor is it clear what the requirement for sharing "without a password" means - most windows shared folders that are accessed "without a password" are actually NTLM-authenticated behind the scenes. I can only think it means write access for "EVERYONE" - or world-writable. Not sure why _that_ should make a difference to whether an NTLM hash is sent out either. Weird. Still, the big WTF is the world-writable folder - see tl;dr above.
(Score: 5, Informative) by Hyperturtle on Wednesday November 08 2017, @02:58PM (1 child)
They mean anyone on the local network with access to it can trigger the .scf vulnerability. Putting it on the internet is surely a problem but you aren't understanding the real issue. Windows shares the NTLM hash values to servers not in the same administrative domain -- such as via web page security between sites on servers that may be in a DMZ but not on the domain, or the internet. The vulnerability is not on the internet, it's local -- and a server on the internet can collect the hash for whatever nefarious purposes. This is by design because intranet. If you remember the security zones in IE -- that is relevant to the NTLM hash sharing, but clearly can be exploited via other methods.
Blocking such ports for SMB or ftp or whatever you choose to access the volume, like via an access-list or on a firewall interface...is something everyone in the world already does pretty much, and it can be via software, like by default in windows xp sp2. The issue is not as you describe, this isn't a firewall fail because someone opened the server to the internet.
They are using specific terms, it sounds like you did not understand them so here is what they mean: "global" because users that are not on the specific domain can be impacted. Like member servers in your DMZ, or another server open in a web browser that the exploit is connecting to and is about to send data to via some http command or javascript whatever.
It is "public" because it affects shares that are not password protected or otherwise secured; like anonymous read only file shares. It is by definition not private even if its on a local network and not on the internet. Which means that novell's IPX/SPX protocol probably will probably just as happily trigger .scf file reading on older versions of Windows.
The problem here is that it's a WINDOWS problem by design, to deliberately read those .SCF files -- something any good admin that got experience learning how to overcome their corporate network policy enforcement probably already knows. It's for administration and designed from a day when windows was new and things were becoming automated and security issues like this were few and far between. And then .scf files started to fall into disuse over the next generations of windows hosts and servers (alternatives such as active directory came about, for example...)
Here is how it will affect people:
They get an email and click the link or open the document that then sends them to a bad website to run javascript or whatever and scans local open shares
when one is found with write capability and meets the criteria, an .SCF file is placed, hopefully not one that overwrites something already there which would draw attention to itself
It's possible that the nefariousness of the attack could just append to an existing one if a dumb admin's account was used to trigger the attack, or if weak local security was used and some system account was compromised that had better-than-user-rights.
.SCF runs/is read on people's machines when the volume is accessed. This might even mean clicking network neighborhood and browsing the LAN, I am not sure. But the takeaway is that if you put it where everyone goes, like the sysvol folder, and poof.
That SCF can allow for the collection of a good deal of information that could allow for another prong in the attack phase. NTLM hashes tend to work well on the network it was grabbed from. Tools exist to crack them, too...
The user interaction here is just visiting a site and possessing write access to shares with high traffic volumes/user visitation.
If you have that and access to internet sites, chances are it will run surrepitiously until noticed, collecting the NTLM hashes of each machine it has "infected" for distribution either then or later. It could upload to a website from everyone affected or just collect it on the original infection host and upload from there to draw less attention to itself. who knows. I am sure there will be some creative efforts that do it better than how I have speculated.
The hashes tied to the username can be used to get admin account passwords or other heightened security accounts, perhaps even remote access if your company is dumb enough to have remote vpn access on vpn.mycompany.com and use windows authentication and no fob or other password requirements. Ding, come right in. Remote admin access over a VPN is great, I assure you, and if you get the hash and have looked at the company on linked in, you can figure out who in IT would be a good choice to try that out on based on the user names and passwords you have. or rdp, lots of places open 3389 to specific servers, too...
(and for my friends that think I write too much, tl;dr upgrade your servers I guess cause MS isn't fixing the problem since it's not a problem, it's a feature in the older OSes, both client and server.)
(Score: 2) by choose another one on Thursday November 09 2017, @07:28AM
Only if there is write access granted to anonymous users (hence unknown, untracked, unaudited) _and_ there are untrusted/malicious users already on the local network.
I would suggest that if those two statements are true, you already have big problems even absent this vulnerability. For a start, malicious actors with write access can already add straightforward executable malware to your network and phish for users to open it which will generate no warnings/alarms/suspicions because the file is local.
I think I know what "anonymous read only file shares" means, and this vulnerability will definitely not affect them.
And how pray is the .SCF file placed by the "bad website" onto a server which is "on a local network and not on the internet"? If a web page can use a browser to write to local-machine or local-network shares then you are already hosed, and the problem is the browser sandbox.
Well, having found a walkthrough of exploit ( http://www.sysadminjd.com/adv170014-ntlm-sso-exploitation-guide/ [sysadminjd.com] ) the user action would appear to be creating an anonymous-writable share (possibly, although not clear it is a requirement, below/within users desktop folder). The rest of the action is by the attacker.
The user whos hash is exposed is the owner of the share (or possibly the owner of the created file - which would make sense, since for an authenticated share that would by default be the attacker who then only gets to crack his own password, which is why it would require an anon-writeable share). I think it would also mean that if you really have to have a world-writeable share you can set it up properly with created files owned by a user that can do nothing other than create files in that share (which is the way I'm pretty sure it used to be done on Samba), and you'd probably be safe from this vulnerability?