Kismet

---

Kismet’s capabilities and usefulness have grown significantly since its first release. It is one of the most robust open-source wireless tools available. You will also find that the web site, http://www.kismetwireless.net, also provides some excellent forums for selecting the appropriate equipment to accomplish your task. Once you delve into the wireless arena, you will realize that a good antenna (or set of antennas) and a GPS device add more quality to the data collected.

Tip 

If Kismet turns out to be more than you need on a BSD system, you can try the bsd-airtools in the security directory of the BSD Ports collection. It has an interface similar to Kismet, but it does not have all of the capabilities and data handling that Kismet offers.

Implementation

Kismet compiles on most Unix systems (including Mac OS X) and Cygwin for Windows. You can download the latest stable release from http://www.kismetwireless.net, or you can play with development releases via CVS access.

Note 

Do not be mislead by the comment that kismet will compile on Windows in the Cygwin environment. It will compile easily with the ./configure --disable-pcap option, but it will not function as a server. In other words, you will not be able to use kismet to sniff with a wireless card in a Windows system. On the other hand, you will be able to use the client functionality of a Windows-based kismet.

$ cd /usr/local/src $ cvs -d :pserver:anonymous:[e-mail]:/home/dragorn/cvs \  co kismet

Once you have downloaded the source code, follow the usual ./configure; make; make install routine. For the most part, kismet will be able to auto-detect the options and drivers available on your system. The only exception is when you wish to compile with Ethereal wiretaps, which enables binary packet capture and storage. The Ethereal source code must have already been compiled, but it is not necessary to install Ethereal. To do this, pass the following option to ./configure:

$ ./configure --with-ethereal=/path/to/ethereal/source

As a final convenience, you can install kismet with SUID root privileges using the suidinstall target to make. This means that any user can launch kismet. It also implies that any user can take advantage of kismet’s sniffing capabilities or compromise the system through a security hole in the kismet binary. This is really more a matter of choice and policy than security.

Configuring the Server and Client

Kismet has two main pieces: a server for collecting wireless data and a client for presenting the data to the user. Once the binaries have been compiled, a few steps need to be taken before kismet is ready to sniff. The kismet.conf and kismet_ui.conf files need to be configured.

Note 

Kismet can run in a third “drone” mode, which also has a kismet_drone.conf file. This mode is more useful for distributed systems in which administrators wish to monitor particular areas. Drones are merely collection points for data, much like servers.

By default, the configuration files are located in the /usr/local/etc directory. Table 17-2 shows some important lines of the kismet.conf file (the file used by the server).

Table 17-2: /usr/local/etc/kismet.conf Options That Should Be Modified

Name	Value	Description
version	3.0.1c	Tracks the version for which the configuration file was initially built. Make sure that this is close, if not an exact match, to the version of the binary that you use.If you notice that the configuration files have not changed even though you have installed a newer version of kismet, use the forceinstall target when issuing the make command. Beware that this will overwrite previous configuration files.
servername	Kismet	A mnemonic for keeping track of servers. Change this to whatever you want.
suiduser	your_user_here	This must be a nonroot user defined on your system. Kismet starts with root privileges to set the wireless cards in monitor mode but then drops to nonroot status while it collects data. Depending on your personal paranoia, this is either a must-have-security-defense or a convenient option.
source	cisco,eth0, ciscosource	This defines the driver, card name, and descriptive name for the wireless card. The drive must match a supported card (there are many!), and the card name must match the interface defined on your system (such as eth0 or wlan0). It is possible to define multiple sources, all of which can be used by the server.

If you have changed these options, you can immediately start sniffing with kismet. If you chose the route of a suidinstall, type kismet and everything will start correctly. Otherwise, you will have to perform two steps.

# kismet_server # su – user $ kismet_client

It is best if you switch user (su command) from root to the suiduser defined in the kismet.conf file.

Tweaking the Server and Client

As long as you specify the suiduser and source options in the kismet.conf file you can launch kismet as a single, host-based wireless sniffer. If you want to delve into more advanced capabilities, you’ll need to modify other values and install additional software, as shown in Table 17-3.

Table 17-3: More kismet.conf Settings

