TL;DR: Installing hostapd-wpe on a wireless router powered by an external power bank provides a standalone wireless attack platform with good transmit power, concealability, and mobility.
Despite being almost 5 years old (but recently updated to support hostapd 2.6), hostapd-wpe is still a go-to tool for assessing the security of wireless clients attached to WPA2 Enterprise networks. The War Room has written about the tool multiple times, from basic installation and use to creating spoofed certificates to fool untrained users.
The original hostapd-wpe is not the only tool to support this type of attack. Similar functionality is included in Sensepost’s MANA toolkit and s0lst1c3’s eaphammer.
Though all these tools bring some unique capabilities to a wireless or red team assessment, they share the common delimiting factor of wireless hardware. Namely, they’re often conducted on a laptop with either an internal or external wireless card.
(Note: I am aware that the Wi-Fi Pineapple NANO and TETRA exist. But in addition to costing respectively $99.99 and $199.99 without a power source, they do not support attacks against WPA2 Enterprise out of the box.)
Using the “laptop and wireless card” approach can introduce the following limitations:
Transmission Power: Depending on the type of assessment you’re conducting, you may have limited access to areas with the highest density of wireless clients. It can be difficult, if not impossible, to beat out enterprise APs with an on-board or USB wireless card.
The TP-Link TL-WN722N is a favorite of ours because of its low cost, support for external antennas, and ability to operate in master mode. However, it transmits at less than 20 dBm, whereas a Cisco wireless access point can put out 23 dBm. Remember that this 3 dBm increase is twice the power output.
Transmission power is not everything when it comes to radio frequency communications, but it is one of the variables we can control in an attack scenario. This can be overcome in part with directional antenna, but that brings us to the next problem.
Concealment and Mobility: You can increase the success of wireless attacks with external cards and directional antenna, but these peripherals are cumbersome and call attention.
Timing and Duration: If your attack has you tied to a keyboard, it’s only going to last as long as you can sit somewhere and keep your laptop powered. Not necessarily challenging, but also not necessarily the best use of your time.
To address these issues we’ll return to the original hostapd-wpe, but on a different platform. Installing hostapd-wpe on a wireless router flashed with OpenWrt and powered with a power bank results in a tool with better transmission power, mobility, and the ability to operate unattended for a long duration.
Before we get into the steps, credit where it’s due – Acrylic WiFi posted early last year about Tarlogic’s version of hostapd-wpe for the OpenWrt Barrier Breaker release. The repository has existed on GitHub for over two years, but I was sadly ignorant of it until relatively recently.
Building a tool around this version of hostapd-wpe and adding additional OpenWrt packages can increase its utility and flexibility. This post walks through the following:
- Downloading, compiling, and installing hostapd-wpe for OpenWrt Barrier Breaker 14.07
- Adding support for a wireless adapter to function as a management network interface
- Installing screen
- Expanding storage space by extending the root filesystem to external storage
Prerequisites include:
- A compatible router with two USB ports and OpenWrt Barrier Breaker installed
- A connection to the internet for downloading additional OpenWrt packages
- A USB wireless NIC
- A USB flash drive
- A suitable system for compiling the OpenWrt hostapd-wpe package if you choose to do so (I used Kali 2.0)
I used a TP-Link N600 (TL-WDR3600 Version 1.5) I had on hand and which happened to be compatible with Barrier Breaker. If you choose to pursue a project like this, you’ll want to do some research to be sure your hardware is compatible before taking the plunge or spending any money. However, this can be difficult – for instance, at some point TP-Link changed the chipset in some of its devices without changing the nomenclature or version number. Differences such as this can be difficult if not impossible to identify without the device in your hands.
Tarlogic created packages for all OpenWrt architectures. I chose to compile these from source to familiarize myself with that process.
Step 1: Compile and Install hostapd-wpe
As noted, I performed the following on my up-to-date Kali 2.0 installation.
Install dependencies necessary for compilation:
apt-get install g++ libncurses5-dev git-core subversion mercurial \ gawk zlib1g-dev ccache
Download and decompress the ar71xx SDK. I worked out of the /opt/ directory:
wget https://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2 tar -xjf OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2
Download and unarchive hostapd-wpe for OpenWrt:
wget https://tarlogiccdn.s3.amazonaws.com/tools/hostapd-wpe-for-OpenWrt-14.07.tar tar -xf hostapd-wpe-for-OpenWrt-14.07.tar
Copy the hostapd-wpe directory from the Tarlogic hostapd-wpe download into the package subdirectory of the SDK:
cp -r ./package/hostapd-wpe/ ./OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2/package/
Copy the hostapd-wpe source code from the Tarlogic hostapd-wpe download into the dl subdirectory of the SDK:
cp ./dl/hostapd-wpe-2014-06-03.1.tar.bz2 ./OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2/dl/
If you’re in Kali you may be running as root. Attempting to compile as root will result in the error “Build dependency: Please do not compile as root.” If you don’t have a non-root user (shame on you), you can edit the prereq-build.mk file located in the /include/ directory of the SDK. Edit line 16, which checks to see whether you’re running as root.
make package/hostapd-wpe/compile
Success looks like this:
Collecting package info: done # # configuration written to .config # make[1] package/hostapd-wpe/compile make[2] -C package/hostapd-wpe compile
You should now have a bright and shiny new hostapd-wpe .ipk (hostapd-wpe_2014-06-03.1-1_ar71xx.ipk) in the /bin/ar71xx/packages/base directory of the SDK.
You can install the package with opkg locally, by transferring it to the router (such as via scp), or by sharing it on a webserver that the router can access.
Step 2: Add support for an external wireless device and install screen
Using a router like this as an evil AP is nice because it’s dual band. If you want to take advantage of both the 2.4 and 5 GHz radios while still being able to control the device remotely, you’ll need to add an additional USB wireless NIC. This is simple, but likely requires the installation of additional packages. I used a TP-Link TL-WN722N. Since that uses the Atheros chipset, I had to add support by installing the appropriate kernel module:
opkg update opkg install kmod-ath9k-htc
Though I settled on the TL-WN722N for this run through, a working thumbnail drive would reduce the router’s profile and limit the chances of the USB wireless card getting jostled out of place if you’re carrying the router in a backpack or something of that nature.
After inserting the card, perform a reboot,then remove the existing wireless configuration:
rm /etc/config/wireless
And run the following command to detect the new wireless card and build a configuration including it:
wifi detect > /etc/config/wireless
Now we need a way to remotely manage the router without running the risk of losing any progress or data in the event we become disconnected. Screen fits the bill here. As one of hundreds of programs that has been ported to OpenWrt, it is easily downloaded and installed using the opkg utility:
opkg install screen
With an additional wireless interface and Screen, you can use the router’s onboard 2.4 and 5 GHz radios to conduct your attack while using the USB wireless radio to broadcast a management network. By connecting to that network and SSHing in to the router, you can launch attacks, monitor attacks already in progress, or pull down logs that may include captured credentials. I chose to use the router’s web configuration interface to setup a wireless using WPA2 with a strong PSK.
Step 3: Expand the router’s root storage
As you poke around the router’s file system, you’re likely to notice that you’re rapidly running out of storage space. External USB storage could be used to store things such as hostapd-wpe logs, but if you plan on installing additional packages to extend the devices capabilities (such as the aircrack-ng suite, Python, openssl, etc.), you need to expand the root filesystem.
Expanding the root filesystem onto a USB storage device is referred to as “Rootfs on external storage” (extroot). Luckily, we still have a USB port open. As with the wireless card, using a small profile USB drive (such as a SanDisk Cruzer Fit) can limit the router’s overall profile and reduce chances that the drive will be knocked loose.
To perform this, you’ll need some additional packages, some for USB support and another to support extroot:
opkg install kmod-usb-storage opkg install kmod-nls-cp437 opkg install kmod-nls-iso8859-1 opkg install block-mount
Barrier Breaker supports two extroot options, pivot overlay and pivot root. Pivot overlay, which the official OpenWrt documentation recommends, extends the filesystem on the external drive. Pivot root essentially moves the entire root filesystem to the external storage. Pivot root may be a cool way to practice OPSEC and keep the router “clean,” by removing the drive when it’s not in use. However, for my first run, I used pivot overlay.
I followed the pivot overlay walkthrough appropriate for Barrier Breaker detailed here: https://wiki.openwrt.org/doc/howto/extroot.old
My working configuration is as follows:
config 'global'
option anon_swap '0'
option anon_mount '0'
option auto_swap '1'
option auto_mount '1'
option delay_root '5'
option check_fs '0'
config 'mount'
option target '/overlay'
option device '/dev/sda1'
option uuid 'f9a567d7-7gb6-4580-a59b-6c143nf76a11'
option fstype 'ext4'
option enabled '0'
The complete tool
There are plenty of power banks out there, but I settled on the Intocircuit PC-26000 (https://www.amazon.com/Intocircuit-26000mAh-Capacity-Portable-External/dp/B00BB5VQCE) based largely on cost and customer reviews. This power bank happily powered the router for hours without registering any loss in charge. I haven’t tested the total runtime, but I suspect it would be sufficient for any attack that needed to occur at a planned time or within a window of time.
I also outfitted the router with some high-gain omnidirectional antennas. Remember that higher gain antennas increase horizontal coverage but decrease vertical coverage, so the payoff varies depending on your target environment (for instance, a single-story versus multi-story building).
With the power bank, antennas, and wireless card running a management network, I can place the router in my backpack or in the general vicinity and monitor it with a terminal / SSH application from my smart phone. In the same manner, one could gather logs from the device without physically retrieving it, such as in the scenario below.
Attack scenario
As an example of how this tool could be used, consider the following scenario: Our team was conducting a red team engagement against a large client. We wanted to probe their wireless networks and clients as a part of this engagement without unnecessarily exposing or tying up our personnel.
Late in the evening, we parked a car in the corner of their employee parking lot closest to the office. Employees walking to and from the office would likely pass near the car.
A tool like this one was placed in the car, broadcasting an evil AP mimicking the enterprise network in use at the client’s office. Because it also broadcasted a management network, we could check on the device or retrieve logs without entering the car in which it was located or physically retrieving the device itself.
As employees passed their car on the way to and from work, their mobile devices and sometimes laptops would automatically associate. In this case, they did not attempt to authenticate, and no credentials were passed (good on them for configuring their devices properly). However, we did gather user IDs, the name of the internal domain, and host naming conventions, all of which were new information. Moreover, having a tool like this at the ready meant we could deploy it and reap the benefits of such an attack without spending much time or committing precious resources.
