- War Driving 101
Getting Started
In order to follow this tutorial, you must have either a working LiveCD/USB disto of Linux or a bootable distro on your hard drive. I am using Ubuntu 10.04LTS for this tutorial and it is tailored as such. If your distro is different, modify your commands appropriately (ie, yum/RPM instead of aptitude).
You will need to install both the Aircrack-ng and Kismet packages, available from your standard repository. Fire up a terminal and type the following commands. Enter “Yes” to any questions you may receive.
sudo apt-get install aircrack-ng
sudo apt-get install Kismet
After installing, migrate to your /etc/kismet directory…
cd /etc/kismet/
Kismet is designed with a simple client/server architecture. While most users will run both the client and server on the same machine and will use Kismet as a local application, you can also run Kismet clients on your remote systems. This way, one or more remote machines can see real-time data from the machine hosting the Kismet server. This opens up doors to many possibilities!
Before you can run Kismet for the first time, you will need to fire up your favorite text editor and modify the primary configuration file, kismet.conf. I prefer nano, which is reflected here.
sudo nano kismet.conf
Inside, you will find the line:
suiduser=your_username_here
The conventional wisdom is that you should set the above variable to the local user under which you’ll execute Kismet. My experience in Ubuntu 10.04LTS, while using the Kismet package provided by Ubuntu, was that I could only run Kismet successfully as the root user. All of my attempts to run as a standard user failed, and quickly aborted due to fatal errors. This may vary on other platforms but just keep it in mind.
You will also need to tell Kismet which “source,” or wireless adapter, to use for sniffing. The basic syntax used in kismet.conf is:
source=type,interface,name
On my Ubuntu system, with an Atheros card, my source configuration looked like this:
source=ath5k, wlan0, Atheros242x
Some alternative source lines for other cards include:
source=madwifi_b,ath0,madwifi
source=orinco,eth1,Orinoco
source=prism,wlan0,hostap
source=viha,en1,AirPort
Now, save and exit your kismet.conf file, and return to your terminal.
In your terminal, run ifconfig. Locate your wireless device (mine was wlan0) and copy the MAC address (displayed as hardware address). Simply replace any hyphens that are displayed in the string with colons and omit anything after the first six pairs of characters. This is your wireless card’s MAC address. This can be changed (see, spoofed) by using the macchanger utility but I’ll let you figure that out on your own. It’s a very useful tool to have in your bag of tricks.
Locate your target
Now, back in your terminal, execute kismet. After Kismet has initialized, press the Space Bar and then press s to choose how to sort the available wireless LAN’s which are located by your wireless interface. Personally, I will usually choose to sort by channel, which is accomplished by pressing c. Bear in mind that all commands executed within Kismet are case sensitive. To view the extended details of a specific target network, use your arrow keys to scroll up or down, and once it is selected, press Enter. Once you are done viewing the details, press x to close the dialogue.
After locating the network you would like to pen-test (ie, your own network) and gathering information about your target, open another terminal. It is recommended that you go ahead and close down Kismet at this point in order to lessen the chances of interference between the software.
Start grabbing IVs
In the new terminal type…
airodump-ng --ivs -w /pathto/your/FILENAMEHERE -c 10 wlan0
airodump-ng is the script name
--ivs signals that you would like to capture Initialization Vectors (IV’s)
-w signals that you would like to write the information into a file
/pathto/your/FILENAMEHERE this is the path for the new file to be written. Change FILENAMEHERE to anything you like.
-c 10 signals the channel that the airodump script will “lock on to”. In this case; Channel 10
wlan0 is your interface device. Set this to whatever your device is labeled in ifconfig
Now, open another terminal and type…
aireplay-ng -3 -b 00:11:22:33:44:55 -h 99:88:77:66:55:44 wlan0
aireplay-ng is the script name
-3 is requesting a standard ARP-request replay by the script
-b 00:11:22:33:44:55 is the MAC address of the Access Point, set it to what you wrote down when you were gathering information on the target
-h 99:88:77:66:55:44 is the source’s MAC address. Usually, this is your own. The value here is what you wrote down earlier when you ran ifconfig
wlan0 is your interface device. Again, set this to whatever your device is labeled in ifconfig
Now we need to associate with the target access point. We do this in order to speed up the IV capture process. In yet another terminal, you would type…
aireplay-ng -1 0 -e linksys -a 00:11:22:33:44:55 -h 99:88:77:66:55:44 wlan0
aireplay-ng
-1 requests a fake authentication to be made with the Access Point
0 denotes that it will retry itself every 0 seconds, if failed. This is a zero.
-e linksys is the target AP’s SSID. Modify linksys to the target SSID
-a 0:11:22:33:44:55 is the target AP’s BSSID (MAC address)
-h 99:88:77:66:55:44 is the source’s MAC address (usually, your own).
Again, the value here is what you wrote down earlier when you ran ifconfig
After a few moments, you should receive a message verifying that authentication was successful. The number of IV’s should increase rapidly at this point, as will the number of packets and ARP requests.
After you have reached 100,000+ IV’s, run the following command in another terminal. Let’s get to cracking.
aircrack-ng -s /pathto/your/FILENAMEHERE-01.ivs
aircrack-ng
-s tells the script to decode the key into ASCII plain-text for you to view
/pathto/your/FILENAMEHERE-01.ivs is the directory and filename you gave to airodump eariler, followed by -01. Thus, a file you named key in airodump earlier will now become key-01.ivs
In the case that it fails, simply wait a few minutes and try again. You should be able to crack a 128bit WEP key in far less than 45 minutes. Bear in mind that there must be at least one active client connected to the AP for this to work. You can use the -p 0841 method if there are no active clients, which I will describe in another tutorial.
The theory behind it all…
WEP is a really crappy and out-of-date encryption technique to secure a wireless network connection. A 3-byte vector, called an Initialization Vector or IV, is appended onto the packets and it’s based on a pre-shared key that all the authenticated clients know. Simply think of it as the network key you need to authenticate.
If it’s on nearly every packet generated by the client or AP, then theoretically, if we collect enough of them, (like a few hundred thousand) we should be able to dramatically reduce the key space to check against and brute forcing becomes a very realistic proposition.
Possible Issues
- If the key is not static, then you’ll mix up all of your IVs and it will take an extremely long time to decrypt the key.
- If there’s no traffic, there are no packets – but we can fix this.
- MAC Address Filtering – we can fix this too.
The tools required…
airodump – Grabbing IVs
aircrack – Cracking the IVs
airreplay – Packet injector to attack APs.
kismet – Network Sniffer that can grab IVs as well.
For a standard WEP hack, we’ll usually only need airodump, aircrack, and kismet (the server and client). If we run into any problems, we may have to use airreplay to fiddle about, but I prefer bringing it in to the picture ahead of time as a safety measure. This way, we speed up the process and it’s less of a headache in the long run.
First step, we need to find a network to crack. Start up kismet and start sniffing out APs. Leave it on for a bit so that it can discover all the important information about the networks in your vicinity. What we want from kismet is:
- Encryption type: Is it WEP 64-bit? 128-bit?
- What channel is it on?
- AP’s IP Address
- BSSID
- ESSID
ALL of this information isn’t required, but the more you have, the more options you have later to crack and sniff.
Alright, so we know what we want to crack, so lets start capturing packets. You can use kismet to capture files but I prefer airodump because it keeps a running count of all the IVs we’ve captured and can crack them as well, if you’d like. Likewise, airodump will automatically update aircrack with any new IVs as it locates them.
Note: Kismet shouldn’t run at the same time as airodump, due to the possibility of interference between the two scripts.
Airodump will display a graph showing us all the APs and their relevant information, as well as client stations connected to any of the APs.
BSSID PWR Beacons # Data CH MB ENC ESSID
00:23:1F:55:04:BC 76 21995 213416 6 54. WEP hackme
BSSID STATION PWR Packets Probes
00:23:1F:55:04:BC 00:12:5B:4C:23:27 112 8202 hackme
00:23:1F:55:04:BC 00:12:5B:DA:2F:6A 21 1721 hackme
The second line displays some information about the AP, as well as the number of beacons and data packets we’ve collected from the AP. The last two lines show us the two authenticated clients currently connected, where they are connected and the packets they are sending. We won’t use this client information in a theory hack but in practice we’ll need this info to actively attack the AP.
This step may take a long time — upwards of an hour — or it could be very short — less than five minutes. It depends how busy the AP is and how many IVs we are collecting. What we are doing is populating a file with all the important packet information. Next, we’ll feed this data to aircrack. To move onto the next step, we’ll want at least 100,000 packets (displayed as # Data in airodump) but probably more.
Ok, let’s say you have enough IVs now to attempt a crack. Head to a new terminal (without killing airodump– remember it’ll autoupdate as new IVs are found) and we’ll start aircrack. So off it goes! Keep an eye on the Unique IV count as it should increase while airodump is still running. For all intents and purposes, you are done.
Now for some anticipated problems. There are lots of problems that can arise at this point; either they will make the above solution fail, or work very, very slowly.
No traffic
- No traffic is being passed, therefore you can’t capture any IVs.
- What we need to do is inject some special packets to trick the AP into broadcasting.
MAC Address filtering
- AP is only responding to connected clients. Probably because MAC address filtering is on.
- Using airodumps screen you can find the MAC address of authenticated users so just spoof your MAC to match theirs and continue on.
- Using the -m option you can specify aircrack to filter packets by MAC Address, ex. -m 00:12:5B:4C:23:27
Can’t Crack even with tons of IVs
- Some of the statistical attacks can create false positives and lead you in the wrong direction.
- Try using -k N (where N=1..17) or -y to vary your attack method.
- Increase the fudge factor. By default it is at 2, by specifying -f N (where N>=2) will increase your chances of a crack, but take much longer. I find that doubling the previous fudge factor is a nice progression if you are having trouble.
Still Nothing?
Find the AP by following the signal strength and ask the admin what the WEP key is.
Writing Through Dawn 