Dec 17

Wordlist Generation – CeWL on Ubuntu

CeWL is a custom wordlist generator written by Robin Wood. Written in Ruby, CeWL takes a target website as an argument and crawls the site for HTML, MS Office (2007 and earlier) and PDF documents. For each supported document, CeWL extracts the words, email addresses and metadata to build a wordlist.

Used with tools such as Asleap and coWPAtty, CeWL’s wordlist generation technique can be very useful, building a dictionary off words found on the target website. This often includes project names, acronyms and other content that apply specifically to the target and may be successful in a dictionary attack where standard dictionary words would not.

While I’m working on another project, I’ve departed from Gentoo to run Ubuntu 9.10. I’m looking forward to the day I can return to Gentoo, but until then, I got CeWL to run on Ubuntu without much complication:

$ sudo apt-get install exif libimage-exiftool-perl
$ sudo gem install http_configuration spider mime-types mini_exiftool rubyzip spider
$ echo "export RUBYOPT=\"rubygems\"" >>~/.bashrc
$ source ~/.bashrc
$ wget
$ tar xvfj cewl_2.2.tar.bz2
$ cd cewl
$ ./cewl.rb  --help
cewl 2.0 Robin Wood ( (

Usage: cewl [OPTION] ... URL
        --help, -h: show help
        --depth x, -d x: depth to spider to, default 2
        --min_word_length, -m: minimum word length, default 3
        --offsite, -o: let the spider visit other sites
        --write, -w file: write the output to the file
        --ua, -u user-agent: useragent to send
        --no-words, -n: don't output the wordlist
        --meta, -a: include meta data
        --email, -e: include email addresses
        --meta-temp-dir directory: the temporary directory used by exiftool when parsing files, default /tmp
        -v: verbose

        URL: The site to spider.

CeWL is one of the tools we cover in my Ethical Hacking Wireless course, running next in New Orleans on January 11-16. It’s not too late to sign up for this class, and escape the winter chill for good food and wireless hacking in New Orleans.


Jul 03

Cowpatty 4.6 (with less teh suck)

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.


Jun 04

Cowpatty 4.5

After too much time I have posted coWPAtty 4.5 with several fixes and a couple of new features:

  • Fewer restrictions on collecting the data needed to mount an attack.  The default behavior requires all 4 frames of the 4-way handshake to mount an attack.  If you specify “-2″ on the command-line, coWPAtty will only require frames 1 and 2 of the 4-way handshake to mount an attack.  More on this below.
  • Validate that the needed information is present to mount an attack, without launching the attack (the “-c” option).  This was requested by Pure Hate for an awesome project he gave me a preview on.  I’m hoping details of this project will be public soon.

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

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

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.


May 26

Kismet-Newcore Screenshots

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

Kismet-Newcore Main UI View

Check them out at


May 26

Kismet Newcore RC1 Released

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

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:

  • Plugin architecture makes it easy to add new functionality (passive and active) which promises to introduce significant new features on a more regular basis, not the least of which are support for DECT sniffing, live Aircrack-PTW WEP cracking and (coming soon?) ZigBee sniffing;
  • Improved security model using suid-root group-exec-only interfaces;
  • Lots of greater functionality in capture sources including improved channel hopping controls and graceful interface termination with dynamic interface adding (no more exiting Kismet to add or remove an interface from use);
  • Save state feature where you can resume a previous capture state by running “kismet -r” on the runstate file;
  • New menu-driver Kismet client interface which shows you the interesting information at a glance;
  • Lots of new alerts and informational events help you in analyzing and assessing networks.

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.


May 13

Wlan2eth 1.2 Release

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.