Name	Value	Description
tcpport	2501	The socket on which the server listens for client connections.
allowedhosts	127.0.0.1	IP addresses or networks in CIDR notation (e.g. 10.0.1.0/24) that are permitted to connect to the server. This has no effect on what hosts are sniffed from the wireless network.
maxclients	5	The maximum number of remote clients that may connect to the server.
gps	true	Enable or disable if a GPS device is present.
gpshost	localhost:2947	Most GPS devices connect to the computer via a serial or USB cable. The software used to read data from the device opens a socket so that other applications can access the data. The most popular package, gpsd, listens on this port by default. Normally, it doesn't make sense to specify a host other than localhost.
gpsmodelock	false	Set to true only if you are having trouble with GPS data capture.
enablesources	prismsource	If you create multiple source definitions, you should explicitly enable them with this option.
sourcechannels	prismsource:1,6	This option presents a unique method of distributing scan duties among multiple cards. For example, it is possible to have multiple USB and PCMCIA wireless cards attached to a single laptop. If you had two cards, you could set one to monitor all channels and the other to monitor only channel 6 (possibly the most used channel): sourcechannels=prism1:1,11,2,7,3,8, 4,9,5,10sourcechannels=prism2:6
alert	NETSTUMBLER, 5/min,2	Kismet generates an alert for 10 predefined types of traffic. These relate to specific probes and packets sent by tools such as Wellenreiter, NetStumbler, and Airjack. Typically, they represent malicious activity on the wireless network.
logtemplate	%n-%d-%i.%l	The logtemplate can specify paths and filenames. You may find it useful to create a directory hierarchy based on date (%d) or log type (%l). The only drawback to this method is that the directory must exist before kismet starts; otherwise it will not save the file.

It is possible to have the server play sounds or use speech when networks are detected, but it makes more sense to set these options in the client configuration file, kismet_ui.conf. The configuration directives in Table 17-4 are not essential to kismet’s operation, but they provide battery information and enable various audio cues when networks are discovered.

Table 17-4: Important kismet_ui.conf Settings

Name	Value	Description
apm	true	Display remaining battery charge.
sound	true	Play a sound for specific events: new network, traffic, junk traffic, GPS locked, GPS lost, and alert.
soundplay	/usr/bin/play	The path to the application that plays .wav files.
speech	false	Use the Festival text-to-speech engine to report discovered networks.
festival	/usr/bin/festival	You will need to download and compile the Festival speech engine. This option defines the location of the binary. See http://www.cstr.ed.ac.uk/projects/festival/.

Kismet Commands

Kismet provides helpful instructions from the client. Press h to access the Help menu. Press x to close any pop-up window, including the Help menu. To use any of the commands to view information about an SSID or list its associated clients, you must take kismet out of auto-sort mode. Do this with the s command followed by the type of sort to use, such as f for first seen. When you want to view more details about a network, use the arrow keys to highlight the desired SSID, and press i for information. An example of captured wireless traffic is shown in Figure 17-5. Notice that this will tell you whether the SSID is cloaked (not being broadcast by the access point), the MAC address of the device, traffic rate, use of WEP, channel, and GPS information if available.

Figure 17-5: Linux kismet_client

Press c to view the clients of a particular SSID. This shows another auto-sorted list of MAC addresses and related information. Take this out of auto-sort mode (press s and then f), and then highlight a client and press i to display more information. Figure 17-6 shows an example of a Cygwin kismet client. You might notice, however, that the information does not appear reliable. The MAC address is incomplete and no IP address is associated with the client. This tends to happen for weaker signals. Wireless networks do not have the fidelity of wired networks, so expect to capture noise and bad data.

Figure 17-6: Cygwin kismet_client

To view detailed information about a wireless network or a particular wireless client, highlight the SSID or MAC address and press i. Figure 17-7 shows an example of the information available for wireless networks. The information regarding the wireless network represents the configuration settings of the network’s base station. Figure 17-8 shows an example of the information available for a client that is using the wireless network. A wireless client is any device whose network traffic uses the wireless network. Thus, kismet will observe "wired" clients (clients that do not have a wireless network card) if they communicate with wireless clients or the base station.

Figure 17-7: Press i on a highlighted SSID to view information

Expanding Kismet’s Capabilities

