Last May, DD-WRT released the (long in development) v24 of their firmware. I had been running one of the release candidates for it on my Linksys WRT54GL, but decided today to upgrade to the stable release. I downloaded the appropriate file (dd-wrt.v24_std_generic.bin), followed the instructions for flashing through the web GUI, and promptly bricked the router.
It wasn’t totally destroyed. I could still ping the router, but couldn’t access it in any other way. The power light would flash repeatedly, and no other lights came on. No amount of hard resets would fix it.
According to DD-WRT’s wiki article on bad flashes, the repetitive blinking of the power light means that the bootloader is defective, but that the problem might be solved using a TFTP recovery. The idea is that when the router first boots up, there’s a brief moment where it will accept an upload. By pushing through firmware, you are able to temporarily boot the router.
On older Linksys routers, this only works with the official Linksys firmware, so I downloaded the latest version from Linksys’ support page for the WRT54GL. Because the router will only accept the firmware at the very start of the boot process, I first unplugged the router, turning it off. To monitor the router during the process, I started a ping from my machine.
$ ping 192.168.1.1
Then, using the TFTP client that ships with OS X, I executed the upload
and immediately plugged the router back in. In 10 seconds, TFTP reported that the file had been sent.
At this point, the router stopped responding to my pings for about 30 seconds. When it began replying again, I was able to access the default Linksys web GUI. The first thing I did in the GUI was to hit the “reset to factory defaults” button, which clears the NVRAM of my bad DD-WRT image and installs the fresh Linksys image. After that, I installed a new DD-WRT “mini” image (the WRT54GL requires you flash with “mini” before upgrading to “standard” when moving from the default firmware), by uploading dd-wrt.v24_mini_generic.bin via the upgrade page. This worked without a hitch.
In the DD-WRT web interface, I tried to flash the router with the standard firmware, but was greeted by a vague error message that told me only that the upgrade had failed. I went back to the wiki to see what the differences were between mini and standard and decided that it would be find to leave the router with mini. All I needed was for the router to act as a wireless repeater with a virtual interfaces. The mini firmware supports this, so I was able to setup the router just as before.
As the Macbooks don’t come with PCMCIA or Express card slots, I’m unable to use my old Proxim card for less than savory acts of wireless piracy. I haven’t been able to find any USB wifi dongles that please me, so I decided to go another route.
The DD-WRT project is alternative firmware that turns your supported consumer wireless AP into an untamed beast. More to the point, it allows the AP to act as a repeater – hijacking a current signal, boosting it, and rebroadcasting. For the hardware, I bartered for a Linksys WRT54GL (v1.1) at the Bay of E. The device is supported, and has two RP-TNC jacks, allowing me to replace the default antennas with two of my uncommonly large spikes.
Despite the labyrinth of convoluted, contradictory information that is the DD-WRT wiki, installation was quite simple. First, I reset the router to factory defaults through the web interface. It was new out of the box, so I imagine already set to factory defaults, but who knows. The wiki suggests the first flash of the WRT54GL be with the mini firmware, but, after that, it can be flashed to any other version. So, I downloaded both dd-wrt.v23_sp2_mini.zip and dd-wrt.v23_sp2_standard.zip. The wiki also claims that Firefox may fubar the upgrade and suggests using IE in its stead. Not having access to IE, I went to flash dd-wrt.v23_mini_generic.bin through the web interface using Safari, which promptly failed. The router’s default firmware was in no way damaged, so I went to do the same thing again in Firefox (2.0.0.11), which worked without a hitch. Giving no explanation as to why, the wiki suggests that after one arrives at the “Upgrade Successful” screen, one should wait for the esoteric count of 5 minutes before hitting continue (perhaps while chanting some manner of incantation). I did this (minus the chanting), hit continue, and was greeted by a login prompt. The default user/pass of root/admin didn’t work, so I held down the reset switch on the back of the router for 30 seconds (leaving the power cord plugged in), after which the router booted up, accepted the root/admin login, and all was shiny. After that, I upgraded to the standard firmware without note, and quickly realized that I actually needed the v24 beta firmware. So, I grabbed dd-wrt.v24_std_generic.bin, upgraded to that (again without problem), and was finally ready to turn it into a repeater.
To set it up, I first changed the router’s IP to 192.168.69.1, so that it was on a different subnet than my target. Next, under Wireless Basic Settings, I changed the mode to Repeater, entered the target SSID, and changed the wireless channel to Auto, leaving all the other settings on their defaults. After saving those settings, I added a virtual interface with my own SSID and made sure it was set to Bridged. Then, after saving that, I followed the wiki’s advice to go to the Security tab, uncheck everything under Block WAN Requests and disabled the firewall. That was it. The router had a WAN IP displayed in the upper right hand corner, indicating that it was working.
Note that up till here, I was doing everything on the router through a wired connection, which was strongly urged in many places and seemed wise to me. At this point, I unplugged the cat5, turned on my Airport, connected to my new AP, and was online immediately.
Before moving into my new place last month, I had planned on paying an ISP for internet access. But, complications arose with the company I had chosen, so I decided to cancel my order soon after it was placed. Instead, I planned to borrow internet access from my neighbors (hey, they’re pumping signals into my air-space). Trouble was, everyone had encrypted their networks with WEP. No doubt this is a good thing, and a vast improvement from the last time I had scanned down here (about 8 months ago), but I wanted in. I was able to justify cracking in to myself by recognizing that my paranoia isn’t limited just to the “others” out on the global interwebs – no, I’d be just as paranoid about the owner of whomever’s network I was breaking into watching my traffic. There was no question I’d make ample use of encryption, which, as a side benefit, meant that anything I did through his connection would be rather difficult to trace back. So, he was protected. As long as he wasn’t paying for bandwidth by the KB, he’d not be much affected by my leeching. (I use the pronoun “he” because I know now that the owner of my primary network is, in fact, a he – put a password on your routers, people!).
But there was another problem, in addition to WEP: during reconnaissance, I would rarely pick up any connected clients. Perhaps I was always trying at the wrong time of day. Or perhaps people pay for internet access and never use it. Regardless, it would have taken weeks of constant logging to gather enough IVs to crack the WEP key. So, the first step was to take the money I had saved by canceling my order with the ISP, and invest in a new wireless card that supported packet injection.
The Proxim 8470-WD (from aircrack-ng’s recommended list) caught my eye, though it took a while before I could find it a decent price. To do my initial cracking, I popped in Backtrack and followed aircrack-ng’s newbie guide. (I had upgraded my trusty old Auditor cd to Backtrack just for this occasion. It’s quite the nice distribution.) Within about 5 minutes, I had gained access to the first network. Goes to show how secure WEP is.
Though the Proxim card is plug and play in Ubuntu, the steps to crack WEP are a little different. Here’s what I do (note that I do recommend using Backtrack, instead).
First, of course, one must install aircrack:
sudo apt-get install aircrack
You may change your mac address manually, or, if you aren’t concerned with anonymity, don’t change it all. I have a preference of using the macchanger tool:
sudo apt-get install macchanger
Set your card’s MAC address randomly. In this case, the network device is at ath0:
sudo ifconfig ath0 down
sudo macchanger -r ath0
sudo ifconfig ath0 up
Put your card into monitor mode:
sudo iwconfig ath0 mode monitor
Start scanning:
sudo airodump ath0 dump 0
In this case, dump is the file prefix for airodump’s output and the 0 tells airodump to channel-hop. Now you want to pick your target network from the scan. It should have at least one client connected (displayed at the bottom of airodump’s output), the more the merrier. (Hopefully that client is transmitting data, too.)
When you pick your target, kill the first instance of airodump and start it up again, this time specifying the channel of your target:
sudo airodump ath0 targetdump 9
The targetdump is the file prefix and 9 is the channel. Optionally you can add a 1 to the end of the command, which tells airodump to only capture IVs (which is what you’re after). I normally don’t bother.
When you’ve captured somewhere in the range of 250,000 - 500,000 data packets (shown by airodump in the “Packets” column of your target client), you can start cracking:
aircrack -b 00:12:34:45:78:A3 targetdump.cap
In this case, -b is the essid of your target network. Cracking could take minutes, hours, days, weeks, months, or years. I’ve never had to wait over 20 minutes.
But what if the client is being a party-pooper and not transmitting? That’s where packet injection comes in. From aircrack’s guide:
ARP works (simplified) by broadcasting a query for an IP and the device that has this IP sends back an answer. Because WEP does not protect against replay, you can sniff a packet, send it out again and again and it is still valid. So you just have to capture and replay an ARP-request targeted at the AP to create lots of traffic (and sniff IVs).
You’ll want to keep airodump running, so that all the traffic you generate will be captured. In another terminal, start injecting:
The -3 tells airepay you want to replay ARP requests, -b is that target network, and -h is the client. In a little bit, aireplay should inform you that it has captured 1 (or more) ARP packets. Sit back and watch airodump count up the IVs.
If that pesky client still isn’t cooperating, you can give it a little motivation. From aircrack:
Most operating systems clear the ARP cache on disconnection. If they want to send the next packet after reconnection (or just use DHCP), they have to send out ARP requests. So the idea is to disconnect a client and force it to reconnect to capture an ARP-request. A side-effect is that you can sniff the ESSID during reconnection too. This comes in handy if the ESSID of your target is hidden.
...the risk that someone recognizes this attack or at least attention is drawn to the stuff happening on the WLAN is higher than with other attacks.
Keep airodump and aireplay running, and in a new terminal give it a little kick in the butt:
sudo aireplay -0 5 -a 00:12:34:45:78:A3 -c A3:78:45:34:12:00 ath0
The first switch, -0, informs aireplay you want to force the client to be unauthenticated, -a is the target network, -c is the target client. When the client reconnects, you should start grabbing ARP requests.
After you have enough packets, crack the WEP key as before.
To manage and connect to my wireless networks, I’ve taken to using wifi-radar. It scans for networks, allows you to specify which networks you prefer and, for each network, allows you to set preferences such as the WEP key, whether to use dynamic or static addresses, and the like. What I like best is the connection commands, which allows you to set commands you want executed before wifi-radar connects to the network, and after. In the before field, I have it randomly change my mac address:
ifconfig ath0 down && macchanger -r ath0 && ifconfig ath0 up
After it connects, I restart tor:
/etc/init.d/tor restart
(As another reference for you, this site keeps turning up as a guide to cracking WEP in Ubuntu.)