Android vulnerability exposes users to data theft

Using an Android device on unsecure Wi-Fi can expose your calendar, contacts, and other data to bad guys

Android users running apps over an unsecured Wi-Fi network run the risk of having their authentication tokens swiped by eavesdroppers. Those tokens can be used to secretly view and tamper with your contacts, calendars, email, and other information, according to research from University of Ulm.

The bad news: Smartphones running Android 2.3.3 or earlier -- which accounts for 99.7 percent of Android devices -- are most vulnerable. The good news: Developers, users, and Google can take steps to reduce the risks.

The vulnerability can affect apps that access Google services, such as Calendar or Contacts, via the ClientLogin authentication protocol, according to the researchers. Using ClientLogin, an app requests an authentication token from the associated Google service. That authToken can be conveniently (from a user perspective) repurposed for subsequent service requests for two weeks.

The problem is, if the authToken is used in a request sent via an unencrypted insecure connection (HTTP instead of HTTPS), an eavesdropper can grab it and use it for that 14-day period to get at user data made available through the service. Compounding the problem, the authTokens aren't bound to any session or device-specific information.

Thus, "[an] adversary can gain full access to the calendar, contacts information, or private web albums of the respective Google user," according to the researchers. "This means that the adversary can view, modify or delete any contacts, calendar events, or private pictures. This is not limited to items currently being synced but affects all items of that user."

A hacker could collect a large store of tokens by first setting up a Wi-Fi access point with the same SSID of an unecrypted wireless network, such as one a user might access at the airport or the local coffee shop. Any Android device set to automatically connect to a previously known network would attempt to sync automatically when in range. Whether or not the hacker opted to forward the request, he or she would be able to capture authTokens.

Beyond being able to view user data, a hacker could use the token to tweak a victim's contacts list to, for example, alter an email address or group so that the user would inadvertently send messages to an unintended recipient.

The researchers tested out apps that contact Google services, including Calendar, Contacts, and Gallery, on various iterations of Android. They found that those apps were all vulnerable on devices running Android 2.3.3 or earlier. On Android 2.3.4 and later, Calendar and Contacts use a secure HTTPS connection, though the Gallery app -- which syncs with Picasa online Web albums -- does not. More important, the vulnerability is not limited to standard Android apps; any Android or desktop app that accesses Google services via ClientLogin over HTTP is vulnerable.

The researchers offer several suggestions for fixing the vulnerability. App developers whose apps and services use ClientLogin should switch to HTTPS. They should also switch to more secure authentication services, such as oAuth.

Google, the researchers advise, should limit the lifetime of authTokens. Google services should be tweaked to reject ClientLogin-based requests over insecure HTTP connections.

Android users should update to Version 2.3.4 of the OS, though the update is not immediately available for all phones. Additionally, users should switch off the set that permits automatic synchronization with open Wi-Fi networks. The best protection at the moment, according to the researchers, "is to avoid open Wifi networks at all when using affected apps."

More details are available on the University of Ulm website.

This article, "Android vulnerability exposes users to data theft," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest business technology news, follow InfoWorld.com on Twitter.

Join the discussion
Be the first to comment on this article. Our Commenting Policies