Android Authentication Vulnerability

Back in February of this year, Dan Wallach, a computer science professor at Rice University, posted an article at the Freedom to Tinker blog about the results of a class experiment using a WiFi “sniffer” to eavesdrop on communications from an Android smartphone.  One of the things he noted was that communications to and from some services, such as Google Calendar, were done in clear text.  This issue has resurfaced in the last few days, because a group of researchers at Universität Ulm in Germany published a note on their work, demonstrating that there was an exploitable security vulnerability.

The vulnerability exists in Android versions prior to 2.3.4 (the most recent version).  It is not really a vulnerability in the Android OS, but a consequence of the clientLogin protocol, which is used to authenticate the user, being transmitted in clear text.  Under this protocol, when the user has entered his user ID and password, an authentication token is returned to the browser, which is used for subsequent session authentication.  If the plain-text token can be sniffed, an attacker can impersonate the user.  (This is very similar to the technique used for browser session hijacking embodied in the Firesheep extension for Firefox.)  The exposure is made greater because the authentication tokens typically have a long lifetime (up to two weeks).

Beginning with Android 2.3.4, the clientLogin protocol and subsequent communications are done with a secure encrypted (https:) protocol, at least for the Calendar and Contact applications, which removes the vulnerability.  (Some applications, such as Picasa, still appear to be vulnerable.)   However, as an article at Ars Technica points out, the absence of a systematic software update procedure for smartphones means that most users are still vulnerable.

Although the bug has already been fixed (for calendar and contact sync, but not Picasa) in Android 2.3.4—the latest version of the operating system—the vast majority of mobile carriers and handset manufacturers haven’t issued the update yet. According to Google’s own statistics, this means that 99.7 percent of the Android user population is still susceptible to the vulnerability.

This really is a problem that should have been foreseen.  After all, we do have experience with the (lack of) security consequences of putting general-purpose computing devices in users’ hands without a plan to fix software problems.  Also, especially for wireless devices, there is really no justification for using anything but encrypted communications.

Fortunately, there are some encouraging developments.  A group of large handset vendors and cellular carriers have formed a working task force to develop systematic update policies and guidelines.

Although the initiative is still at a very early stage and the policies it formulates will be entirely voluntary, it already has preliminary buy-in from enough prominent Android stakeholders to make it credible. The leading Android handset manufacturers and all four of the major US carriers are currently involved.

I hope that the group does manage to put some reasonable system in place; we have seen all too often that leaving all of the systems administration to the users is a recipe for trouble.

Comments are closed.

%d bloggers like this: