Mobile Hacking with Android

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 rouge 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 it’s 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 document, but the general idea is that you setup 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 rouge AP running on tiwlan0, and now the VPN on tap0.

The goal now is to get traffic from our rouge AP on tiwlan0 to go through the VPN, rather than straight through 3G to the Internet. If we run a traceroute from the Android device now, we will see this is currently not the case:

# traceroute 75.206.123.22
traceroute to 75.206.123.22 (75.206.123.22), 30 hops max, 38 byte packets
 1  66.174.112.129 (66.174.112.129)  143.097 ms  75.959 ms  70.312 ms
 2  66.174.112.127 (66.174.112.127)  62.164 ms  85.510 ms  69.916 ms
 ...

So what we need to do now is setup a new default route that will take all traffic out through the 192.168.1.x network’s primary router (in this case, 192.168.1.1) To do this you will use the “route” command:

# route add default gw 192.168.1.1 dev tap0

Note that, unlike the desktop Linux equivalent, the Android “route” command requires you give it an interface name.

Re-running the traceroute command from before, we can see that the path packets are taking through the phone has changed:

# traceroute 75.206.123.22
traceroute to 75.206.123.22 (75.206.123.22), 30 hops max, 38 byte packets
 1  192.168.1.50 (192.168.1.50)  300.831 ms 365.326 ms  265.656 ms
 2  66.174.112.127 (66.174.112.127)  257.843 ms  257.507 ms  265.930 ms
 ...

The first hop is now the tap0 interface, so we can see that data is traveling through the 192.168.1.x network to get to the Internet, rather than directly out 3G. The keen eye will also note the increased travel time, as data now has to run through the VPN before it gets out to the Internet. Though it is worth noting that the travel times shown here are rather high because my phone had poor signal when I ran this particular test. In ideal conditions, performance over the VPN is not much different than 3G alone.

With the victim’s data now traveling through the attacker’s personal network, there is no limit to what he can do. A server on the network could provide the victims spoofed DNS entries and forged login pages, or sslstrip could be used to hijack HTTPS connections and get their plain-text content. A combination of these techniques could be used to present the victim with a convincing looking “Critical Update” page that instructs the user to “Download and install the following important system update…” before allowing them to continue on to the Internet at large.

Conclusion

For those of us interested in technical exploration, Android offers nearly unlimited possibilities. Not only can an Android device be used to explore and examine the world around us, we are even given the freedom to explore and modify Android itself by virtue of its open nature. While the installation and use of security related tools on a mobile device is certainly nothing new, older devices primarily used close source proprietary operating systems the user had no control over. Even in the few previous mobile devices that actually shipped with an open source OS, you were still limited by the relative rarity of supported devices and the small userbase. The fact that you can walk into the store of essentially every cellular carrier in the US and purchase a handset that runs an open source OS with development tools baked right in is completely without precedent.

Of course, the same opportunity is available for criminals, and if Android continues it’s meteoric rise in popularity as analysts predict, it won’t be long until they start getting on the Android bandwagon too. Whether it is to develop malicious applications or remote exploits (at the time of this writing, proof of concepts exist in both cases), criminals will attempt to exploit Android’s open nature for their own gains.

For hackers, Android represents not only an excellent platform for personal use and an ideal worthy of our support, but also a future battleground. As smartphones approach the ubiquity that was once reserved for wristwatches, mobile security research and development will be key in protecting user’s data and privacy. The hacker ethics of exploration, experimentation, and dissemination of knowledge can aid in Android’s evolution just as they once helped shape the telephone itself.

Pages: 1 2 3 4