Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: Collecting Users Credentials from Locked Devices - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Collecting Users Credentials from Locked Devices

It’s a fact: When a device can be physically accessed, you may consider it as compromised. And if the device is properly hardened, it's just a matter of time. The best hacks are the ones which use a feature or the way the computer is supposed to work. To illustrate this, let's review an interesting blog post published yesterday[1]. It demonstrates how easy it is to steal credentials from a locked computer. If the attack is not new, the method used is really awesome. You probably know that computers tend to generate a lot of network request that may content sensitive information. As an example, if you specify an URL like  "file://1.2.3.4/doc.txt" in a web page, Internet Explorer will try to access the file via SMB and will disclose the current user credentials. In the new attack, no need to play with cables to sniff traffic, no MitM or altered web pages. Access to the USB port of a locked computer (read: a user being logged in but away for a coffee break) is enough.

To perform the attack, a low-cost device is required like the USB Armory [2] or the Hak5 Turtle[3], both can be connected to a host computer via USB and provide TCP/IP service via an Ethernet over USB protocol. When you connect such device into the USB port, a driver is loaded by the operating system (which does not require any user intervention), a new interface is set up and classic TCP/IP communications occur. What happens in this case? The host computer will consider this interface as the new default one for a few second and tries to configure it by requesting an IP address via DHCP.

The USB Armory is configured to provide DHCP services but with a specific option (number 252) to provide the proxy auto configuration script also called “WPAD” (“Web Proxy Autodiscovery Protocol”):

option local-proxy-config code 252 = text;

subnet 192.168.10.0 net mask 255.255.255.0 {
    ...
   option local-proxy-config “http://192.168.10.1/wpad.dat”;
}

The key point is that WPAD provided by DHCP has a higher priority than the one provided by DNS. The tool that will handle the requests and capture data is Responder[5]. A nice demonstration is available on Youtube[6]. Evil!

The next question is "how to protect against this kind of attack?". It's not easy because countermeasures may affect the computer operations or restrict users' operations. The first idea is to disable the proxy automatic settings (that can be also enforced via a GPO) but it does not prevent the host computer to make an HTTP request to the URL provided by DHCP. I tested on a Windows 10 system, disabled all the automatic configurations, rebooted and saw this on my web server:

192.168.254.222 - - [09/Sep/2016:08:26:53 +0200] "GET /wpad.dat HTTP/1.1" 200 591 "-" "WinHttp-Autoproxy-Service/5.1"

How to mitigate this attack?

Completely disabling USB port is not an option but restricting the use of some USB devices (usually HID of "Human Interface Devices") can be implemented by a GPO or a specific software.

If you don't use automatic proxy discovery, monitor your DNS logs for requests like "wpad.domain.com". The WPAD configuration over DHCP has a higher priority then DNS. However as explained by Microsoft[7]: "

"Now, if DHCP is configured to provide the WPAD location, IE stops the detection and will make a GET request for the wpad.dat file and no further searching is done. This is true even if the DHCP 252 option is incorrect and a correct entry is configured as a DNS record. Please also be aware that IE still sends out the DNS query in this situation, even the DNS result won’t be adopted."

Again, I saw this while booting my Windows 10. It tried to find valid WPAD URLs:

09-Sep-2016 08:26:54.672 queries: info: client 192.168.254.222#57683: query: wpad.xxxxx IN AAAA + (192.168.254.8)
09-Sep-2016 08:26:54.672 queries: info: client 192.168.254.222#61760: query: wpad.xxxxx IN A + (192.168.254.8)

If you don't use the DHCP option 252 in your network, a good idea is to track such feature via your IDS. Here is a Snort / Suricata rule:

alert udp any 67 -> any 68 (msg:"ET INFO Web Proxy Auto Discovery Protocol WPAD DHCP 252 option Possible BadTunnel"; content:"|02|"; depth:1; content:"|fc|"; byte_jump:1,0,relative,post_offset -9; content:"/wpad.dat"; within:9; fast_pattern; classtype:protocol-command-decode; sid:2022915; rev:1;)

