All your AP base are belong to us

Wireless empowers us to conveniently participate in the modern “connect everything” age. Almost every household and business is running a wireless network of some form. We are addicted to the technology, which in turn has created a smoke haze of denial that wireless is secure. We choose the ignorant path, as we are all well aware of how insecure the medium is, yet we still see alarming rates of poorly configured wireless networks.

Unfortunately for us, wireless is so simple to break, even without any knowledge of coding an exploit or understanding the technology. The amount of point-and-click programs freely available to automate unauthorised access to a wireless network is staggering. These tools are so easily available, that even ‘skids’ are starting to believe they have l33t h4x0r street cred and skillz.

The purpose of this post is show you how to test your wireless network for easily exploitable vulnerabilities, focussing on the very basic reason why your l33tp4ssw0rd is not as strong as you believe it is, and why you should NOT be running WPS unless you have a specifically hardened WAP or a particularly good reason for running the protocol.

The flood of incorrectly configured 802.11 networks is creating easy access for maliciously minded folk to easily gain access to your network, and in the majority of cases without your knowledge. It is very rare for the average turn-key consumer to check their logs, mac-tables, or DHCP leases. Take a look at the below three hour data gathering exercise from SE Queensland. Note that none of these networks were accessed, and all were freely broadcasting their SSID.

Over 10,000 wireless networks were discovered in a very short time. The only equipment used was a simple laptop, a wireless card, and a GPS receiver. Whilst it’s hard to see from the small size of the images and text, 25% of the wireless networks had no security at all (fully open), 30% utilised a WEP key as there only form of encryption, and the remaining 45% of networks used WPA or WPA2 encryption keys.

The tools we are going to use in this post come from the aircrack-ng library, reaver, and macchanger. Other tools such a fern-wifi-cracker, wepcrack, or wifite are all capable of varying attacks however are not tools that I rate useful for my particular toolbox. Like previous posts, I am not here to spoonfeed people. I won’t be going into details or explaining too much about the aircrack-ng tools, nor which wireless chipsets allow packet injection, power manipulation, etc. For more information on the tools and their usage, as well as a lot of other ‘getting started’ type info, head on over to the aircrack-ng website. With that said, fire up your favourite linux distro and let’s crack on.

Wireless equipment that I am using for all these tests are:

– D-Link DSL-2750B WAP/router (firmware version AU_3.01)
– Alfa AWUS036H Wireless USB

By default, I always setup my wireless testing in a particular way that suits my vulnerability testing needs. The following is a simple bash script I run to get my environment ready:

#!/bin/bash
clear
echo -n "What interface to use? ie 1: "
read -e IFACE
echo "* Setting zone to Bolivia"
iw reg set BO >/dev/null 2>&1
echo "* Setting power to 30"
iwconfig wlan$IFACE txpower 30 >/dev/null 2>&1
echo "* Going all ninja on the wifi"
airmon-ng stop mon3 >/dev/null 2>&1
airmon-ng stop mon2 >/dev/null 2>&1
airmon-ng stop mon1 >/dev/null 2>&1
airmon-ng stop wlan$IFACE >/dev/null 2>&1
echo "* Time to go all stealth like"
airmon-ng start wlan$IFACE >/dev/null 2>&1
echo "* Turning off power saving"
iwconfig wlan$IFACE power off >/dev/null 2>&1
echo "* Randomising mac address for wlan$IFACE"
ifconfig wlan$IFACE down >/dev/null 2>&1
macchanger -r wlan$IFACE >/dev/null 2>&1
ifconfig wlan$IFACE up >/dev/null 2>&1
echo "* Randomising mac address for mon0"
ifconfig mon0 down >/dev/null 2>&1
macchanger -r mon0 >/dev/null 2>&1
ifconfig mon0 up >/dev/null 2>&1
echo "* Enjoy the ride.... :)"

Basically, I set my regulation zone to Bolivia so that I can open up further channels and not have my power levels FCC restricted. (Please note that this is in a controlled environment which does not impact nearby radio transmissions or equipment. Ensure you follow the specific FCC rules in your area.) Next I create a monitor interface and randomise the mac address of my particular wireless card. The only step that is necessary for your particular setup is the monitor mode of the interface, all other setting are not necessary and are simply my preference.

