Android, HTTP and authentication tokens

Published: 2011-05-18
Last Updated: 2011-05-18 08:21:53 UTC
by Bojan Zdrnja (Version: 1)
8 comment(s)

A few days ago, a group of researchers from the University of Ulm in Germany published details about a security “vulnerability” in Android operating systems version 2.3.3 or lower. This is not really a vulnerability but the way that Android apps use the ClientLogin authentication protocol in order to access various Google’s services.

As you can probably guess by now – the problem here is that ClientLogin sends authentication data over plain text HTTP connections. The Authorization: header, which is used (as the name implies) for authorization is sent as part of a GET request in plain text so any attacker who can see this traffic can easily extract this header and impersonate the victim. Depending on what you use, the token can give the attacker access to the Calendar and Contact Google applications. What’s even worse, the token is valid for 14 (!!!) days, so once it has been acquired by the attacker it can be easily used in the future.

This issue is not limited only to Android – any other application that uses the ClientLogin protocol over plain text HTTP is subject to similar attacks, however since Android is so wide spread it looks as the most critical target for a potential attacker.

How could an attacker exploit this? First of all, if you are connecting with your Android on any open wireless networks (i.e. Starbucks or similar), the attacker can easily sniff your traffic and collect all authentication tokens. Similarly, the attacker could setup a fake access point with a familiar name to get victims to connect to it – if the attacker is just forwarding traffic (and extracting authentication tokens), the victim will never even know what happens. Finally, attacks such as ARP poisoning are possible even on encrypted wireless networks (if the attacker can connect to it).

What can you do? If possible, update Android to at least version 2.3.4 on your phones since that version uses HTTPS for authentication. In today’s world, there is absolutely no reason not to use SSL to encrypt everything.


8 comment(s)


The show has now dropped...How many of those with Android handsets running Android 2.3.3 or lower CAN upgrade? Aren't the majority of the handsets still running 2.2.x? much longer until an actual security vulnerability renders these handsets as bricks?
Yes, many have Verizon or AT&T and you cannot just upgrade the OS on these phones when you want, the vendor has to push the update down. Meanwhile, we all sit and wait....why isn't there a stronger push to get vendors to keep up with the updates better?
Wife and I have identical Android phones: an LG Ally on the Verizon network. It was a New Every Two deal so we got them for free.

However, mine is rooted and hers is not.

I'm stuck at Android 2.1 for some reason (it won't discover updates for the OS, I am guessing a side effect of rooting it) and wife is on 2.2.1. That is the latest and greatest from Verizon.

The processors on these phones are pretty puny (Flash? forget about it), so I don't know if we'll get future updates to 2.3 at all.

And we've got at least another year on our contracts.

We're hosed then. Good thing the wife doesn't use the WiFi on hers at all and I only connect to my home network with mine. At least that will make exploiting it harder.

We've only got 3G, but that's good enough for most activity. It certainly isn't worth it to connect to strange WiFi unprotected.
I find it amazing (if not shocking) that Google even _offers_ login via a non-HTTPS page...
Could someone login to their Google account in a web-browser using https and have the applications reuse that token so no data would leak for the next 14 days?
I wonder if this could be escalated by using stolen tokens to gain full access to the google account, or somehow used in conjunction with to remotely install nefarious software to android devices.
News are out that Google will fix this server-side, solving the problem also for older Android versions.

The smartphone market is suffering a bit of supply-chain/support problems like we used to have in PCs. The software support interface is controlled by the carrier (AT&T, Verizon), but they are not really interested in the trivia. Some of that has to do with how much different every implementation platform is.
When MS finally built out Windows Update, we got past waiting for the middlemen. Something similar has to happen for smart phones. At least Google is closer to this. In the meantime, I suggest, if you are inclined, to check out Originally a Windows Mobile expertise site, they have jumped on Android as well. Updates and fixes often appear there before they get support distribution.

Diary Archives