My next class:

Collecting Users Credentials from Locked Devices

Published: 2016-09-09. Last Updated: 2016-09-09 07:16:17 UTC
by Xavier Mertens (Version: 1)
15 comment(s)

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

15 comment(s)
My next class:

Comments

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!
We are looking locking USB storage device access to a model/make/serial number.
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?
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...
[quote=comment#37731]Internet options -> Security -> Custom level for all zones:
User authentication -> Logon -> Prompt for user name and password
[/quote]
This mitigation works only for authentication over HTTP/HTTPS via WinINET, i.e. Internet Explorer, it does NOT work for authentication over SMB/CIFS!
[quote]The key point is that WPAD provided by DHCP has a higher priority than the one provided by DNS.[/quote]

On Windows, you can swap this via
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"AutoProxyDetectType"=dword:00000002
[quote=comment#37737]By design, Windows will send the credentials of the logged user with the HTTP GET resquest...[/quote]

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.
[quote=comment#37733]We are looking locking USB storage device access to a model/make/serial number.[/quote]
This device is NO storage device!
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
[quote=comment#37743][quote=comment#37737]By design, Windows will send the credentials of the logged user with the HTTP GET resquest...[/quote]

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.[/quote]

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.

Diary Archives