802.11 Pocket Reference Guide Sample
I’ve posted my IEEE 802.11 pocket reference guide to the Projects Section. This legal-sized guide provides some quick-reference resources for wireless analysis including common acronyms, Wireshark display filters, Kismet shortcuts and a breakdown of several of the IEEE 802.11 header fields. This will be especially helpful to my SANS SEC617 Ethical Hacking Wireless students!
-Josh
New slides I’m delivering tonight at the SANS Denver 2009 conference on using Kismet Newcore for wireless assessment in the role of wireless network administrator, auditor or ethical hacker. Check it out in the usual place.
Thanks to @jabra for his help in getting the BT4 update repository current with the most recent Kismet Newcore fixes.
-Josh
As it turns out, there was a pretty significant bug in cowpatty 4.5 and earlier when built on systems with a more modern version of OpenSSL than what I was testing against:
typedef struct {
unsigned char k_ipad[65];
unsigned char k_opad[65];
unsigned char k_ipad_set;
unsigned char k_opad_set;
} SHA1_CACHE;
struct SHA1_CACHE cached;
SHA1_CTX context;
/* ... */
if (usecached) {
/* Cache the context value */
memcpy(&cached.k_ipad, &context, sizeof(context));
cached.k_ipad_set = 1;
}
When I looked at this I realized what the problem was right away: I was stupid when I wrote this code.
One of the ways we can accelerate WPA2-PSK cracking is to cache values that are computed each time during SHA1 rounds; namely the inner and outer pad hashes (ipad, opad). I implemented this in cowpatty and created a data structure SHA1_CACHE to store the hashed value with a field to indicate if it was currently cached or not.
At the time, OpenSSL’s SHA1_CACHE structure was 64 bytes; I created my structure members at 65 bytes (why not 64 bytes? Because I was stupid when I wrote this code). Perfect!
All worked well until I recently discovered that the SHA1_CTX structure is now 96 bytes, which did not fit so well in my 65 byte data structure.
The lesson here: don’t try to recreate the wheel. This is how I fixed the problem, and how I should have done it back in 2005:
typedef struct {
SHA1_CTX k_ipad;
SHA1_CTX k_opad;
unsigned char k_ipad_set;
unsigned char k_opad_set;
} SHA1_CACHE;
Instead of relying on a static byte length that once characterized the size of SHA1_CTX, I should have just used the real thing. I’ll remember this lesson in the future, and hopefully you won’t make the same mistake I did.
You can snag the latest version of cowpatty here. Special thanks to Kevin Kestinggolrer, Philipp Schroedel, Max Moser and Nathan Grennan, Jason Franks and Michal Knobel for hitting me with their various clue-sticks.
-Josh
After too much time I have posted coWPAtty 4.5 with several fixes and a couple of new features:
The “-2” option also includes fewer restrictions for validating the content of the packet capture. This was implemented by a patch submitted by Nathan Grennan, accommodating some AP’s that do not strictly adhere to the IEEE 802.11i/IEEE 802.11-2007 specification.
Removing the restriction of needing all 4 frames of the 4-way handshake to mount an attack has some interesting implications. First, packet captures taken while channel hopping often miss parts of the 4-way handshake, since they can hop in the middle of the 4-way handshake exchange. Relying on only frames 1 and 2 gives you a better chance of catching the needed data even if you are channel hopping.
coWPAtty "-2" utilization example
Second, it provides the ability for an attacker to mount an attack against a client even if they aren’t within range of their target network (for example, a WPA2-PSK user is at the airport). Consider the following illustration:
Cowpatty Attack Scenarios
On the left is an example of what I consider a traditional WPA2-PSK attack. The attacker gets within physical proximity of the target network and waits for (or coerces) the 4-way handshake between an AP and a valid client system.
On the right, however, is a less-understood attack scenario. In the 4-way handshake, the client system authenticates first, sending a HMAC-MIC of frame 2 to the AP. If an attacker impersonates the legitimate SSID of the network, they are able to send Frame 1 of the 4-way handshake (no authentication) and observe the HMAC-MIC of frame 2. At frame 2, the attacker has everything they need to recover the PSK (now with cowpatty’s “-2” option). Frame 3 fails validation by the client, but by that point, it’s too late.
In practice, I’m testing this using HostAP running on my attack workstation, but that’s not even necessary. Simply take any SOHO AP, configure the SSID to reflect that of your vistim with any pre-shared key and observe the exchange between the victim and the imposter AP, supplying the packet capture to coWPAtty with the “-2” option.
My transition to work for InGuardians has given me a chance to spend more time on penetration tests. As a result, I’ve started to change my mind about the value of “weaponized” attack tools. If the tool isn’t reliable, works under many circumstances and flexible enough to withstand an error or two, it takes much longer to be useful, and that costs your customer more. I’m using this as a motivator to make tools more effective, capable of demonstrating a point, and thereby allowing you to providing greater value to your customer.
I’d love to hear comments and questions. Please add a comment below, or send me a note.
-Josh
Dragorn has posted a bunch of screenshots for Kismet-Newcore, demonstrating some of the cool UI features including traffic activity timeline view, update client list view, plugins view, network details view, color preferences, channel utilization (signal and noise) view, and channel configuration.
Kismet-Newcore Main UI View
Check them out at http://kismetwireless.net/screenshot.shtml.
-Josh
Just a little while ago, dragorn released RC1 of Kismet-Newcore, the much-awaited next-generation of Kismet. From the release news:
After 5+ years of development, this staging release is to work out any final minor issues before a full release. Kismet-2009-05-RC1 is expected to be fully functional, so please report problems on the forums or via email. Please read the new README and replace your configuration files, as just about everything about configuring Kismet has changed (for the better!) The old Kismet tree also sees a new release as Kismet-old-2009-05-R1, which incorporates minor fixes and support for some of the newer Intel and Ralink cards/driver names. Both are available from the download page.
Kismet-Newcore Screenshot
I’ve been moving away from using Kismet-Stable to the Kismet-Newcore architecture. On my short-list of awesome-new-features in newcore are:
The development leading up to this release has been long in coming, and cheers to dragorn for continuing the introduce awesome new features that push the edge of what this powerful tool can do.
Take a look at the new Kismet-Newcore and enjoy this gem of the open source community.
-Josh
Wlan2eth is a tool I wrote to convert 802.11 packet captures into Ethernet-style captures; I find this useful when working with various sundry tools that don’t properly handle 802.11 frames.
Adrian Crenshaw sent in a bug report for wlan2eth where he was getting the following output:
$ ./wlan2eth ../forjosh.pcap out.dump
Converted 0 packets.
Turns out I didn’t have support for other 802.11 packet capture link types (Adrian was using PRISM_AVS). I’ve updated wlan2eth to fix this issue, while adding support for Ad-hoc network captures as well.
Thanks,
-Josh