The most common and useful group of wireless network discovery and traffic analysis tools use the RFMON mode combined with hopping through all DSSS
channels. This lets you discover wireless hosts via detecting and analyzing passing traffic including all kinds of control and management frames. Your client card
receiving sensitivity (dBm) becomes the only limiting factor in network discovery and it can be greatly alleviated by the use of high-gain antennas and bidirectional amplifiers.
The next part of the chapter is devoted to the description of wireless sniffers that we have found to be useful while doing penetration testing while working for Arhont Ltd. Both fully blown advanced tools and simple shell scripts are outlined.
Although simpler tools and scripts might not be as exciting, they have their niche in both wireless penetration testing and network troubleshooting. They are easy to incorporate into your custom scripts, consume minimal resources, and are educational, in particular for novice wireless security tools developers.
Kismet
Kismet (http://www.kismetwireless.com) was our workhorse for years and is a universal 802.11 sniffer that went a long way from a wardriving tool to a full-blown wireless protocol analyzer and an IDS suite. The IDS features of Kismet are reviewed in Chapter 15; for now we'll concentrate on the network discovery and traffic dumping features of Kismet.
Kismet is easy to install and configure on any UNIX-like operating system;
however you can also use it in Windows running Cygwin. To do this, you should compile Kismet with:
arhontus:~# ./configure --disable-pcap --without-ethereal --disable-gps --disable-wireless --disable-netlink --disable-suid-root --enable-wsp100 && make && make install && make clean
Pay attention to the --enable-wsp100 string in the configure command. The problem with running Kismet and any other noncommercial wireless sniffer that
uses RFMON mode in Windows is that publicly available Win32 drivers just don't support the mode and cannot be reverse engineered and rewritten without
breaking the law. A way around the problem is to buy the RFGrabber from
http://www.wildpackets.com/ (formerly the WSP100 Remote 802.11b Sensor of http://www.networkchemistry.com/) or the Neutrino Distributed 802.11b Sensor from http://www.networkchemistry.com/. These hardware sensors are easy to integrate with Kismet; simply put source=wsp100,"host":"port",wsp100 into the kismet.conf file. Kismet_monitor script has wsp100 configuration part:
"wsp100")
echo "Enabling a wsp100 at $DEVICE for channel $CHANNEL"
if test "$HOSTIP" == ""; then HOSTIP=`hostname -i`
echo "'hostname -i' thinks our IP is $HOSTIP. Set HOSTIP manually if this is wrong."
echo " ie, HOSTIP=1.2.3.4 kismet_monitor"
fi
WSPDEVICE=`echo $DEVICE | cut -f 1 -d:`;
WSPPORT=`echo $DEVICE | cut -f 2 -d:`;
# sensor::loghostaddress
snmpset -c public $WSPDEVICE .1.3.6.1.4.1.14422.1.1.5 a $HOSTIP # sensor::channel
snmpset -c public $WSPDEVICE .1.3.6.1.4.1.14422.1.3.1 i $CHANNEL # sensor::serverport
snmpset -c public $WSPDEVICE .1.3.6.1.4.1.14422.1.4.1 i $WSPPORT # sensor::running
snmpset -c public $WSPDEVICE .1.3.6.1.4.1.14422.1.1.4 i 1
;;
This would configure the sensor via SNMPv1, including setting the device IP, channel to sniff, and User Datagram Protocol (UDP) port set in kismet.conf to pass the sniffed wireless traffic. Channel hopping has to be set on the sensor manually or using kismet_hopper -s <hop sequence> -v <velocity> & if
needed. The "public" community is used with the snmpset command and SNMPv1 itself has known insecurities (e.g., lack of authentication). Thus, the sensor is very vulnerable to attacks from the wired LAN side. Changing the SNMP
community on the sensor is a very good idea. Don't forget to modify the kismet_monitor script appropriately after changing the community string.
Overall, deploying such sensors together with Kismet might provide a good
distributed network monitoring and intrusion detection solution, while keeping the Windows administrator in the Microsoft world. However, such a solution is not scalable for remote penetration testing and is a bit on the expensive side. As in many other cases, it is cheaper and easier to use Linux/BSD.
We have never had any problems compiling Kismet on these systems and you can always install it from your distribution packages, although we recommend
grabbing the latest sources of Kismet from the CVS and compiling them yourself.
Kismet's configure script is rich in options, including --enable-wsp100 to enable WSP100 remote sensor support in the configuration files and --enable-zaurus to enable piezzo buzzer on a Sharp Zaurus PDA when a network is found. If you want to cross-compile Kismet for Zaurus use this:
arhontus:~# ./configure --host=arm-linux --disable-pcap --enable-zaurus --disable-setuid && make
For the iPAQ Familiar distribution employ this:
arhontus:~# ac_cv_linux_vers=<your kernel version>
./configure --host=arm-linux --with-pcap=linux --disable-setuid && make
The only true dependency you need for compiling Kismet is Ethereal's wiretap and we assume that you already have the latest version installed. Ethereal is great for studying Kismet dump files. In addition, Kismet can use the Ethereal wiretap
library for dumping and processing these files. If you plan to use a GPS device, you'll need to install GpsDrive (http://www.kraftvoll.at/software/), which includes the GpsDrive daemon that Kismet interfaces with. Finally, if you want to impress your clients, employers, or peers with a cool talking Kismet, you can install
Festival speech generator supported by Kismet. Appropriate synthesized speech packages will have to be installed for Festival to work.
After the compilation (use "gmake" and not "make" if on BSD), take a good look at /usr/local/etc/kismet.conf. You will need to do the following:
Disable the MAC filter.
Set an unprivileged user to run Kismet if you don't want to use your casual unprivileged user.
Allow 127.0.0.1 to connect.
Set maxclient=1 (unless you deploy Kismet as an IDS server for connecting many clients).
Set the source for your sniffed packets (e.g., source=cisco,eth1,cisco).
Enable GPS (gps=true) if needed.
Adjust the write interval (seconds; use 0 if you don't dump any data).
Adjust your sound using play and Festival, set metric=true unless you use obsolete distance measurement systems.
Set GPS waypoints.
Check the file types for dumped or logged data (default settings are fine for us).
Set noiselog and beaconlog to false (you'll still log the first beacon and will save a lot of hard disk space by not logging the rest of the beacons from the same access point).
Most likely you should leave the rest of the settings as they are.
Now bring up the interface you want to sniff on using ifconfig (recommended), run kismet_monitor as root, then run kismet_hopper (unless you use a Cisco Aironet card), log in as a user you set for Kismet to run, and run Kismet, perhaps giving it an interface to sniff on with a -c flag, (e.g.,
arhontus:~# kismet -c cisco,wifi0,cisco note: in the later kernels you should use
arhontus:~# kismet -c cisco_wifix,eth1:wifi0,cisco_wifix).
This example is not accidental, because if you set cisco,wifi0,cisco in kismet.conf, you'll get an obvious error:
arhontus:~# kismet_monitor
Using /usr/local/etc/kismet.conf sources...
Enabling monitor mode for a cisco card on wifi0:
/usr/local/bin/kismet_monitor: line 136: /proc/driver/aironet/wifi0/Config: No such file or directory
/usr/local/bin/kismet_monitor: line 137: /proc/driver/aironet/wifi0/Config: No such file
or directory
/usr/local/bin/kismet_monitor: line 138: /proc/driver/aironet/wifi0/Config: No such file or directory
However, if eth1 is set in the configuration file and wifi0 is supplied with the -c switch, you should see the familiar green panel interface on your console and enjoy the wireless traffic (if there is any). Cisco Aironet drivers that come with newer Linux kernels or from the Airo-Linux Sourceforge project CVS will require a different Kismet switch. Check out the kismet.conf file that comes with your
version of the tool for an appropriate command syntax. A vast variety of wireless drivers, newer madwifi and Prism54 included, are well-supported by Kismet.
The amount of options available in Kismet is astonishing (use "h" for help). The most interesting options are probably these:
i - Detailed information about selected network l - Show wireless card power levels
d - Dump printable strings r - Packet rate graph
a - Statistics
p - Dump packet type
Figure 5-1 shows Kismet running with the dump packet type option turned on.