Products + All Products + Software Integrity + Semiconductor IP + Verification + Design + Silicon Engineering
Posted by Nikos Vassakis on November 10, 2016
Stealing credentials from locked machines shouldn’t work. And yet, it does. The main reason for this is that the operating system automatically loads device drivers if it has access to them. This is true even when a machine is locked. In the case of locked machines, USB Ethernet adapter drivers ship with every major operating system (e.g., Windows, MacOSX, Linux).
Leveraging this fact, it’s possible to create a network using Android tethering. When tethering, the mobile device receives all of the host’s traffic and acts as a network gateway. Once implemented, it is trivial to conduct any number of man-in-the-middle (MitM) attacks. In this post, I’ll explain the steps, tools, and configuration needed to conduct a successful attack on a locked device.
When an Android device enters tethering mode, it adds an additional USB descriptor to the USB interface and restarts it.
When the operating system queries the Android device—connected via USB port—it receives the USB network device descriptor (among others). It then loads the driver.
Once the driver loads, the host operating system creates a new network interface (via USB). The host treats the new network interface as any other. Since the USB link is active, the host requests an IP by sending a Dynamic Host Configuration Protocol (DHCP) request.
In the native Android tethering configuration, use dnsmasq to set up a DHCP and DNS server that responds to the request. This provides the host with the IP and routing details necessary to connect to the network.
In Android’s tethering implementation, these configuration details are hardcoded in the “Tethering.java” package. However, in a rooted Android device, manual configuration is possible.
Apart from these elements, iptables forwarding rules can be set up to forward traffic from the USB to the external interface (typically Wi-Fi or 3G). Once this is done, the host can use the USB network to connect to the Internet (i.e., tethering).
Carrying out a MitM attack in which the attacker poisons the network with rogue packets to force network devices to connect through the attacker’s network isn’t necessary with tethering. When tethering, all host traffic passes through the device as explained above. Even if the device connects to another network, some network traffic eventually goes through the USB network. This is proven to be enough to leak some authentication credentials as we’ll expand on below.
In this example, the MitM tool of choice is Responder. A passive credentials gathering tool, Responder listens for specific NetBIOS Name Service (NBT-NS) and Link-local Multicast Name Resolution (LLMNR) queries. It also poisons the issuer. This tool involves rogue authentication servers listening via UDP and TCP ports. Additionally, the victim is redirected to these services in an attempt to capture their authentication credentials.
Using Responder to MitM traffic and capture credentials is extremely effective. This is especially true when the user is active in the network (e.g., browsing the Internet, accessing internal shares, etc.).
This attack vector assumes that the user isn’t present or active on the network. However, the user must have previously authenticated to the host for this to work. It also assumes physical access to the host and USB ports.
The Web Proxy Auto-Discovery (WPAD) protocol is a method that operating system’s utilize to locate a proxy auto-config (PAC) file automatically. The location of the PAC can be presented to the user in the DHCP response “site-local” option 252 (i.e., auto-proxy-config) with a “http://example.com/wpad.dat” value.
DHCP has a higher priority than DNS. If DHCP provides the WPAD URL, no DNS lookup is performed. This only works with DHCPv4. In DHCPv6, there is no defined WPAD option.
All Web browsers support this protocol: Windows, MacOSX, and Linux, as well as iOS and Android. However, it is only enabled by default in Windows operating systems.
With regard to tethering and DHCP, we’ve seen that it’s possible to create a network and set up a DHCP server using an Android device. It’s also trivial to set up a DHCP server using Android’s dnsmasq and configure the WPAD option to point to Responder.
Regarding authentication, the attack works on locked computers because of the proxy automatic configuration file details that pass with the DHCP response.
When the host tries to retrieve the PAC file, Responder’s HTTP server responds with a “(407) authentication required” message. In many cases the host authenticates via the user’s cached credentials.
Windows uses the NTLM protocol, a challenge-response authentication protocol, for this authentication. A hash derived from the user’s password and the challenge-response steps act as the user’s authentication token.
Although, these aren’t plaintext credentials that an attacker can use directly, with modern hardware it’s possible to crack the hash and reveal the user’s password in a realistic time-frame. The time for this is significantly lower if the password used is weak.
This will not work in a freshly-booted host since cached credentials aren’t available. However, once the user authenticates, the host can try to get the file again.
One of the key challenges is running Responder (a Python project) in Android. There are a number of potential solutions to consider. The easiest and most effective is to install the qPython application. qPython is a Python interpreter compiled for Android. It’s able to run Responder without any issues.
An alternate solution is to install NetHunter. NetHunter is a Kali Linux installation ported to Android. It also contains a Python interpreter.
This video displays a Windows 10 lock screen. The test host has a fresh Windows installation and it doesn’t join to any domain. It also isn’t connected to any other network. The user previously authenticated and locked the screen. Additionally, the Android device connected to it is running the aforementioned Responder scripts.
Notice that seconds after executing Responder, the user’s NTLM hash is captured without any user interaction.
The images below better illustrate what is captured:
Image 1: The script’s execution steps. These enable tethering by setting up the network and running Responder.
Image 2: The captured hash (in yellow) and other poisoned responses.
A potential control, at least against locked computer attacks, is to disable the automatic proxy configuration setting in the operating system and browsers.
Note that this could also create issues in corporate networks that use proxies and rely on automatic configuration to provision employee workstations. Nevertheless, when using proxies, it’s recommended for the settings to be hardcoded or provided by automatic configuration scripts.
Below you’ll find operating system-specific directions: