Basic Wireless Auditing with Linux and Open Source Tools

 

 

By Todd Hughes, November 22, 2009

 

            On occasion I am called upon to perform some basic auditing of a client’s wireless network. The standard audit consists of war-walking/driving around the client’s premises to collect data on any available wireless networks and then hauling this data back to my office for a detailed analysis.

            Being a FOSS kinda guy, I utilize several open source tools and a Linux operating system. My OS preference is any Debian based distro; currently I am running Mepis 8 on my laptop. The latest BackTrack distro is an excellent choice too, as it has all the necessary tools already installed and mostly configured. While I do use BT a lot (I’ve got it installed on a bootable USB stick with a persistent partition to save changes to), I wanted to install some basic tools on my Mepis laptop so that I wouldn’t have to fire up BT every time I needed to do a quick audit.

            In order to do basic wireless testing you’re going to want a few wireless pen-testing tools installed. The best one I’ve found for discovery and data gathering is Kismet. Kismet sniffs 802.11a, b, and g traffic, identifies named wireless networks, exposes hidden networks, and captures all the packets into a dump file. It also works in conjunction with GPS to record location coordinates of any networks discovered. I need to point out that you will require the latest version of Kismet, the older versions save data in a different format that won’t work with some of the tools referenced in this article. Debian based distros that use the stable repositories (like Mepis 8) most likely will grab the older version if you do an apt-get, Ubuntu I believe will get the latest version. Best bet is just to grab the latest source code (via SVN) and build from scratch, it’s very easy to do. If you’re familiar with the older Kismet, you are going to love the newest version.

            You will also need a decent rfmon (raw monitoring) capable wireless card. It’s also nice to have a card that is capable of doing packet injection for those jobs that require you to actually attack the client network (but that is out of scope for both the standard wireless assessment and this article). I use either a Cisco Aironet card (AIR-CB21AG-A-K9) or a Ubiquiti SRC300 with an external antenna. Both of these are PCMCIA cards with the Atheros chipset, perfect for our whitehat wireless exploits. Do a bit of Googling to determine if your card supports the necessary modes.

            Next up on our requirements list is some type of GPS antenna/receiver. There are many different flavors out there, I use the Pharos GPS500 III with the USB adapter. In addition to the GPS hardware you will need some software to make it work. I recommend “gpsd” and “python-gps”, both packages available via the standard apt repositories. (As a side note, there is a lot of mapping software available to turn your laptop into a GPS device ala TomTom, Garmin, etc. Take a look at Viking, GPSDrive, Roadnav, or Navit.)

            Some other tools I use are a python script “pykismetkmlv0.42.py” available at Google Code (code.google.com) which converts the Kismet data files into a format that can be imported into Google Earth, “macchanger” (apt-get macchanger) which allows me to spoof the mac address of my wireless card (always a good idea to disguise yourself), and “thcrut”, “fing”, “nmap” or some other tool that will allow you to gather mac addresses on the client’s wired network. My favorite for this is “arp-scan” (it’s in the standard Debian repositories).

             At this point I will not be spoon feeding you a step-by-step “how-to for dummies” but rather assume that if you are doing this type of testing/auditing that you know how to handle yourself around Linux and the command line. That said, here’s my basic framework for a simple wireless audit:

             Configure Kismet to work with your wireless card and GPS receiver and make sure it will dump it’s data files somewhere that you can find them (the default /tmp/datafiles is not a good idea). Start up gpsd, verify that it’s getting a signal lock, spoof the mac address of your wireless interface, put the interface in monitor mode, start up Kismet, and then spend some time walking/driving around the target site. Better yet, write a little script that will do all of the above (below is mine, feel free to edit for your needs):

 #!/bin/bash

wlanconfig ath0 destroy

wlanconfig ath0 create wlandev wifi0 wlanmode monitor

macchanger -m 00:DE:AD:BE:EF:00 ath0

ifconfig ath0 up

gpsd -n -D 2 /dev/ttyUSB0

/usr/local/bin/kismet

             After you’ve collected a good amount of data, shut down kismet, make sure you’ve got data, and then head to the wired network to grab a list of mac addresses. I run arp-scan against the internal network and save the data to a file somewhere. Remember, arp requires that you be on the same network segment that you are arp-scanning, so if there are several subnets you will need to physically plug into each one to grab the macs.

 arp-scan -I ethn0 192.168.11.0/24 > /data/11 gets me:

root@mepis:/home/thughes# cat /data/11

“Interface: eth0, datalink type: EN10MB (Ethernet)

Starting arp-scan 1.6 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)

192.168.11.1    00:12:17:02:97:fe       Cisco-Linksys, LLC

1 packets received by filter, 0 packets dropped by kernel

Ending arp-scan 1.6: 256 hosts scanned in 1.385 seconds (184.84 hosts/sec).  1 responded”

            I suppose you may be wondering why I bother with the arp scan stuff? Comparing a list of mac addresses gathered on the wired network against the mac addresses of all the wireless access points and clients can sometimes aid in determining if there are any “rouge” access points on the network.

            Now that you have all the data, you need to analyze it and present a report to the client. I use wireshark to dig through the pcap dump and look for any sensitive info (passwords, usernames, etc.). Using the python script mentioned earlier, a .kml file can be created and imported into Google Earth to create some nice images to include in your report (like this):

Wireless Networks

            That’s about all there is to your basic wireless audit/assessment. Your report should probably include things like a list of all wireless networks found and whether they could be associated with the client’s network, signal strengths, what type (if any) encryption each network uses, a list of all clients discovered and which networks they were associated with, whether any sensitive data associated with the client’s network was captured, a map or diagram of the wireless networks discovered, and anything else you might feel relevant.

            As always, if you have any questions, comments, complaints, or would like to contribute to my beer fund, feel free to contact me at thughes@fwpm.com

Copyright 2009 Todd Hughes

Leave a Comment