Previous Section  < Day Day Up >  Next Section

Monitor Mode Network Discovery and Traffic Analysis Tools

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 graphics/ccc.gif --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 graphics/ccc.gif or directory /usr/local/bin/kismet_monitor: line 137: /proc/driver/aironet/wifi0/Config: No such file graphics/ccc.gif or directory /usr/local/bin/kismet_monitor: line 138: /proc/driver/aironet/wifi0/Config: No such file graphics/ccc.gif 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.

Figure 5.1. Kismet ncurses utility.

graphics/05fig01.gif


Familiarize yourself with the Kismet interface. It has a variety of useful information messages including warning about the factory default access point configuration (F, colored red), probe requests from lost or misconfigured clients (P, Netstumbler probe requests are flagged as N, not P), and discovering data-only networks without any management traffic (D, usually non-802.11-compliant microwave links operating in ISM/UNII bands such as Orinoco Lynx T1/E1 or Mmwaves SDH/SONET radios). When supplied with a correct WEP key in hex (see kismet.conf), Kismet can decrypt the packets on the fly. As the IP addresses of participating networks are discovered, Kismet reports which protocol was employed to discover the IP (Address Resolution Protocol [ARP], Transmission Control Protocol [TCP], User Datagram Protocol [UDP], Dynamic Host Configuration Protocol [DHCP]). The format in which Kismet dumps log files is very convenient for analysis: The packets are stored in a pcap file format (hint: use Ethereal to open them) and the listing of found networks is stored in ASCII, .cvs, and .xml formats. GPS waypoints and information on Cisco devices running Cisco Discovery Protocol (CDP) is also stored in separate ASCII files. The format of networks reported by Kismet is as follows:






Network 1: "TheMatrixHasYou" BSSID: "00:02:2D:8E:74:5E"

    Type     : infrastructure

    Carrier  : 802.11b

    Info     : "None"

    Channel  : 11

    WEP      : "Yes"

    Maxrate  : 11.0

    LLC      : 6262

    Data     : 1303

    Crypt    : 1303

    Weak     : 0

    Total    : 7565

    First    : "Tue May 20 16:42:37 2003"

    Last     : "Tue May 20 16:58:41 2003"