There are a number of attacks that I have no need to elaborate on, as the myriad of existing vulnerabilities are very well documented. There are plenty of articles already on the interwebs explaining how to generate IVs and crack WEP, how to do dictionary or rainbow attacks with Pyrit or coWPAtty against WPA or WPA2, with or without clients. So open up google and do some trolling yourself if you are interested in well known vulnerabilities surrounding the deployment of wireless networks. As a side note, the only time you will really find a challenge with WEP is if it is using EAP-TLS x.509 certificates for final authentication, which I will cover in a future post regarding physical access and certificate replay.

So let us start with the current flavour of the month; WPS attacks. Back in late 2011 Stefan Viehböck made comment on implementation flaw with WPS that enables an attacker to brute force the the 8 digit pin used to associate a client. In short, the press button or soft button action to connect with a simple to remember pin would enable a user to set a very secure encryption key without the need to remember or share the complex key with their guests. Once the code has been revealed, the WAP will advertise to the supplicant the WPA/WPA2 network key.

For the following example, I have set the WPA2 network key to a complex string (!t|1s()*&HN6H4VVVDŽ)~!) that I know does not currently (until now for the scrapers) exist in a number of popular large word lists. The purpose is to show you that by brute-forcing the 8 digit pin, the WAP will simply give up the string for our convenience. Let’s rock and roll.

The first step is to find our WPS enabled WAP. To determine WPS enabled WAPs we can simply run the wash -i mon0 command.

As you can see from the above screenshot, we have a WPS enabled device. To spark further interest, we notice the RSSI is -22, which as you know means the device is close, which in turn means that our RXQ is certain to be around 100%.

With the target acquired, let’s try to bruteforce the pin. For this we will use a tool called reaver as follows: reaver -i mon0 -b C0:A0:BB:C1:21:6A -vv -d 0 -t 2 (For specific information about how to use reaver, navigate to this webpage). I like to perform most activities verbosely, hence the -vv argument. Also, as this device is relatively close and we are receiving good beacons and data packets (obtained by running airodump mon0 in reccy activities), I have chosen to reduce the delay between pin attempts.

As you can see we are successfully receiving M1 through to M4 messages and handshakes. The entire process can take anywhere from 1 minute, through to 24 hours depending upon the manufacturers default pin the the AP rate limiting factor. As you can see below, our WPS bruteforce attack forced the WAP to give up the pin, and more importantly, gave up the relatively complex PSK that was set for authentication. WPA PSK: '!t|1s()*&HN6H4VVVDŽ)~!'

There are a few factors we need to consider with this attack. Some WAPS set an infinite rate limiting or lockout period. You’ll be able to identify these devices as the rate limiting warnings will continue during your attack, or during a wash reccy you will notice the WPS locked variable will be set to Yes. Another point of interest is that you need to have a stable connection with the AP to make the attack viable. In my vulnerability testing, I like to use a directional antenna and to ensure I am receiving 100% RX quality and a good fluid increase in beacons. It’s a bit of a zen environment, but if all the planets align there is no reason why a vulnerable WAP won’t give up the PSK.

For me, the moral of the story is this. Investigate whether your WAP is vulnerable by utilising freely available open source tools. If your WAP is vulnerable, and you have no alternative but to run WPS, investigate whether there is a firmware upgrade available for your WAP and apply the patch accordingly. Personally, I ensure that WPS is off on all wireless networks which I connect to. I am not really concerned as to whether someone has access to your wireless network and leaches your internet quota; realistically who cares. I am more concerned that someone is sitting on a wireless network I connect to and they performing are performing a Man-In-The-Middle (MITM) attack and sniffing my traffic. In future posts, I will show examples of what damage an anonymous person can do when connected to your network, and how easy it is to start collecting usernames/passwords and personal information. But for now, if your router/WAP has a WPS function, TURN IT OFF!