How to create a wireless pen testing lab

In my previous rant I was telling how notoriously difficult is to get the right hardware. If you get an AP for this reason, chances are it won’t work as expected. Finding information about various models is next to impossible.

My solution is: get a bunch of USB adapters, then use virtual machines. You need a hypervisor with proper USB passthrough support though. Unfortunately, VirtualBox won’t cut it.

Hypervisor recommendations: VMware Player (Windows, Linux), KVM (Linux, untested for this particular setup), VMware Fusion (OS X), Parallels Desktop (OS X, untested for this particular setup). Unfortunately, for OS X there’s no free/freeware product with proper USB passthrough support. Bear in mind that virt-manager makes things easier for KVM under Linux. This brings KVM close to the usual desktop solutions.

I use three virtual machines with three USB adapters, but at minimum you need two VM’s and two adapters if you don’t need remote connectivity to your lab. The wireless client may be any device if you’re near the machine (phone, tablet, etc). The adapters that you need to use for monitor mode and wireless client may need to have removable antennas.

The AP VM

I found out that an adapter with AR9271 proved to be the best choice for the AP VM. That is, from my collection of USB adapters. For example, I use a TP-LINK TL-WN722N. It is inexpensive and easily available. I mounted the antenna on the AP adapter.

For the VM itself, I use Ubuntu 14.04 with hostapd and dnsmasq. I removed the network-manager package and configured the wired interface by editing the /etc/network/interfaces file.

I placed the hostapd configuration in /etc/hostapd/hostapd.conf:

interface=wlan0
driver=nl80211
ssid=wifu
hw_mode=g
channel=3
macaddr_acl=0
ignore_broadcast_ssid=0

# WEP config
# 1 = open
# 2 = psk
# 3 = both
auth_algs=1
wep_default_key=0
wep_key0=AABBCCDDEE

# WPA config
# 1 = WPA
# 2 = WPA2
# 3 = both
#wpa=2
# TKIP = WPA
# CCMP = WPA2
# TKIP CCMP = both
#wpa_pairwise=CCMP
#wpa_passphrase=password

This configuration is for WEP with open authentication. The comments help you to use this as a template for configuring WEP with PSK, WPA, or WPA2. If you comment the WEP config and uncomment the WPA config, it will default to WPA2.

The dnsmasq config was placed in /etc/dnsmasq.conf:

# disables dnsmasq reading any other files like /etc/resolv.conf
no-resolv
# Interface to bind to
interface=wlan0
# Specify starting_range,end_range,lease_time
dhcp-range=10.0.0.3,10.0.0.27,12h
# dns addresses to send to the clients
server=8.8.8.8
server=8.8.4.4

For starting the AP, I use this script:

#!/bin/bash
#Initial wifi interface configuration
ifconfig $1 up 10.0.0.1 netmask 255.255.255.0
sleep 2
 
###########Start dnsmasq, modify if required##########
if [ -z "$(ps -e | grep dnsmasq)" ]
then
 dnsmasq
fi
###########
 
#Enable NAT
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables --table nat --append POSTROUTING --out-interface $2 -j MASQUERADE
iptables --append FORWARD --in-interface $1 -j ACCEPT
 
sysctl -w net.ipv4.ip_forward=1
 
#start hostapd
hostapd /etc/hostapd/hostapd.conf
killall dnsmasq

I placed it into a $PATH directory. Invoke it with:

sudo initSoftAp wlan0 eth0

The script runs in foreground. It can be easily killed with Ctrl+C. You may easily observe the hostapd log messages for debugging reasons. The subnet for this lab AP is different than the subnet used by the eth0 interface of the VM. It’s irrelevant if the VM itself uses NAT or bridge for its “wired” interface.

The monitor mode VM

I use an ALFA AWUS036H simply because I have it. It uses the RTL8187L chipset which is old, but well supported. You may pick any adapter that properly supports packet injection. I started a project to document this. I call it aircrack-db as I use the aircrack-ng suite for testing the wireless interfaces capabilities.

I took down the antenna of this adapter because of the receiver saturation. It is too close to the AP and using long USB cables isn’t feasible in my case. Taking the antenna down and placing the cards apart at about half a metre provides the best results. The aircrack-ng FAQ explains this: Why do I have bad speeds when i’m too close to the access point? If you keep the antenna, you may see good quality signal (PWR -19 or so), but the RXQ shows that something is wrong. Most of the time, this setup is going to be useless, therefore only the AP or the attacking card needs to have the antenna, or place them far away from each other.

