Google today confirmed that it’s starting to roll out a server-side patch for a security vulnerability in most Android phones that could let hackers snatch important credentials at public Wi-Fi hotspots.
“Today we’re starting to roll out a fix which addresses a potential security flaw that could, under certain circumstances, allow a third party access to data available in Calendar and Contacts,” said a Google spokesman in an emailed statement. “This fix requires no action from users and will roll out globally over the next few days.”
Computerworld blogger JR Raphael was the first to break the news of Google’s move to fix the flaw.
Google will apparently apply a fix on its servers since it does not need to issue an over-the-air update to Android phones.
Experts applauded Google’s fast reaction.
“It’s impressive how quickly Google fixed this,” said Kevin Mahaffey, chief technology officer and a co-founder of San Francisco-based mobile security firm Lookout. “Google’s security team, especially on Android, is very, very quick to deal with issues.”
Mike Paquette, the chief strategy officer for Hudson, Mass.-based Top Layer Security, agreed.
“The Google team talks about how they breathe security in and out, and this is a good example,” said Paquette, who called the speed with which Google addressed the issue “pretty good.”
Whatever Google is implementing will shut the security hole that three German researchers publicized last Friday .
According to the University of Ulm researchers, who tested another researcher’s contention last February that Android phones sent authentication data in the clear, hackers could easily spoof a Wi-Fi hotspot — in a public setting such as an airport or coffee shop — then snatch information that users’ phones transmitted during synchronization.
In Android 2.3.3 and earlier, the phone’s Calendar and Contacts apps transmit information via unencrypted HTTP, then retrieve an authentication token from Google. Hackers could eavesdrop on the HTTP traffic at a public hotspot, lift authentication tokens and use them for up to two weeks to access users’ Web-based calendars, their contacts and also the Picasa photo storage and sharing service.
Other applications that use Google’s ClientLogin Protocol, including third-party Android apps as well as traditional desktop software like Mozilla’s Thunderbird email program, were also vulnerable, the researchers said.
“The implications of this vulnerability reach from disclosure to loss of personal information for the Calendar data,” said the three researchers, Bastian Koenings, Jens Nickels, and Florian Schaub. “For Contact information, private information of others is also affected, potentially including phone numbers, home addresses, and email addresses.”
The trio estimated that 99% of Android users were affected because of the slow and fragmented updating that carriers conduct.
Koenings, Nickels and Schaub also outlined more devious damage that a cyber criminal could do. “An adversary could perform subtle changes without the user noticing,” they said. “For example, an adversary could change the stored email address of the victim’s boss or business partners hoping to receive sensitive or confidential material pertaining to their business.”
Google declined to specify how it’s addressing the problem, but the German researchers had posed several ways the search giant could plug the security hole.
Among them, Google could modify its services to “reject ClientLogin-based requests from insecure HTTP connections to enforce use of HTTPS,” said the researchers, referring to the encrypted data transmission used by online retailers. “HTTPS is already required for the Google Docs API und will be required for Google Spreadsheet and Google Sites APIs in September 2011. It should be mandatory for all of Google’s data APIs.”
Lookout’s Mahaffey suspects that that is exactly the route Google is taking.
“I haven’t seen exactly what they’re doing,” said Mahaffey, “so I can’t speculate much, but one solution would be to make it so that authentication tokens aren’t sent in the clear anymore.”
Paquette assumed the same.
“My guess is that the ClientLogin Protocol had an option that allowed clear text over HTTP, and that Google disabled that on its end by having it say, ‘Our end is always going to say “No” to that.’ When that happens, the client will decide to send the authentication request encrypted.”
While Google could have applied the same fix to the client side — to each Android phone running an older version of the operating system — the faster solution was to do it on the server side, Paquette said.
“It’s possible that the newest [version of] Android doesn’t even offer that [clear text] option,” speculated Paquette when asked why only older editions of Android were affected.
HTTPS has been in the news several times this year, as major Web-based services have added it as an option or made it a requirement in an attempt to prevent password theft at unsecured Wi-Fi hotspots.
Last March, for example, Twitter added HTTPS as an option to its users.
Some of those moves were in reaction to last year’s release of the “Firesheep” add-on for Mozilla’s Firefox that let “pretty much anyone” scan a Wi-Fi network and hijack others’ credentials for Amazon, Facebook, Google, Twitter, and other services.
“Right now, we’re in a transition period,” said Mahaffey, talking about the move from unsecured HTTP to the encrypted HTTPS. “It’s taken the industry a while, but with the amount of data stored in the cloud, being moved to the cloud, it’s very important that HTTPS be required.”
Google is still investigating the authentication issue during synchronization between Android phones and its Picasa service.
