Transmissions
Seven Yearss of Wireless Fun
by Dragorn
The stars (or in this case, access points) align: The summer issue for H2K2 had one of the first articles about Kismet (and my first article for 2600), and this summer has the first release of a completely rewritten Kismet which has been under development for five-plus years.
Besides, "Seven years of wireless fun" sounds better than "A bunch of years, and some wireless stuff."
So what's changed since 2002?
In many ways, not a whole lot. Absolutely shocking, really, that the average home user hasn't listened all that well. Slowly, however, the tide is turning; within 50,000 networks collected randomly over the course of six months across several major cities, approximately 30 percent of networks are still wide open, 40 percent use WEP, and the remainder use some form of WPA (significantly leaning towards WPA-TKIP; only five percent of the total advertise WPA2-AES). This is up from a few years ago, when 20 percent encryption was a promising statistic.
In retrospect, this info is available on www.wigle.net worldwide, but that would preclude bringing us to...
Stupid Kismet Trick #1: Quick-and-dirty processing of log files. Being, of course, absolutely on top of deadlines and never rushing things, I decided instead of writing a full XML parser to process log file lines, obviously the better solution was to spend a frantic five minutes with the AWK manual and toss together some ugly script:
#!/bin/bash cat *.nettxt | awk '/^BSSID/ { ssid=0; printf "%s ", $3; }; /:Beacon/ { ssid=1; } /Encryption/ { if (ssid) printf $0; }; /Channel/ { printf "\n"; };' | grep Encryption | sort | uniq | grep WEP | wc -l |
This gives us a least-possible-effort mechanism for taking a directory full of logs, squash the network plaintext output format into single-line records, and count them.
Unfortunately, it's harder to separate statistics about home networks from networks used for inventory control, point of sale, or offices. Using WEP on a home network is still, most likely, foolish, considering how easy it is to break, but using it on a network with any sort of business application is begging for an intrusion.
For Kismet, however, the changes since the early versions are significant.
Despite taking longer (much longer, as in multiple years longer) than intended, as several people are all too happy to remind me, the Kismet-2009-05-RC release incorporates a complete rewrite of the Kismet engine and user interface.
Among other key new features, Kismet sports a completely redone UI. While still in curses text mode (hey, I like curses, I curse all the time), the new user interface is widget-based and dynamically reconfigurable.
Bigger changes lie under the hood, however, with a completely redesigned packet processing system with usability and expandability as the main goals; Kismet will now automatically detect the driver type of network interfaces, can have new dynamic sources added while it is running, can export packets real-time to any other PCAP-based tool via tun/tap virtual network interfaces, automatically detect the supported channels on a capture interface, and keep running through most errors that would have killed previous releases.
Most significantly, Kismet now supports plugins which can do nearly anything within the framework that Kismet does already, such as defining new alerts, adding new commands and reports to the client-server protocol, and even defining new capture types and log files.
Internally, once read by a packet source, data travels the "packet chain" where any type of arbitrary information can be attached. Plugins can attach anywhere along the chain: New packet data, decryption, network decode, logging, and so on. Once attached, a plugin receives all data which was attached to the packet in previous stages (such as decrypted WEP data, IDS alerts, tracked networks and clients) and can attach any information, including new custom data to be interpreted by later stages. Plugins can also be attached to the client, and can add new windows and widgets, and even change the main window layout.
There's a lot of possibilities, but what actual plugins are there? So far, Kismet bundles two plugins of its own, Kismet-PTW and Kismet-Spectools, which implement a passive Aircrack-PTW and integrate with the Spectools spectrum analyzer software.
With the PTW plugin loaded, Kismet can automatically attempt to crack the WEP key of a protected network when enough data has been seen, without ever injecting any packets, automatically add the discovered WEP key to the log files for future reference, raise an alert that WEP has been cracked, and enter the WEP key into the decryption system so all future packets from the network are decrypted automatically.
The first third-party plugin comes from dedected.org and implements a completely new capture type, reading data from DECT digital phone cards and expanding Kismet sniffing beyond 802.11. Server and client plugins define a new network protocol for DECT phone records and display it integrated in the UI.
Stupid Kismet Trick #2: Getting information out of Kismet real-time. Kismet writes data files at regular intervals, but reading them while Kismet is running can cause problems. Fortunately, Netcat and (once again) AWK come to the rescue here:
#!/bin/bash echo -e '\n!0 enable channel channel,networks' | nc localhost 2501 | awk 'BEGIN { CHN = 0; }; /CHANNEL:/ { chnum[CHN]=$2; chval[CHN]=$3; CHN=CHN+1; }; /TIME/ { if (CHN != 0) { printf("["); for (x = 0; x < CHN; x++) { printf("{\"id\":%s,\"value\":%s}", chnum[x], chval[x]); if (x < (CHN-1)) printf(",") } printf("]\n"); CHN=0; fflush("");} };' | while read line; do echo "$line" > channel.json; done |
Which is the quick-and-dirty way of converting the Kismet channel usage report (in this case, number of networks per channel) into a JSON file for displaying channel usage in Ajax. Similar magic can be done to extract active networks in the vicinity, GPS location, IDS alerts, and any other data collected by Kismet.
Development continues, and hopefully others will start writing plugins (read as: that's a hint) to add new features and functionality.
Code: script-1.sh
Code: script-2.sh