Hack Android stock email client

[alien]

When I got my first Android device just over a year ago, one of the first things I noticed was this little configuration feature in the stock email client.

Really, “accept all SSL certificates”? Doesn’t sound like a very good idea, now does it? This thing has been brewing in the back of my head ever since until I finally worked up the motivation of doing some research about it. Let’s start with some basics:

A computer, be it a mobile device or a laptop, generally has a list of trusted certificate issuers. Once the computer makes an SSL connection, it checks so that the issuer of the received SSL certificate is in the trusted issuers list. In theory, ticking the “accept all SSL certificates” checkbox would tell the device not to validate against the list but to accept any issuer.

Let’s validate the theory by staging a man-in-the-middle (mitm) attack against an Android device connected to a wireless network. Note that this attack will also work on a wired network but will not work if the mobile device is communicating over GPRS.

In this experiment, I have a wireless network with a gateway (192.168.2.1), an Android device (192.168.2.4) and myself, the attacker (192.168.2.3). The concept of the attack is to place myself in between the Android device and the gateway to be able to intercept and eavesdrop on the traffic.

It begins…

I’ll start by forwarding the default ports for HTTP and HTTPS to port 8080 were I’ll have a client-side web proxy listening. The reason for doing this is that I want to use a separate tool for the web traffic sniffing. To do this, I use the following IPTABLES commands in Linux:

root@bt:~# iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-ports 8080
root@bt:~# iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 443 -j REDIRECT –to-ports 8080

Note that these commands will not be saved to your configuration, after your next reboot they will be gone. If you want to save them, the command is:

root@bt:~# iptables -save

The web sniffer

The next thing to do is start up BURP which is the tool that will act as sniffer for the web traffic. I’ll configure it to listen externally on port 8080 and to produce a (fake) SSL certificate per host.

Man In The Middle

Next I need to trick the Android device that I’m the gateway and vice versa. To do this, I use a tool called Ettercap and a technique called “arp poisoning” which is executed by the following command:

root@bt:~# ettercap -T -M arp:remote /192.168.2.4/ /192.168.2.1/

…which would produce something like this:

Note that even though I use BURP to sniff the web traffic, I have still enabled Ettercap to do some sniffing on its own by setting the ‘-T’ flag. If I wanted Ettercap to act strictly as a man-in-the-middle, I could replace the ‘-T’ with an ‘-o’ for “only mitm”.

The outcome

As long as the “accept all SSL certificates” checkbox is NOT ticked, the email client will only display a “could not connect to the server” message, which is good. If we however decide to check the box, this is what BURP produces:

So, we’ve got the username in clear text and an authorization string which is a base64 encoding of domain\username:password. For an attacker, that would qualify as a jackpot.

Summary

I can understand why this “feature” might be handy, for example; purchasing a certificate from a trusted issuer such as VeriSign or Thawte is expensive so some smaller companies might want to use a self-signed certificate instead. Still, the checkbox could have been placed in a different place, and ticking it could have at least produced a warning of some kind.

What happens when a non tech-savvy user connects his device to a wireless network and finds that he can’t download his emails? Chances are he’ll check his account settings, notice the unticked checkbox and think “Hey, it can’t hurt to try”. If it works after that, I can guarantee that he will never give it another thought.

Source: The Insecurity of the Android Stock Email Client | 3vildata