(Note that this rule won't protect you against the attack described here because the DHCP traffic remains "local" but it can help you to detect a classic MitM attack)

Finally, you can track the use of devices like the USB Armory by monitoring the following registry key: HKLM\SYSTEM\CurrentControlSet\Enum\USB. Here is a screenshot (idVendor=0525 is the USB Armory):

This can be implemented with a host based IDS like OSSEC[8].

As you can see, this attack is not easy to mitigate. If you have tips to protect against such USB attack, feel free to share!

[1] https://room362.com/post/2016/snagging-creds-from-locked-machines/
[2] https://inversepath.com/usbarmory
[3] http://hakshop.myshopify.com/collections/lan-turtle/products/lan-turtle
[4] https://en.wikipedia.org/wiki/Ethernet_over_USB
[5] https://github.com/Spiderlabs/Responder
[6] https://www.youtube.com/watch?v=Oplubg5q7ao
[7] https://blogs.msdn.microsoft.com/asiatech/2012/08/14/insight-wpad-proxy-settings-on-ie/
[8] https://blog.rootshell.be/2010/03/15/detecting-usb-storage-usage-with-ossec/

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

Xme

275 Posts
ISC Handler
I got the following feedback to mitigate the problem of credentials being sent in the wild:

A fix is to force a prompt when NTLM authentication is requested:

Internet options -> Security -> Custom level for all zones:
User authentication -> Logon -> Prompt for user name and password

Warning, this could break many stuff in corporate environments!
Xme

275 Posts Posts
ISC Handler
We are looking locking USB storage device access to a model/make/serial number.
SteveR

1 Posts Posts
So the device sets itself up as your default proxy, how does that allow it to steal passwords? Why would the device send out your password over the network while in the lock screen?
Barmar

8 Posts Posts
The USB Armory runs the DHCP server which instructs the victim to perform an HTTP GET request to get the WPAD file. This is handled by the Responder tool.
By design, Windows will send the credentials of the logged user with the HTTP GET resquest...
Xme

275 Posts Posts
ISC Handler
Quoting Xme:Internet options -> Security -> Custom level for all zones:
User authentication -> Logon -> Prompt for user name and password

This mitigation works only for authentication over HTTP/HTTPS via WinINET, i.e. Internet Explorer, it does NOT work for authentication over SMB/CIFS!
Anonymous

Posts
Quote:The key point is that WPAD provided by DHCP has a higher priority than the one provided by DNS.


On Windows, you can swap this via
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"AutoProxyDetectType"=dword:00000002
Anonymous

Posts
Quoting Xme:By design, Windows will send the credentials of the logged user with the HTTP GET resquest...


WRONG!
Windows does NEITHER initiate a HTTP connection when an ethernet device is attached, NOR does it send the credentials.
Internet Explorer (as well as other browsers too) will send credentials. IE is but not started when an ethernet device is attached or a new route added.
Anonymous

Posts
Quoting SteveR:We are looking locking USB storage device access to a model/make/serial number.

This device is NO storage device!
Anonymous

Posts
For mitigation in WinHTTP see MS16-077 and/or the MSKB articles 3161949 and 3165191:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHTTP]
"AllowOnlyDNSQueryForWPAD"=dword:00000001
"AutoProxyAutoLogonIfChallenged"=dword:00000000
Anonymous

Posts
Quoting Anonymous:
Quoting Xme:By design, Windows will send the credentials of the logged user with the HTTP GET resquest...


WRONG!
Windows does NEITHER initiate a HTTP connection when an ethernet device is attached, NOR does it send the credentials.
Internet Explorer (as well as other browsers too) will send credentials. IE is but not started when an ethernet device is attached or a new route added.