If you want to produce a nice .html output file of Kismet logs for your Web page, Kismet Log Viewer (KLV; http://www.mindflip.org/klv/) is useful. KLV takes Kismet .xml log files and outputs a structured formatted HTML interface to browse the logs with. It also enables Snort users to generate a page of Snort output for each specific ESSID that has logged data. Besides, KLV comes with the Kismet Log Combiner script to help users merge together multiple .xml and .dump log files.

The absence of a default GUI is a great advantage in Kismet, as you don't have to run X, which saves time and battery power. There is actually a GUI for Kismet called Wirekismet, which has been developed for handhelds and runs on laptops if needed. Wirekismet has extended functionality, including putting the client card into the RFMON and Infrastructure modes, connecting to the discovered networks, turning on a DHCP client, choosing a Kismet server to connect to from the list, and so on. Another excellent GUI for Kismet, which also acts as a server–client configuration tool, is kismet_qte for Trolltech's QT environment (http://sourceforge.net/projects/kismet-qte/; Figure 5-3). Finally, for the laptop environment, Gkismet (http://gkismet.sourceforge.net/) is probably the best GUI available; see Figure 5-2 and also check out the screen shots at the Sourceforge site.

Figure 5.3. Kismet_qte front end to kismet on Trolltech's QT environment.

graphics/05fig03.jpg


Figure 5.2. Gkismet, a graphical interface to Kismet.

graphics/05fig02.jpg


Because PDAs have a good battery life compared to laptops and notebooks, using a GUI for Kismet on a handheld is a power-affordable method and provides a good way to demonstrate to "nongeeks" (e.g., management) the peculiarities and insecurities of wireless networking.

Kismet and GpsDrive Integration

Sometimes it is nice to revisit an access point that was found during a wardriving tour. However, in a busy city you might find hundreds of access points within a short period of time. How do we find a particular one from the whole list of access points recorded during the trip? For this task it is best to use a GPS device connected to a laptop to track the exact position when the access point is spotted. It is also advisable to implement a tool that will place the locations of wireless networks on the map. GpsDrive can be tweaked to do this without much effort. Gpsmap, a tool packaged with Kismet, is another excellent utility that we find very useful to graphically represent a Kismet wardriving session or client site survey. The setup of Kismet, GpsDrive, and Gpsmap is detailed in this section.

For our wardriving explorations we use a Haicom GPS Receiver HI-204E, a quite efficient, yet very inconspicuous magnetically mounted GPS device that can be bought at http://www.cheeplinux.co.uk. To make it work, simply place the device on the car roof, connect it to a USB port in your laptop, modprobe pl2303 module, run gpsd -K -p /dev/ttyUSB0 or other relevant device name, and finally run Kismet. Kismet records the positions of found wireless networks in a file named something like Kismet-XXX.gps. The first task is done: We can record the latitude and longitude positions of the networks so that they can be easily revisited at will.

What if we want to plot WLAN coordinates on the map? Let's use two well-known open source tools called GpsDrive and Gpsmap. Gpsmap uses Kismet-generated GPS output to download the map of the area from the Internet and plot access point positions on the map. This tool is highly flexible and can also generate an interpolated network power, estimated network range, and many other useful features that will brighten up your map, as shown in Figure 5-4.

Figure 5.4. Gpsmap-generated output.

graphics/05fig04.gif


GpsDrive is yet another useful utility for GPS navigation that a war-driver can use. For simplicity reasons, we only describe Kismet-related features of GpsDrive. If you want to learn more about this tool, visit its project page at http://gpsdrive.kraftvoll.at, where you can find a lot of information about Linux and GPS setups. To integrate GpsDrive and Kismet you need a MYSQL server containing database table entries ready for the output from GpsDrive. Before launching GpsDrive, make sure the following procedures have been done:

  • Install MySQL server. Add database and GpsDrive user.

  • Edit GpsDrive configuration file, usually found in ~/.gpsdrive/gpsdriverc, to represent mysql settings.

  • First launch gpsd, then Kismet, and finally GpsDrive.

If all goes well, you should see a small Kismet logo in the bottom left corner of the screen. If you have difficulties with these procedures, consult the README.SQL and README.kismet files, located in the source directory of the GpsDrive tool. The GpsDrive and Kismet integration should look like Figure 5-5.

Figure 5.5. GpsDrive integration with Kismet.

graphics/05fig05.jpg


Once you get comfortable with these tools, you can easily revisit any of the found networks by following previous wardriving tracks and simply setting the required network as the destination point in the GpsDrive or any other GPS navigation system.

Wellenreiter

If you want a very easy-to-use graphical wireless sniffer, look no further. Sparing the obvious pcmcia-cs, libpcap, and tcpdump, you'll need to install Gtk-Perl (http://www.gtkperl.org/download.html) and the Net-Pcap Perl module (http://earch.cpan.org/search?mode=module&query=net%3A%3Apcap) to run Wellenreiter (http://www.wellenreiter.net/). Then you simply launch the tool with the perl Wellenreiter.pl command. No configuration is required for Prism (wlan-ng driver), HostAP, Cisco Aironet (Sourceforge airo-linux driver), or Hermes chipset (orinoco_cs driver) cards. Scanning with Wellenreiter is straightforward and you can toggle traffic and log windows to watch flying packets and happening events in real time (Figure 5-6).

Figure 5.6. Wellenreiter utility.

graphics/05fig06.jpg


Additionally, you can configure the event sounds. Wellenreiter dumps logged data into the running user home directory in the form of two files: a tcpdump file ending in .dump and an ASCII network parameters list file ending in .save.

Airtraf

Airtraf is an intuitive wireless network discovery and traffic and bandwidth consumption statistics monitoring tool for console users. It is easy to install: Check that you have libncurses library installed, untar the tool, and do the usual make all && make install. Then run airtraf -l to see if airtraf recognizes your wireless interfaces:






arhontus:~# airtraf -l

You have (2) wireless devices configured in your system

Found eth1: IEEE 802.11-DS on IRQ: 3, BaseAddr: 0x0100 Status: UP

   Using Driver: (airo_cs)

Filename:/lib/modules/2.4.20/kernel/drivers/net/wireless/airo_cs.o

   Author: "Benjamin Reed"

success: above driver's compatibility verified!

Found wifi0: IEEE 802.11-DS on IRQ: 3, BaseAddr: 0x0100 Status: UP

   Using Driver: (airo_cs)

Filename:/lib/modules/2.4.20/kernel/drivers/net/wireless/airo_cs.o

   Author: "Benjamin Reed"

success: above driver's compatibility verified!


Then use these parameters to run airtraf, or just launch the tool to answer a question about the RFMON mode and it will run. Airtraf supports Prism, Cisco Aironet, and Hermes chipset cards. If you use a Cisco Aironet card you'll have to set the interface manually, because by default airtraf would set the interface to ethX and not wifiX:






arhontus:~# airtraf -I wifi0 -C aironet


Otherwise you can simply launch airtraf and it will put your card into the RFMON mode when you tell it to. In case you want to put the card into the monitor mode without knowing the proper commands to do so, use kismet_monitor script or airtraf itself (simple monitor and unmonitor shell scripts are included in airtraf/src/scripts).

Airtraf has a feature-rich menu (Figure 5-7) that lets users scan for access points in the area (Scan Channels for AP activity option), then press Esc to enter the main menu, focus on the selected access point, and monitor its activity.

Figure 5.7. Airtraf wireless network discovery tool.

graphics/05fig07.gif


Two unique airtraf menus are General Protocols Statistics (Figure 5-8) and TCP Performance Statistics. The General Protocols Statistics interface breaks down the wireless bandwidth usage by various protocols, whereas TCP Performance Statistics shows TCP connections for the chosen host on a WLAN as well as all wireless hosts available and the amount of retransmitted packets, bytes, and wasted bandwidth on the network.

Figure 5.8. Airtraf General Protocols Statistics menu.

graphics/05fig08.jpg


You can run airtraf in a daemon mode. Obviously, you can dump the traffic statistics into a file, but this file can be viewed by airtraf only. You can easily replay the traffic when viewing the statistics dump. The main disadvantage of airtraf is that you cannot enter the WEP key and decrypt or monitor wireless traffic in real time. This is the reason you cannot see any higher layer traffic on the provided screen shots.

Gtkskan

Gtkskan (http://sourceforge.net/projects/wavelan-tools/) is a simple WLAN scanner for Hermes chipset cards running a Shmoo-patched orinoco_cs driver. In our experience it can also work with Prism cards and linux-wlan-ng; just set an appropriate interface (e.g., wlan0). Gtkskan is easy and straightforward to use (Figure 5-9) and supports NMEA GPS devices.

Figure 5.9. Gtkskan.

graphics/05fig09.gif


You need berkeley db (http://www.sleepycat.com) to compile and run gtkskan. It should be version 1.85, otherwise run ./configure 2.x/3.x with the --enable-compat185 flag. Gtkskan does not support Cisco Aironet cards but can be modified to do so.

Airfart

The tool creators said, "Following suit with the major players in the wireless arena, we decided the 'air' prefix best categorizes airfart. Further, re-arrange the letters in 'traf' and you can get 'fart.' So, our mission is to sniff out wireless devices who broadcast a 'scent'." Airfart is another GTK+ front-end tool for WLAN discovery written in C/C++. Airfart supports Prism chipset cards run with linux-wlan-ng only. Its distinguishing feature is using the Prism headers that we have discussed (ARPHRD_IEEE80211_PRISM) to monitor signal strength on the discovered 802.11 LANs. For cards with the newer Prism3 chipset, linux-wlan-ng drivers do not present the signal strength values correctly. If you have such a card (e.g., Linksys WPC11 v3.0), then the signal strengths will be smaller in the Airfart display than they really are. Multiply the Airfart values by about 2.5 to get the real signal strength. Figure 5-10 demonstrates Airfart in action.

Figure 5.10. Airfart tool.

graphics/05fig10.gif


Here and in some other cases we took an example screen shot from the tool's Web site (http://airfart.sourceforge.net/ in Airfart's case) because our screen shot would be rather boring. Only three 802.11b networks in the testing lab, and one of them (with the closed ESSID) was not detected by the Airfart.

Mognet

If you like Java then you will like Mognet, as it is a compact wireless sniffer written purely in Java with handhelds in mind. To install Mognet (http://www.node99.org/projects/mognet/) you need a Java Development Kit (JDK), which is necessary to compile the jpcap library that comes with it. You can get the latest version of JDK from http://www.sun.com or http://www.blackdown.org. Check that JAVA_HOME in the install.sh script points correctly to your Java directory. After jpcap is compiled, you can run Mognet with either JDK or Java Runtime Environment (JRE): java Mognet <interface>. Alternatively, you can run Mognet in the console to dump wireless traffic:






arhontus:~# java ConsoleCapture wlan0

opening device wlan0

wrote frame 82


The frames are dumped into a pcap format log file (mognet-<timestamp>.log file) in the Mognet directory. Unlike Wellenreiter, Mognet does not put your wireless interface into the monitor mode automatically; you have to do it manually before launching the tool. On the other hand, all common 802.11 client cards chipsets are supported. Figure 5-11 shows Mognet at work.

Figure 5.11. Mognet in action.

graphics/05fig11.gif


Its features include real-time capture output; support for all 802.11 generic and frame-specific headers; raw hex, and ASCII views for any frame; and loading and saving capture sessions in the libpcap format. Thus, on a PDA without an installed Ethereal, Mognet can be priceless. Please note that Sharp Zaurus has a JeodeRuntime Java environment installed by default, thus making installation and use of Mognet on these PDAs an easier task. Known issues with using Mognet include confusing IPP broadcasts with 802.11b frames, although it is actually an older libpcap versions bug. In our experience, Mognet might confuse ESSID-less beacon frames on a closed network with association request frames.

WifiScanner

WifiScanner is a console tool to find 802.11 LANs (using Prism chipset cards running under linux-wlan-ng) and dump wireless traffic while creating lists of discovered access points or ad-hoc cells:





arhontus:~# ./WifiScanner -h WifiScanner v0.8.0 (Wlan driver version >= 0.14) (c) 2002 Herv? Schauer Consultants graphics/ccc.gif(Jerome.Poggi@hsc-labs.com) Call with no parameters or with the following options -F FileName - Save output to a file as well as stdout -H Hop - Number of hops do for rotating channel (default 1) -S Channel - Only listen on a specific Channel (1-14) -V - Write Version and quit -W FileName - Save sniffed data to a file in PCAP format -D FileName - Create a file of detected devices, in a .dot format -d - Write date in human readable format -i number - Number of the interface wlan0 = 0 (default 0) -M number - Max packets to capture before exit (0 = unlimited) -N abcd - Do not display Ack, Beacon, Control, Data -v level - For verbose, level 2 is debugging

A sample WifiScanner screenshot is shown in Figure 5-12. Please note that the tool can also show the strength of the received signal, presumably via reading the Prism headers (check out the source code).

Figure 5.12. WifiScanner console tool.

graphics/05fig12.gif


The data on a screenshot is read in the following way:






Column 1 : Time since 1 January 1970 (or readable date if -d option is set)

Column 2 : ESSID

Column 3 : Channel. When is 0, it means that it's unknown

Column 4 : STA or AP : Client Station or Access Point

Column 5 : Strength of Signal

Column 6 : Strength of noise (if it known)

Column 7 : Packet Destination Address (FF:FF:FF:FF:FF:FF is broadcast)

Column 8 : Packet Source Address

Column 9 : BSSID

Column 10: Data Rate (1, 2, 5.5 or 11Mbit/s)

Column 11: Type of client

   Client : it's a client (in usual management or control data)

   AP Base: it's an AP

   AP Base (STA in master mode) : It's a card in Master mode

   AP Base (dedicated)          : It's a dedicated AP

   Ad-Hoc STA                  : It's an Ad-Hoc client

   STA Activity                 : It's a client emitting some Data

Column 12: Type of radio transmission

   Radio only

   Data To DS

   Data From DS

   Data AP to AP


To compile WifiScanner from source you will need some object code from linux-wlan-ng, so compile your Prism drivers and utilities without execution of the make clean command. You will also need a source code of Ethereal and a manual compilation of Ethereal wtap library. Of course, ncurses are needed, too. If you don't want to compile WifiScanner or your compilation fails, precompiled binaries are available from the http://sourceforge.net/projects/wifiscanner/ site. To run WifiScanner, a wide (minimum of 132 columns and 50 rows) terminal is needed; maximized xterm did the job for us.

Miscellaneous Command–Line Scripts and Utilities

By the time the major wireless discovery and protocol analysis tools, such as Kismet or Wellenreiter, came to the market, a great variety of simpler command line tools for wardriving already existed and were widely used. The majority of these tools are custom hacks by enthusiastic individuals aimed at discovering wireless networks using the client cards at hand.

A group of such tools was based on a Prismdump, a utility to dump 802.11 frames to a pcap format file. Such tools included Prismsnort, which was a combination of Prismdump with an early version of the Airsnort, and Prismstumbler, which has been described as Prismdump on steroids with added GPS (via gpsd) support and a GTK GUI. These tools are no longer supported and rely on the historic PF_NETLINK interface. At the same time, all modern 802.11 protocol analyzers have switched to using the PF_PACKET interface and the current libpcap library supports the 802.11 frame format just fine. Thus, Prismdump-based tools are on the obsolete side. Nevertheless, we have included them in the book for historical and educational (in terms of software development) reasons.

You might have difficulties compiling Prismdump-based tools against the wtap library included with the current version of Ethereal. Wtap is used by Prismdump to dump its log files:






dump_file = wtap_dump_fdopen (fileno(stdout), WTAP_FILE_PCAP,

     WTAP_ENCAP_IEEE_802_11, 2344, &wtap_error);

<snip>

/* Now we can save the frame to the capture file */

wtap_dump (dump_file, &packet_hdr_info, NULL, &msgbuf[oi], & wtap_error);


Please note that if you use Prismdump with your linux-wlan-ng driver and libpcap supports PF_PACKET, the tool will enter an infinite loop that you can't stop with Ctrl+C (but kill -9 helps).

Both PF_NETLINK and PF_PACKET are kernel interfaces that provide means for passing data via sockets from the kernel space to user space. PF_PACKET supplies additional means for packets to be passed to end-user programs, such as the wireless protocol analyzers we discussed. This interface is used by the libpcap library and all tools that rely on it. Since the transition to PF_PACKET, tcpdump (and Ethereal) can be used to capture live 802.11 traffic in real time. We don't review tcpdump and Ethereal in this chapter, as they are not specifically designed as wireless sniffers. However, you should always keep these tools in mind and get good hands-on practice using them in wireless protocol analysis. The powerful features of Ethereal (Figure 5-13) make the analysis of 802.11 traffic, for those familiar with the protocols, an easy and entertaining task.

Figure 5.13. Ethereal network protocol analyzer.

graphics/05fig13.jpg


You can filter the beacon frames, replay TCP sessions that took place over the wireless link, sort the packets by protocols or timestamps, and so on. Please note that the beacon frame shown in the screenshot of Ethereal is reported as a "malformed packet." In fact, there is nothing wrong with that beacon, but the Ethereal decoding engine is confused by a lack of ESSID in it (closed network). Several examples of using Ethereal to flag out interesting 802.11 traffic are given in Chapter 15.

Apart from the Prismdump-based tools we have described, a variety of useful scripts and utilities exist and deserve mentioning. They work with the current libpcap library and can often utilize non-Prism chipset cards. For example, Ssidsniff (http://www.bastard.net/~kos/wifi/) allows access point discovery with Prism or Cisco Aironet chipset cards and traffic logging in a pcap format traffic:






arhontus:~# ./ssidsniff -h

./ssidsniff: invalid option -- h

Usage: ./ssidsniff <options>

   -i <device> Set the device to listen on

   -s <snaplen> pcap maximum snarfed length

   -f <filter> pcap filter to use

   -c <maxcount> Set maximum packets to read, then exit

   -m <mode> Set mode of operation:

    live: Use live network device and capture beacons.

    Use <CR> to get current list. Default.

    file: Open libpcap file and run through it; print all beacons.

    acquire: Use live network device and dump out all beacons

    received in machine parseable format.

   -g Geiger counter mode. Beep for every packet received.

   -w <file> tcpdump capture file for everything received

   -W   When capturing to file, only save 802.3 portion

   -r <file> tcpdump capture file to read packets from

   -l <runlog> Text file to keep findings. - is stdout.

   -L   When capturing to text file, use machine parseable format

   -v <verbosity> The higher, the noisier

   -V version number



arhontus:~# ./ssidsniff -i wlan0 -g -v 2

./ssidsniff: datalink type 113 isn't 802.11 (105), continuing anyway

./ssidsniff: geiger mode on: EsounD sound module

./ssidsniff: Starting sniffing with filter= on wlan0

 6 total, 3 beacons, 2 plaintext, 0 wep, 1 martians


The "martians" in the output refers to unknown format frames (e.g., frames corrupted by RF noise) and not green men bearing head-mounted, low-gain omnidirectional antennas. The geiger mode lets you sense when more frames are passing using your ears and might be helpful in trying to find out where the source of these frames could be.

Another utility to sniff a channel in the RFMON mode, using Prism II chipset cards only, is Scanchan from http://www.elixar.net/wireless/download/download.html. Scanchan is used by airtraf, which we have already described. For an easy-to-use command-line utility for Hermes chipset cards, try Wavestumbler:






arhontus:~# ./wavestumbler --help

   WaveStumbler v1.2.0 by Patrik Karlsson <patrik@cqure.net>

   ---------------------------------------------------------

   usage: ./wavestumbler [options]

   -i*   <interface>

   -d*   <delay in ms> (should be greater than 100)

   -r    <reportfile>

   -m    reduce shown information to minimum

   -v    be verbose (show debug info)


Wavestumbler, by default, tries to write into the /proc/hermes/eth1/cmds file and you might need to modify the tool if the corresponding file is not there (find /proc/ -name*hermes* helps). Another scanning utility for Hermes chipset cards is wlan-scan, which unfortunately comes as a precompiled binary:






arhontus:~# ./scan -h

Usage: ./scan <1|2> [<essid [rate]>|<auto>|<-{profile}>]

arhontus:~# ./scan 2

ESSID   AgentSmith

 Link   52/92 (56%)

 Speed  2Mb

 My HW  00:90:4B:06:15:4F ()

 AP HW  00:02:2D:4E:EA:0D   ()


Apart from the scan utility, wlan-scan also has a file with an OUI-to-manufacturer list and arpq parsing utility that might come in handy:






arhontus:~# ./arpq 00:00:39:BA:33:86

00:00:39:ba:33:86=Intel


Yet another utility and collection of scripts for command-line wardriving utilizing a Hermes chipset card is called Wardrive that comes from van Hauser of the The Hackers Choice (http://www.thehackerschoice.com). Wardrive was one of the very first wardriving tools to support GPS devices and sound signals on network discovery. Edit the wardrive.conf file and the shell scripts included to suit your system settings (wireless interface, GPS serial port, etc.). The sniff_wvlan.sh script runs tcpdump and Dug Song's Dsniff on the selected wireless interface:






#!/bin/sh

test -z "$DEV" && DEV="$DEVICE"

test -z "$DEV" && DEV=eth0

dsniff=dsniff.$$.sniff

tcpd=tcpdump.$$.sniff

dsniff -i $DEV -n -m -s 2500 > $dsniff &

tcpdump -l -i $DEV -n -s 2500 -w $tcpd ip or arp &


Ensure that you have these tools installed and they can be found in the $PATH.

The syntax of the Wardrive utility itself can be confusing:






arhontus:~# ./wardrive --help

Wardrive v2.1 by van Hauser / THC <vh@reptile.rug.ac.be>

Syntax: ./wardrive [-p serport] [-d interface] [-o file] [-I script]

        [-i interval] [-l level] [-b level] [-B interval] [-G] [-v]

Options:

  -d interface  wavelan interface. [eth0]

  -p serport    seriell port the GPS device (NMEA) is connected to. [/dev/ttyS1]

  -o file       output file to append the data to. [./wardrive.stat]

  -I script     script to run initially to configure the wvlan card []

  -R script     script to reset wvlan card after node was found [reset_wvlan.sh]

  -W            print access point hwaddr and SSID via "iwconfig" [false]

  -i interval   interval to write GPS+wavelan data in seconds, 0 =  amap. [1]

  -l level      only save data with >= this link level, 0 = all. [1]

  -b level      beep if >= this link level, 0 = disable. [5]

  -B interval   wait time in seconds before beeping again. [5]

  -G            ignore errors from GPS, dont exit. [false]

  -v            be verbose. [false]


However, running the scan via start_wardrive is easy once everything is configured:





arhontus:~# ./start_wardrive eth1 enable roaming Wardrive: GPS could not be configured, disabled support and still running ... Starting logging, saving to ./wardrive.stat; press Control-C to end logging ... 2003-05-21 20:09:12 00:00:00.0000? 00:00:00.0000? 0 0 188 134 0 4635 0 tcpdump: WARNING: eth1: no IPv4 address assigned tcpdump: listening on eth1 dsniff: listening on eth1 2003-05-21 20:09:13 00:00:00.0000? 00:00:00.0000? 0 56 214 114 0 4638 0 2003-05-21 20:09:13 00:00:00.0000? 00:00:00.0000? WINFO - SSID:"foobar net" Access Point: graphics/ccc.gif 00:02:2D:4E:EA:0D 2003-05-21 20:09:14 00:00:00.0000? 00:00:00.0000? 0 58 212 112 0 4643 0 2003-05-21 20:09:15 00:00:00.0000? 00:00:00.0000? 0 58 210 112 0 4647 0 2003-05-21 20:09:16 00:00:00.0000? 00:00:00.0000? 0 60 213 111 0 4651 0 2003-05-21 20:09:17 00:00:00.0000? 00:00:00.0000? 0 64 215 111 0 4655 0 2003-05-21 20:09:18 00:00:00.0000? 00:00:00.0000? 0 62 213 110 0 4659 0

Finally, for all you Perl lovers wanting to use (and perhaps dissect) something simpler than Wellenreiter, there is Perlskan. Perlskan uses the GPS::Garmin module (included with the tool) for interfacing with the GPS device. Thus, the GPS receiver will have to send data in GRMN/GRMN and not NMEA unless the NMEA support is implemented in the GPS::Garmin module by the time this book is released. Perlskan was written for Hermes chipset cards and is easy to compile and use:






arhontus:~# perl perlskan

Usage: perlskan <ifname> <gps tty>

arhontus:~# perl perlskan eth1

eth1: 31337++

   link    = 0

   freq    = 2422000000

   bitrate = 2000000


In the current example, Perlskan could not find our closed ESSID 802.11g LAN, which is depressing. If a Cisco Aironet card is used instead of the Hermes chipset, Perlskan still finds the access points, but shows them all as running on channel 1. This is probably because of the Aironet card's default channel 1 setting, even though the card hops automatically between channels.

BSD Tools for Wireless Network Discovery and Traffic Logging

Although Linux is our workhorse in wireless security auditing, it is important to mention several wireless security testing tools for various BSD flavors. These tools are not numerous, but they are nevertheless powerful and quite important in the overall picture of wireless security. The story of BSD wireless tool development probably began from this little Perl script:






#!/usr/bin/perl -w

#

#resets wi0 every second.

#first second we check for non-encrypted network,

#next second for encrypted network, and so on

use strict;



$|=1;



my $wicomm      = '/sbin/wicontrol';

my $resetcomm   = '/sbin/wicontrol -p1 -e0';

my $resetcomme  = '/sbin/wicontrol -p1 -e1';

my $n           = 0;



while (1) {

        print time(), "\t";

        open(WICO, "$wicomm|") or die "$wicomm Error: $!";

        while (<WICO>) {

                chomp;

              print $1,"\t" if /^Current netname \(SSID\):\s+\[(.*)\]$/;

              print $1,"\t" if /^Current BSSID:\s+\[(.*)\]$/;

              print $1,"\t" if /^Comms.*\[(.*)\]$/;

        }

        close (WICO);

        print $n%2? "Y"  : "N";

        print "\n";



        if ($n%2) { system($resetcomm); }

        else { system($resetcomme); }

        sleep 1;

        $n++;

}


This script was used by Francisco Luis Roque while warwalking and biking around Ann Arbor, Michigan, with a 486 laptop running OpenBSD and a Lucent Orinoco wireless card. The script does not put the wi0 interface into the monitor mode. Over time, a few simple BSD wireless scanning tools such as airosniff and wicontrol have surfaced and disappeared. Currently, Dachb0den Labs BSD-airtools is the main and the most well-known wireless security auditing suite for BSD systems. Dstumbler is the main network discovery tool included in the suite; we mentioned it previously when we discussed the Netstumbler's internal workings. When run in the RFMON mode, Dstumbler provides the following unique capabilities:

  • Detects if an infrastructure network uses shared or keyed authentication

  • Detects if bss nodes are set to connect to any network or a specified one

  • Partial detection of 40-bit or 104-bit WEP encryption

These features alone make Dstumbler a very valuable addition to any wireless penetration testing tools collection. Dstumbler will also report default ESSIDs, estimate beacon interval of detected access points, show hosts on infrastructure networks, and record the maximum supported bitrate on both APs and hosts.

You'll need to install BSD-airtools source-mods and recompile the BSD kernel to be able to set Prism chipset cards into the RFMON mode, unless you run OpenBSD 3.2 or later OpenBSD versions in which the monitoring mode for wi and an interfaces is supported by default. After the kernel recompilation, installing Dstumbler is easy, but remember that you'll need to run it as root. Launching Dstumbler in monitor mode is also straightforward:






arhontus:~# dstumbler wi0 -o -l allyourbase.txt


Two other relevant tools included in the BSD-airtools suite are prism2ctl and prism2dump. Prism2ctl is really an interface to the prism2 debug kernel modules provided in the BSD-airtools source-mods package. It allows you to set a Prism2 chipset card into any of the 14 various debug modes. The monitor mode is one of them. For your reference, these modes are as follows:





-r: reset device -i: initialize device -s: put device into sleep mode or wake it up arguments: 0 - wake 1 - sleep -f: switch device to specified frequency channel arguments: channel number (1-14) -d: this mode suppresses "post back-off delays" with transmitted frames, should provide graphics/ccc.gif better throughput -t: this mode makes the device suppress any errors with transmitted frames -m: enable monitor mode -l: enable led test arguments: :x - blinks the power led at a rate of x usec on and x usec off 2:x - blinks the activity led at a rate of x usec on and x usec off -c: continuously transmits the supplied 16-bit parameter arguments: 16-bit hex pattern -h: disables the following modes: delay suppression transmit error suppression monitor mode continuous transmit continuous receive set signal state -e: puts the device into a continuous receive state -g: sets the signal mask for the device (don't use this unless you know what you're doing graphics/ccc.gif and have proper documentation) -a: issues a calenable to the baseband processor -b: enables or disables automatic level control on transmit frames arguments: 0 - disable 1 - enable

To set a wi0 interface into the RFMON mode, just run prism2ctl wi0 -m.

Prism2dump is a tcpdump or its Linux cousin Prismdump-like utility for logging 802.11 traffic. To do it properly, first put your Prism2 card into monitor mode and then run prism2dump <interface> -v <verbosity level>. The levels of verbosity supported include the following:






0: only prints the 802.11 frame information

1: prints the 802.11 frame info as well as basic data/mgmt/control

   protocol info

2: prints all protocol information


You also need to run prism2dump as root.

Apart from the BSD-airtools, an interesting tool that deserves mentioning is wistumbler, originally written for NetBSD wireless network discovery. To compile wistumbler you will need gtk+-1.2.10 and glib-1.2.10nb1 or later. Wistumbler supports both wi and legacy (PrismI) awi interfaces and can communicate with NMEA-supporting GPS receivers. You can run wistumbler with a command like this:






arhontus:~# wistumbler wi0 -f wehaveyouall -g /dev/dty01 -d


where "wehaveyouall" is a logfile, /dev/dty01 is the GPS serial port, and the -d flag sets the debugging mode.

    Previous Section  < Day Day Up >  Next Section