Collecting Users Credentials from Locked Devices

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

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):