I believe the implication here is that on a logged in but locked machine, there are likely tasks (open browser windows, Windows Update, desktop gadgets, etc.) that connect to the Internet and are proxy aware. As such, the connection to the spoofed proxy (Responder) will include the credentials of the currently logged in user. I don't think Windows will send plain-text credentials by default but rather the hash which would need to be cracked to become truly useful. I could be wrong on that last point though.
Ron

5 Posts Posts
I will make more tests but when I rebooted my test Win10 laptop yesterday, it got the WPAD URL via DHCP option 252 and immediately after performed a GET request against the website hosting the file! (without any user logged in).

The user agent is 'WinHttp-Autoproxy-Service/5.1'. It belongs to a service that is running by default called 'WinHTTP Web Proxy Auto-Discovery Service'.
Xme

275 Posts Posts
ISC Handler
Quoting Ron:... there are likely tasks (open browser windows, Windows Update, desktop gadgets, etc.) that connect to the Internet and are proxy aware.


Except for Windows Update, which does NOT run under the logged on user's account, browsers, gadgets etc. are application programs.
These run on Windows, but should be seen separate from the operating system "Windows".
Some/many of these application programs use WinINet, which will send credentials if not configured otherwise.

Services like Windows Update use WinHTTP and run under LocalSystem, LocalService or NetworkService accounts: these user accounts will either send anonymous or the machine's account credentials, unless WinHTTP is configured not to authenticate.

https://msdn.microsoft.com/en-us/library/ms684190.aspx

| The LocalSystem account [...] acts as the computer on the network.

https://msdn.microsoft.com/en-us/library/ms684188.aspx

| The LocalService account [...] presents anonymous credentials on the network.

https://msdn.microsoft.com/en-us/library/ms684272.aspx

| The NetworkService account [...] acts as the computer on the network.
Anonymous

Posts
Quoting Xme:I will make more tests but when I rebooted my test Win10 laptop yesterday, it got the WPAD URL via DHCP option 252 and immediately after performed a GET request against the website hosting the file! (without any user logged in).


Which credentials do you expect to be send without a logged on user?

Quoting Xme:The user agent is 'WinHttp-Autoproxy-Service/5.1'. It belongs to a service that is running by default called 'WinHTTP Web Proxy Auto-Discovery Service'.


Services run under system accounts.
These authenticate either as anonymous or (unless WinHTTP is configured otherwise) with the machine's account, but NOT with the logged on user's account.

Q.E.D.
Anonymous

Posts
There needs to be a way to set limits on what USB devices can be added to a locked or non-logged in system.
Anonymous

Posts
Quoting Anonymous:There needs to be a way to set limits on what USB devices can be added to a locked or non-logged in system.


Why don't you inform yourself before you post?
Vista introduced the following settings about 10 years ago!

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions]
"AllowAdminInstall"=dword:00000001
"AllowDeviceClasses"=dword:00000000
"AllowDeviceIds"=dword:00000000
"DenyDeviceClasses"=dword:00000001
"DenyDeviceClassesRetroActive"=dword:00000000
"DenyDeviceIDs"=dword:00000001
"DenyDeviceIDsRetroActive"=dword:00000000
"DenyRemovableDevices"=dword:00000001
"DenyUnspecified"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\AllowDeviceClasses]
"0"="{........-....-....-....-............}"
"1"="{........-....-....-....-............}"
...

See https://msdn.microsoft.com/en-us/library/ff553426.aspx for the GUIDs of the device classes.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\AllowDeviceIDs]
"0"="USB\\VID=vvvv&PID_pppp"
...

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceClasses]
"0"="{........-....-....-....-............}"
"1"="{........-....-....-....-............}"
...

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceIDs]
"0"="USB\\VID=vvvv&PID_pppp"
...

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DeniedPolicy]
"DetailText"="<popup message>"
"SimpleText"="<popup title>"
Anonymous

Posts

Sign Up for Free or Log In to start participating in the conversation!