For the VM itself I use Kali 1.0.9a (aka the latest, up to date, version). You may also remove network-manager from this machine and configure eth0 via /etc/network/interfaces. The network-manager usually is troublesome together with the aircrack-ng suite. In my case, “airmon-ng check” returns nothing.

The STA VM

This is optional if you don’t need remote connectivity to the wireless pen testing lab. If you do, this is my setup.

I use an ALFA AWUS051NH simply because I have it. I also use a Netis WF2190 from time to time. This adapter doesn’t need to support monitor mode. It just needs to act as a wireless client in order to test various scenarios where an associated STA to the AP is required, or if you target an unassociated client with airbase-ng.

I use Ubuntu 14.04 and that’s pretty much it. It doesn’t need any modifications as the network-manager is actually useful in this case. Sometimes, the AP disappears after repeated deauth attacks. If this happens, you need to uncheck “Enable WiFi” from the network manager menu, and then enable back the WiFi.

If the AP adapter has its antenna, then take down the antenna of the wireless client adapter. The receiver saturation in this case means really erratic behaviour such as connections timeouts to the AP or really slow association.

Reproducing KoreK’s ChopChop attack is a pain in the ass

Well, getting a Netgear WNR1000v2, one of the recommended access points by WiFu, was also a pain in the ass since the product is EOL. Imagine my surprise when I couldn’t reproduce this particular attack as the AP was not dropping properly the packets with invalid ICV.

I started to dig for some information. The product that I got was so old that basically was one of those unsold units. It came with the only firmware still available on Netgear’s support site that features WEP support. Actually, the only one who mentions this product in relation to WiFu is Samiux. WNR1000v2h2 is basically a WNR1000v2, but with internal antenna.

The things that I tried, but utterly failed

I tried the Netgear WNR1000v2 AP with firmware versions 1.0.1.1 (the version that was installed on it), 1.0.1.1NA (basically the same as previous, but region locked to USA, so it would stick to FCC’s emission regulations), and 1.1.2.28 (does not feature WEP support).

I dug up my retired ASUS WL-500g Premium. Tried the attack with the following firmwares: OpenWrt 12.09 (built the attitude_adjustment branch myself few months ago due to unstable b43 driver at the time of the 12.09 release), OpenWrt 10.03 brcm-2.4 (Linux 2.4.40, Broadcom STA / wl driver), and the first available factory firmware on ASUS’ support site, v1.9.6.9. Neither of them worked. OpenWrt 12.09 and the factory firmware created the illusion that it works, only to fail few seconds later.

I also tried to create a basic soft AP using hostapd. In reality, not all the drivers and hardware are the same. While it theoretically supports the nl80211 library in order to talk to devices that use mac80211 drivers, only some of the chips that support master mode can actual create a working AP.

My first try was a proof of concept on a piece of Raspberry Pi, but it didn’t work as I was using my portable stuff instead of the toys that stay at home in my proper Wi-Fi lab. I tried to create an AP using Unex DNUA-93F, powered by AR9271, but I had nothing to test it with. While Kali works on VirtualBox / OS X, the USB support is spotty at best and this card is the only one that can be used with a certain degree of reliability. So I had to switch to an ALFA AWUS051NH, powered by RT2770. I could get reliable packet injection starting from a fragmentation attack, but no dice with ChopChop.

In my home lab I tried to create a proper soft AP on a machine which runs Kali, but as previously mentioned, not all the hardware is the same. I tried to create an AP with the legendary ALFA AWUS036H, powered by RTL8187. For some reason, hostapd won’t start with this card if WEP is in use. Running hostapd with -dd added more confusion, hence I switched to the built in wireless interface, an AirForce One 54g, powered by BCM4318. The AP was created successfully, but every connected client wouldn’t finish the authentication and the log was flooded with “wlan0: STA […] did not acknowledge authentication response”. Which was odd as WL-500gP has the same Mini PCI card in it.

What finally worked

I created a soft AP using a TP-LINK TL-WN722N, powered by AR9271 (same as Unex DNUA-93F). For the internet connectivity I used the built in AirForce One 54g to connect to my actual AP.

For the configuration I used the information posted by nims11’s article about how to create a soft AP, but I used dnsmasq as DHCP server because dhcpd was being a pain in the ass (you can see a pattern here).

The hostapd config in /etc/hostapd/hostapd.conf:

interface=wlan2
driver=nl80211
ssid=wifu
hw_mode=g
channel=3
macaddr_acl=0
ignore_broadcast_ssid=0
auth_algs=1
wep_default_key=0
wep_key0=AABBCCDDEE

The dnsmasq config in /etc/dnsmasq.conf:

