2600 Magazine_ The Hacker Quarterly - Digital Edition - Summer 2011 - 2600 Magazine [16]
Once you feel you have captured enough data, simply stop Shark and shutdown Wireless Tether. You can then open up the PCAP file that was created under /sdcard in Shark Reader (a basic PCAP analyzer created as a companion for Shark), or better yet, pull the file off of the phone's SD card and open it up in Wireshark. Assuming everything went according to plan, you should be looking at a complete log of everything your victim(s) did while connected to your "free" Wi-Fi AP.
A Step Further: Data Siphon
Being able to log all of the plain text traffic to and from the victim's computer is certainly bad, but there are limitations to the Android platform that keep the attack from moving much beyond that. As flexible and widely supported as it is, Android still only has a fraction of the tools available for x86 operating systems. Even if more advanced tools were available for Android, the processing and storage limitations of mobile devices would make it difficult to do much in the way of real-time data manipulation while still delivering the content fast enough to keep the victim from suspecting anything.
But what if, rather than attempting to manipulate the data stream on the mobile device itself, he simply redirected all of the traffic from his rogue AP to another network of which he had full control over; a network which housed machines with the software and processing capability to manipulate the victim's data in real-time? As it turns out, it only takes a few more steps to adapt the man-in-the-middle setup from the previous example into a "siphon," which can redirect all of the traffic on the rogue AP to any network the attacker wishes.
The first step is to bridge the connection between the Android device and the destination network by way of a VPN. Android comes with support for various types of VPNs out of the box, but there are some long-standing bugs in its implementation that make it all but useless in many software configurations. Luckily, the community rose to the challenge and ported over OpenVPN, which offers incredible amounts of customization and capability. Some custom Android ROMs include OpenVPN, but if yours doesn't, you can download it from the Marketplace by way of the OpenVPN Installer application by Friedrich Schaeuffelhut. The same developer also put out an application called OpenVPN Settings, which aims to make configuring and managing OpenVPN connections as easy as the built-in VPN functions, which you may also want to grab.
The actual configuration of an OpenVPN server is outside the scope of this article, but the general idea is that you set up an Internet-facing server in bridge mode. This will let you connect your VPN client (the Android device) to the server from a remote location and give it an IP that is within the subnet of the destination network. I personally used a Linksys WRT56GL running DD-WRT as my OpenVPN server, but any other implementation will work just as well.
With OpenVPN correctly configured on both sides, and Wireless Tether running, the output of "netcfg" should now look something like this:
# netcfg
lo UP 127.0.0.1 255.0.0.0 0x00000049
dummy0 DOWN 0.0.0.0 0.0.0.0 0x00000082
usb0 DOWN 0.0.0.0 0.0.0.0 0x00001002
tap0 UP 192.168.1.50 255.255.255.0 0x00001043
ppp0 UP 75.206.123.22 255.255.255.255 0x000010d1
tiwlan0 UP 192.168.2.254 255.255.255.0 0x0000104
Notice the addition of the "tap0" interface, with an IP address in the middle of the WRT54G's 192.168.1.x network. The Android device is now connected to three separate networks simultaneously: the primary 3G Internet connection on ppp0, the rogue AP running on tiwlan0, and now the VPN on tap0.
The goal now is to get traffic from our rogue AP on tiwlan0 to go through the VPN, rather than straight through 3G to the Internet. If we run a traceroute