These services utilize the same cracking techniques as an individual penetration tester (or attacker), but on a much greater scale – more CPU power, more disk space, and perhaps most importantly, more guesses by way of larger dictionary files. Compared to a popular wordlist from the folks at Offensive Security2 targeting WPA PSKs (consisting of 8 to 63 printable ASCII characters) that contains just over 47 million entries, these hosted services claim to use dictionaries that are orders of magnitude larger – consisting of up to 1.6 billion entries. Of course, the number of possible PSK values (>95^63) still easily dwarves this figure. Nonetheless, even a small amount of additional assurance that the PSK is not easily crackable is well worth an expenditure for any professional penetration tester, or conversely, for an attacker.
The issue here is one of trust, and protecting the client's network. By definition, a packet capture containing the WPA four-way handshake must include the wireless AP's BSSID (MAC address). Several (free) online services exist to provide geolocation of Wi-Fi networks based on ESSID and/or BSSID (the latter providing much more accurate results). I have referred to the crowd-sourced database at Wigle.net several times for this information.
Putting two and two together – suppose that one of the hosted PSK cracking services we submit a capture file to successfully identifies the PSK. We've now provided them with the ESSID, the network's physical location (via BSSID), and the PSK used to access the network and/or decrypt network traffic. By attempting to provide a more thorough test for our client, we've inadvertently created a significant exposure. Granted, the chance that the operator of the hosted PSK cracking service is within remote geographic proximity of our client's network is very slim. But consider that these services provide quite an attractive target for malicious attackers – by compromising a single backend database, an attacker could potentially gain access to thousands of Wi-Fi network locations and keys.
To the original intent of this post – finding a software solution to edit 802.11 packet captures, with the goal of anonymizing WPA capture files to be submitted to a hosted cracking service. Requirements for this software include the ability to change the BSSID and source and destination MAC address of the AP (access point) in order to prevent a third party from geolocating the network using these values.
Thus far I've tried using these promising tools, each unsuccessfully:
- the tcprewrite capability of tcpreplay: "supports a lot of Layer 2 rewriting options to help you modify packets" (does not support selectively replacing individual MAC addresses – instead, only replacing all "client" and "servers" MACs throughout)
- NETDUDE: "The Network Dump data Displayer and Editor is a framework for inspection, analysis and manipulation of tcpdump trace files" (unable to install due to incompatibility with gtk2+; has not been recently updated or maintained)
- bittwiste: "libpcap-based Ethernet packet generator and trace file editor" (a command line-based tool that unfortunately works only with Ethernet frames3)
- bssid-munge: thanks to a suggestion from the helpful folks at the Aircrack-ng forums, I learned of and gained access to this tool, which initially seemed ideally suited to the task. Unfortunately, I ran into two issues using this tool:
- after bssid-munge'ing a capture file with a known PSK, Aircrack-ng is no longer able to identify the key (although it correctly identifies the presence of the WPA handshake for the newly-labeled BSSID);
- although bssid-munge changes the BSSID value, as intended (verified using Wireshark), the source and destination MAC addresses identifying the AP remain unchanged, thereby limiting the anonymity afforded by using this tool.
- after bssid-munge'ing a capture file with a known PSK, Aircrack-ng is no longer able to identify the key (although it correctly identifies the presence of the WPA handshake for the newly-labeled BSSID);
What do other folks do in order to protect the network identity when submitting handshake capture files to online services? Please, let us know in the comments section below if you are aware of other options or alternatives to resolve this issue.
1 – hereafter referred to, more generically and simply, as 'WPA', and 'PSK' (back to post)
2 – originally used to generate ESSID-specific rainbow tables; no longer online (back to post)
3 – I considered using wlan2eth to convert the capture to an Ethernet format, but unfortunately this conversion process would eliminate the 802.11 Beacon frame required by the standard PSK cracking tools Aircrack-ng and coWPAtty (back to post)