# disables dnsmasq reading any other files like /etc/resolv.conf
no-resolv
# Interface to bind to
interface=wlan2
# Specify starting_range,end_range,lease_time
dhcp-range=10.0.0.3,10.0.0.20,12h
# dns addresses to send to the clients
server=8.8.8.8
server=8.8.4.4

The initSoftAP for starting up the stuff:

#!/bin/bash
#Initial wifi interface configuration
ifconfig $1 up 10.0.0.1 netmask 255.255.255.0
sleep 2
 
###########Start dnsmasq, modify if required##########
if [ -z "$(ps -e | grep dnsmasq)" ]
then
 dnsmasq
fi
###########
 
#Enable NAT
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables --table nat --append POSTROUTING --out-interface $2 -j MASQUERADE
iptables --append FORWARD --in-interface $1 -j ACCEPT
 
sysctl -w net.ipv4.ip_forward=1
 
#start hostapd
hostapd /etc/hostapd/hostapd.conf
killall dnsmasq

Started it with ./initSoftAp wlan2 wlan0 (under root, obviously). I did the double-NAT over Wi-Fi because I was too lazy to add another patch cable over the already crowded desktop. Otherwise, it would be ./initSoftAp wlan2 eth0.

I booted up my desktop machine, started Kali in a VirtualBox VM, and made the ALFA AWUS036H to be available inside the VM. Did the usual drill (airmon-ng, airodump-ng, etc). I had to keep the antennas about 1.5 meters apart due to their radiation pattern.

I used my phone as testing client. I could browse the ‘net and I got the 10.0.0.3 IP via DHCP, as instructed by dnsmasq. The ChopChop attack was running in unauthenticated mode, but the packets fetched from the phone as client were not usable. In fact, I don’t recall getting usable packets in unauthenticated mode.

I fired up another instance of aireplay-ng running fake auth and retried the ChopChop attack in authenticated mode. The first captured packet was a winner. Bam! I got the plaintext capture and the PRGA / xor file. Few minutes later, after creating an ARP packet with packetforge-ng and injecting it via interactive packet injection, I managed to crack the WEP key, therefore successfully completing the ChopChop challenge.

The end

It took me two long days, but I did learn a lot. I think the WiFu lab can be reduced to my desktop machine, running a couple of VirtualBox VMs (one for Kali, one for a soft AP), two Wi-Fi USB adapters, and a wireless client to play the victim role. This can be either a phone, a tablet, a notebook (this may be the host machine for VirtualBox and the victim), or another VM plus another USB adapter. I think hunting for old hardware for this course is a flawed idea. Sure, ALFA AWUS036H may be used after finishing this course, but the AP is going to be virtually useless.

WiFi adapters card-to-card packet injection test

Update: I made something which I call aircrack-db. It contains the actual results of my hardware testing for the Wi-Fi attacks and it is kept up to date. Consider this article to be obsolete.

As I started working on the Offensive Security Wireless Attacks (WiFu) course, I needed to know which of the wireless interfaces that I own is capable of doing the job. Turns out that the information is hard to find, even coming from fellow pentesters.

I’ve to admit, my wireless attacking skills were next to null before starting this course. I had to read a lot of stuff before getting some hardware. I had the surprise to see that the most capable wireless interface, so far, is the one that came with my really-really-really-really old notebook which I use as lab environment.

I bought an Unex DNUA-93F because it has the same chipset as ALFA AWUS036NHA (*), but unfortunately it doesn’t support (yet?) the fragmentation attacks. Anyway, the card is really discreet and it may be a good choice for some inconspicuous testing. I also have an ALFA AWUS051NH (**) mostly because it supports both 2.4 GHz and 5 GHz. I don’t really care about 802.11a, but 802.11n works on both frequency bands.

Here are the results for the card-to-card packet injection test:

ASUS A6M built in (miniPCI): Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)

Driver: b43

Attack -0: OK
Attack -1 (open): OK
Attack -1 (psk): OK
Attack -2/-3/-4/-6: OK
Attack -5/-7: OK

Unex DNUA-93F: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n

Driver: ath9k_htc

Attack -0: OK
Attack -1 (open): OK
Attack -1 (psk): OK
Attack -2/-3/-4/-6: OK
Attack -5/-7: Failed

ALFA AWUS051NH ID 148f:2770 Ralink Technology, Corp. RT2770 Wireless Adapter

Driver: rt2800usb

Attack -0: OK
Attack -1 (open): OK
Attack -1 (psk): OK
Attack -2/-3/-4/-6: OK
Attack -5/-7: Failed

I borrowed some interfaces just to extend the test.

