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 220.127.116.11 (the version that was installed on it), 18.104.22.168NA (basically the same as previous, but region locked to USA, so it would stick to FCC’s emission regulations), and 22.214.171.124 (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, v126.96.36.199. 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=188.8.131.52 server=184.108.40.206
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.
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.