Pineapple Corporate Toolkit - Part 1
August 13, 2015
HAK5’s WiFi Pineapple (Pineapple) is a low cost embedded device, purpose-built, for attacking 802.11 wireless networks that can be purchased for about $100. The Pineapple offers the open source flexibility of the popular OpenWRT firmware and can, additionally, be leveraged as a covert tool to establish persistent backdoor access to a remote wired or wireless network environment.
Although the WiFi Pineapple offers a large array of wireless attacking techniques, from KARMA to WPS brute force attacks, there are toolset limitations when it comes to attacking wireless network security and encryption settings typically found in corporate environments. A common configuration for these environments is to utilize 802.1x client authentication in combination with a RADIUS server. The attack methodology for 802.1x wireless environments is to identify if wireless clients have been properly configured to validate certificates issued from the RADIUS server. Wireless clients, that have been improperly configured, will accept rogue self-signed certificates and supply hashed account credentials. To successfully exploit these client side vulnerabilities, the corporate wireless environment would need to be cloned with an attacker controlled RADIUS server. FreeRadius is the typical RADIUS server leveraged for this attack scenario, however, by default, FreeRadius is not configured to gracefully accept all client provided authentication requests (a requirement to collecte hashed credentials).
FreeRadius-wpe contains a set of patches that when applied to the FreeRadius 2.1.12 source code, allow FreeRadius to accept all user provided authentication requests and collect hashed credentials. Unfortunately, the FreeRadius-wpe binaries are not available in the OpenWRT package manager and require the source code to be cross compile for the Pineapple CPU architecture. Additionally, FreeRadius-wpe has been deprecated in favor of hostapd-wpe.
Installation and execution of hostapd-wpe, on the Pineapple, has many of the same challenges of FreeRadius-wpe. Furthermore, there is not much publically available documentation detailing the process of successfully running hostapd-wpe on OpenWRT. Luckily, Acrylic Wi-Fi has prebuild OpenWRT packages for hostapd-wpe in their Barrier Breaker package.
Acrylic Wi-Fi’s Barrier Breaker package contains the hostapd-wpe source and cross-compiled OpenWRT packages for each available OpenWRT supported architecture. The specific version, used in this exercise, is located in the ‘ipk’ directory of the Barrier Breaker package, under the ar71xx / generic sub-directories.
Unfortunately, initial execution of the hostapd-wpe application on the WiFi Pineapple post-installation of the ipk package (to the local disk or the available SD card) results in a segmentation fault.
Figure 1: Unfortunate Circumstance
This failure is believed to be the result of a conflict between the execution of the hostapd-wpe package and an existing instance of wpad-mini, which is designed to support many of the default features of the Pineapple. The Pineapple wpad-mini package is the OpenWRT implementation of the WPA Authenticator and Supplicant functions for WPA-PSK configurations.
Disabling the Pineapple’s wpad processes to execute hostapd-wpe is not advantageous because most of the Pineapple’s functionality is designed around the prebuilt instance of wpad-mini. Also, patching the default Pineapple wpad hostapd module is not possible because Hak5 does not provide the source of the custom hostapd patches bundled with the device in the SDK.
Figure 2: hostapd Pineapple Patches
In order to allow both the wpad-mini package and hostapd-wpe to run concurrently, it is necessary identify an alternative method of executing hostapd-wpe without negatively impacting the wpad-mini process. Parallel execution both wpad-mini and hostapd-wpe can be accomplished by executing hostapd-wpe within a root jail environment.
Building Root Jail
A root jail environment will allow the Pineapple to run a secondary file system in parallel to that of the utilized by the core system. To support the chroot functionality of the root jail environment, it is necessary to install the coreutils-chroot dependency package from the OpenWRT package manager:
opkg install coreutils-chroot
To build the root jail environment, a secondary file system hierarchy also needs to be configured. OpenWRT does provide the default firmware root file system, typically found on embedded devices, to support root jail environments. However, the OpenWRT default firmware does not contain the required platform specific modifications that HAK5 makes to the Pineapple. In order to build a custom root jail environment for the Pineapple, the root file system must be extracted. This task can be accomplished by accessing the latest HAK5 Pineapple firmware package directly.
Extraction of the root file system from the firmware package can be performed with binwalk from the default Kali Linux toolset.
binwalk –e upgrade-2.3.0.bin
Figure 3: Firmware Extraction
This command creates a squashfs compressed file system containing the Pineapple root file system. The extracted squashfs file archive can be uncompressed with squashfs-utils:
apt-get install squashfs-utils
unsquashfs –f –d ../mark5_2.3.0 E278c.squashfs
Figure 4: Uncompressed File System
The extracted root file system only consumes about 20Mbs of, uncompressed, space. Which is well below the space limitation of the default 4Gb SD card provided with the Pineapple. After successful extraction, the root file system needs to be transferred to the Pineapple. In the example here, the root file system was compressed in a tar ball, transferred, and subsequently extracted on the Pineapple in the /sd/chroot directory.
Once the file system is extracted, the next step is to mount both /dev and /proc for use by the root jail environment:
mount –o bind /dev /sd/chroot/dev
mount –t proc none /sd/chroot/proc
In order to maintain access to any custom installed packages, contained on the SD card within the root jail environment, the SD card can simply be hard linked. The following command will allow mounting the local SD card within the root jail environment.
mount –bind /sd /sd/chroot/sd
The OpenWRT package manager requires a lock file to be created in the /var/run directory. By default the /var directory does not contain a run subfolder, to meet this requirement a run directory must be created as follows:
mkdir –p /sd/chroot/var/run
The final step in completing the chroot configuration, is configuring access to the root jail by issuing the following command:
Once inside of the root jail, the next step is to install the hostapd-wpe ar71xx / generic package from the Arcylic Wi-Fi Barrier Breaker package.
opkg install hostapd-wpe_2014-06-03.1-1_ar71xx.ipk
The hostapd-wpe package from Arcylic Wi-Fi installs the binary to /usr/sbin/hostapd-wpe, and the configuration files are placed in /user/local/etc/hostapd-wpe. Several default hostapd scripts are provided in the configuration directory, and for ease of use, these can quickly be modified to specify the appropriate wireless interface and SSID to run hostapd-wpe against (i.e. by modifying the ‘interface=’ and ‘ssid=’ fields).
Figure 5: Hostapd Config File
In this example, the configuration file has been modified to associate with an Alfa AWUS051NH card as interface “wlan2”. The SSID has been set to ‘evil’, both figuratively and accurately. It is also good practice to update the certificates used by the hostapd RADIUS implementation to reflect the particular environment under attack via the bootstrap application provided in the hostapd-wpe package (hostapd-wpe-for-OpenWrt-14.07/bootstrap/certs).
Finally, launch hostapd-wpe and bask in the glory of captured RADIUS credentials:
Figure 6: Ooooh Glorious Creds
As a secondary option, commands can specifically be executed in the root jail environment without the need to start a shell.
chroot /sd/chroot hostapd-wpe /usr/local/etc/hostapd-wpe/hostapd-wpe-bgn.conf
For ease of use, it is possible to create a chroot setup script to configure the chroot environment during the Pineapple boot process. The following shell script can be added to /etc/rc.local so the chroot environment is live each time the device is started.
if ! df | grep "chroot/dev" >/dev/null; then
mount -o bind /dev /sd/chroot/dev
mount -t proc none /sd/chroot/proc
echo "bind && proc are already mounted"
if ! df | grep "chroot/sd" >/dev/null; then
mount --bind /sd /sd/chroot/sd
echo "SD is already mounted"