Mobile auditing counts as one of kismet’s best points. It has two capabilities that support users who want to do some walking, biking, or driving to discover a wireless presence. The first capability falls under the category of “user-friendly”—sound and speech. The second capability, GPS data collection, has more utility for auditing networks.

Speech and sound are useful for discreet auditing because you can place a laptop or handheld device in a backpack, purse, or jacket pocket and monitor activity through an earpiece. Audio clues also aid wardrivers; they provide feedback when it is more important to drive than to read the laptop screen. Thus, a speech engine makes the effort truly hands-free. The festival engine is available from http://www.cstr.ed.ac.uk/projects/festival/. The readme and install files provide all of the information necessary to get things started.

Figure 17-8: Press i on a highlighted SSID to view information

Using GPS with kismet lets you add spatial information to the wireless network. This is especially important when you want to identify how far your wireless network propagates outside a building or even between floors of a building. Kismet does not include software to collect data from a GPS device; a different tool handles this job: GpsDrive. The comprehensive GpsDrive application, available at http://gpsdrive.kraftvoll.at/index.shtml, contains more than you will need for just using kismet. At its core, GpsDrive uses a daemon named gpsd to collect data from a serial port connection to a GPS device. Refer to Table 17-5 for some command-line options to get gpsd up and running.

Tip 

Compiling GpsDrive requires the usual triumvirate of ./configure; make; make install. The only drawback is that a complete GTK development environment must be available. This may necessitate the installation of a half-dozen or so RedHat Package Managers (RPMs). Nevertheless, the process is simple once the environment is set up correctly.

Table 17-5: gpsd Command-Line Options

Option	Description
-D	Debug level. Specify a digit.
-S	Port number. This is the TCP port number on which gpsd opens a listener. Do no confuse this with a “listening port” for the actual GPS device.
-p	Unix path that represents the GPS device. Provide the full pathname to the serial or USB connection with the GPS device. You can use a serial-to-USB cable converter to use a GPS with some handhelds or laptops without a serial port.
-s	Baud rate. The rate at which data are transferred between the GPS device and the computer. The most common rate is 9600, but you may specify different rates. If you do, remember to check the rate at which your GPS sends data through its adapter! Increasing this will not necessarily gain you more accurate data. Many devices only update coordinates once or twice a second.
-K	A special keep-alive flag that can be necessary on some Linux/USB combinations. It does not require additional values.

Case Study: WEP Insecurities

Wireless networks are not relegated to business offices and corporate networks. They can also pop up in residential areas, airports, and large retail establishments. Finding the presence of a wireless network does not necessarily have a security implication, but being able to view data does. In May 2002, an anonymous hacker reported finding wireless networks in several large department stores such as Best Buy, Wal-Mart, and Home Depot. Although it isn't clear whether credit card information was being transmitted unencrypted, this case does drive home the point that someone sitting in the parking lot could collect quite a few credit card numbers in a single day.

Even if the traffic is encrypted, WEP implementations are vulnerable to active and passive attacks that enable a third party to identity the WEP key by analyzing packets. Thus, it is not sufficient to rely only on WEP for data security. Vendors may claim that their WEP security is based on 40- or 64-bit encryption, but the truth here is slightly muddled. The secret key in both of these cases is a 40-bit value. The next 24 bits (which make up the 64-bit key) are part of the initialization vector (IV) that changes for each packet. Researchers from AT&T Labs and Rice University (http://www.cs.rice.edu/~astubble/wep/wep_attack.html) discovered a method for breaking the IV generation scheme and discerning the WEP key based on passive monitoring of 5–6 million packets. At first, this number may appear large, but a partially loaded network easily generates this many packets in a few hours. University of Maryland researchers (http://www.cs.umd.edu/~waa/wireless.pdf) identified a similar weakness in WEP and vendor implementations.

WPA, now available on Windows XP systems, and the 802.11i protocol provide significant improvements over WEP. Additionally, many vendors have upgraded their firmware to silently squash any of the “weak” initialization vectors from being used by the card. So, while WEP should be a concern when installing a wireless network, its weaknesses should not be a detractor for most implementations. Combining wireless network access with a VPN or other encryption layer addresses most security concerns.

---