Canyon CNP-WF518N1 ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter

Driver: rt2800usb

Attack -0: OK
Attack -1 (open): OK
Attack -1 (psk): OK
Attack -2/-3/-4/-6: OK
Attack -5/-7: Failed

ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

Driver: rtl8192cu

Attack -0: OK
Attack -1 (open): OK
Attack -1 (psk): OK
Attack -2/-3/-4/-6: Failed
Attack -5/-7: Failed

Don’t know the manufacturer of this Realtek card. It was sold naked (just the board with a soldered USB interface) for the reason that it worked OOTB with Raspbian. To state the obvious, RTL8188CUS is basically useless beyond deauth and fake auth.

The -1 to -9 are, of course, the aireplay-ng attack flags. My cards were tested with both the drivers that came with the latest Kali 1.0.8 / Linux 3.14.5-1 and with the compat-wireless compat-drivers backports package (guys, pick a name that sticks) 3.16.2-1. The borrowed cards were tested only with the backports drivers. I also used the mac80211.compat patch for the backport package provided by aircrack-ng with Mathy Vanhoef’s compatdrivers_chan_qos_frag patch, with some fixes from Devil_D. This patch can be merged with “patch -p1 -F3” as it fails to match the offsets.

I didn’t get the fixed channel issue with aireplay-ng until I started to do more stuff with it, with or without updated drivers. Even though I applied various patches, I found out that the issue is triggered by Gnome’s Network Manager if the service is restarted. It reconnects ALL of the installed wireless interfaces if it has a device profile for that particular interface. If it’s started again while a VAP is monitor mode is running, I get a fixed channel issue. Sometimes it sticks to -1, sometimes it sticks to 7. The channel of the interface can’t be changed after that.

iw and iwconfig silently fail to change the channel. A reboot solves the issue. Presumably, removing the modules with rmmod and loading them back in also fixes the channel issue. Adding the –ignore-negative-one flag to aireplay-ng doesn’t do anything useful and the attacks still fail. I am running the latest aircrack-ng suite, so the “it was patched against this” doesn’t apply here. I think the lesson here is: don’t start network-manager if a VAP created by airmon-ng is running. airmon-zc doesn’t solve the problem, as opposed to which is stated on aircrack’s issue tracker.

The conclusion is: I am waiting for an ALFA AWUS036H.

Update: the fixed channel issue appears when the network-manager daemon is restarted. This happens with or without the presence of the monitoring VAP. However, my hunch was correct. Unloading the driver with rmmod and loading it back with modprobe solves the fixed channel issue and the attacks may resume.

__________
(*) AWUS036NHA – something that people had “no issues with it”, while Unex DNUA-93F is an adapter which is endorsed by FSF as it needs “completely free software for operating”
(**) also, something that people had “no issues with it”, but I guess they didn’t try the fragmentation attacks with it

Using persistent OpenSSH connections

I found out that using persistent connections greatly improves the productivity when working with SSH. However, finding the appropriate configuration turned out to be a complicated task. I wanted it to be as unobtrusive as possible, to restart the connection when the socket is closed, and to work without blocking timeouts.

After reading the ssh_config man page and some articles, here’s the best thing I came up with:

Host *
	ControlPath ~/.ssh/master-%r@%h:%p
	ControlMaster auto
	ControlPersist 4h
	TCPKeepAlive no
	GSSAPIAuthentication no
	ServerAliveInterval 60
	ServerAliveCountMax 2

The only issue with this configuration is with long hosts (eg: a really long name) as it hits the UNIX_PATH_MAX limit. Unfortunately, the proper solution to this issue isn’t merged into upstream.

The OS X users who also use brew may easily include the patch for the path issue by editing the openssh formula for OpenSSH 6.6p1 with “brew edit openssh”:

  patch do
    url "http://www.mirrorservice.org/sites/downloads.sourceforge.net/m/ma/mancha/misc/openssh-6.6p1-mux-hash.diff"
    sha1 "31f6df29ff7ce3bc22ba9bad94abba9389896c26"
  end

With this patch, a value like ~/.ssh/master-%m works for ControlPath. %m is replaced by SHA1(lhost(%l) + rhost(%h) + rport(%p) + ruser(%r)) and it keeps things short and sweet.

Getting a HTTPS certificate information into the shell

Due to the HeartBleed SNAFU, I needed a quick solution for getting the information from a certificate deployed on a remote machine. As I rarely leave the comfort of my terminal, as always, I simply dumped a new function into the shell’s ~/.*rc file.

Here it is:

Defaults to port 443 if the second argument is unspecified. Example: