# 99% of Android handsets vulnerable to account credential theft



## Kid_Eternity (May 17, 2011)

> A report filed by UK publication The Register details a scary weakness in most Android handsets currently being sold. The aforementioned vulnerability would allow attackers to collect and use digital tokens stored on a handset after a user authenticates to a password protected service.
> 
> “The weakness stems from the improper implementation of an authentication protocol known as ClientLogin in Android versions 2.3.3 and earlier,” reads the report, quoting research from the University of Ulm. “After a user submits valid credentials for Google Calendar, Twitter, Facebook, or several other accounts, the programming interface retrieves an authentication token that is sent in cleartext.
> 
> Because the authToken can be used for up to 14 days in any subsequent requests on the service, attackers can exploit them to gain unauthorized access to accounts.” Google has issued a patch for the ClientLogin protocol with Android 2.3.4 and Android 3.0, but, as The Register points out, only 1% of Android devices are currently running the updated code.



Google has the perfect excuse to exert more control over Android, cleaning up the problems of fragmentation.


----------



## mauvais (May 17, 2011)

Kid_Eternity said:


> Google has the perfect excuse to exert more control over Android, cleaning up the problems of fragmentation.


Err, what? This is a vulnerability in a Google service.

Edit: It's also fixable on the server side and/or by applications (by replacing HTTP with HTTPS).


----------



## fractionMan (May 17, 2011)

that's a massive facepalm of security ineptitude tbh.  It's such an obvious flaw and so easily fixed from the start.


----------



## editor (May 17, 2011)

Obviously any kind of security loophole is of concern, but has anyone actually suffered an attack from this?


----------



## Kanda (May 17, 2011)

Did anyone suffer in any way after the Apple tracking malarky? 

No, but people still went bonkers about it.

Meh.


----------



## fractionMan (May 17, 2011)

editor said:


> Obviously any kind of security loophole is of concern, but has anyone actually suffered an attack from this?


 
they will now imo.  It's soooooo easy to exploit.


----------



## Kid_Eternity (May 17, 2011)

Kanda said:


> Did anyone suffer in any way after the Apple tracking malarky?
> 
> No, but people still went bonkers about it.
> 
> Meh.


 
Well quite but real world evidence of anything hasn't always been the criteria for which we can post on this forum so why start now?


----------



## editor (May 17, 2011)

Kanda said:


> Did anyone suffer in any way after the Apple tracking malarky?
> 
> No, but people still went bonkers about it.
> 
> Meh.


According to some reports, yes. In fact - according to this report - they've been _convicted_ because of it. 

http://checkswag.com/2011/04/22/researchers-say-police-already-use-iphone-tracking-data/


----------



## elbows (May 18, 2011)

Its very sad to see blatant platform bias soiling these security discussions.


----------



## elbows (May 18, 2011)

elbows said:


> Its very sad to see blatant platform bias soiling these security discussions.


 
And I do mean both sides, I expect I was a little slack with the Apple tracking stuff.  But attempts to downplay Googles security issues makes me sad.

This will certainly be a good test of whether android upgrade lags and fragmentation cause security woes to linger. Hopefully its like mauvais suggests and it can be worked round without android os update, otherwise there could be problems.


----------



## mauvais (May 18, 2011)

This is how ClientLogin works:







The problem is that e.g. steps 7 and 8 _can _transmit the token in plaintext over HTTP - it supports HTTPS which is inherently encrypted, but it also allows HTTP for now.

Now you can replace your applications like Facebook (if that uses HTTP) and fix it. The difficult bit is that _some _of those applications such as Google contact sync are embedded in the phone and/or modified by the OEMs like HTC, so not easy to replace.

Another thing Google could do is on the server side - the crudest way would be deny HTTP requests but this would break the relevant functionality of those apps. They could also variously reduce the attack window, e.g. shorten the 14 day period, revoke the token when you log in somewhere else, maybe tie it to other information and so on - all unilaterally without any update on the client.

That this was ever allowed was stupid. Exploiting it is technically easy if the victim is using an open, unsecured network but then eavesdrop attacks like this are not normally a matter of course.


----------



## Kanda (May 18, 2011)

editor said:


> According to some reports, yes. In fact - according to this report - they've been _convicted_ because of it.
> 
> http://checkswag.com/2011/04/22/researchers-say-police-already-use-iphone-tracking-data/


 
That's not a hack though is it. The Police could get their location from the provider anyway. Being convicted for as crime is like being the victim of a hacking vulnerability?? Really? ...


----------



## fractionMan (May 18, 2011)

yup, that step 7 being unencrypted is massively stupid.


----------



## editor (May 18, 2011)

Kanda said:


> That's not a hack though is it. The Police could get their location from the provider anyway. Being convicted for as crime is like being the victim of a hacking vulnerability?? Really? ...


I was simply correcting your comment. 

Back on topic, this sloppy mistake by Google really is a piece of supreme fuckwittedness, and they should be judged by how quickly they fix this.


----------



## cliche guevara (May 18, 2011)

Am I right in thinking that this exploit only works if the attacker is on the same wireless network as the victim? If that's the case, then not a huge deal for the average user but a massive blow to the prospects of Android for business users.


----------



## mauvais (May 18, 2011)

cliche guevara said:


> Am I right in thinking that this exploit only works if the attacker is on the same wireless network as the victim? If that's the case, then not a huge deal for the average user but a massive blow to the prospects of Android for business users.


As far as I know, you just have to be able to eavesdrop. This could be wirelessly or anywhere down the line of communication along the network. As I said earlier, it can be fixed - it's not an inherent problem, so of limited concern to businesses. Any business that really cares about security uses certified devices, which I think means only Blackberries.


----------



## editor (May 18, 2011)

From Gizmodo:



> Google’s Plugging That Potential Android Personal Data Leakage Right Now
> http://gizmodo.com/5803130/googles-plugging-that-potential-android-personal-data-leakage-right-now


----------



## Kid_Eternity (May 18, 2011)

Apparently they've plugged the contacts and cal thing but not the photo thing?


----------



## magneze (May 18, 2011)

Surely the easiest fix is shortening the authentication token life. 14 days is way too long.


----------



## editor (May 19, 2011)

So, backslaps all round for Google after acting so quickly:



> "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."
> ...


----------



## Kid_Eternity (May 19, 2011)

Should they be congratulated for fixing something they allowed out there? Does Apple deserve backslaps for fixing the location thing in a reasonable amount of time too?


----------



## editor (May 19, 2011)

Kid_Eternity said:


> Should they be congratulated for fixing something they allowed out there? Does Apple deserve backslaps for fixing the location thing in a reasonable amount of time too?


It's reasonable to acknowledge a company acting particularly swiftly to fix a security hole. Seeing as you've brought up Apple, they were certainly slower to react to the location issue - they took a week to even _acknowledge_ it  - and they have something of a reputation for being rather leisurely to respond in similar cases: 
http://www.wired.com/gadgetlab/2011/04/apple-crisis-management/

But this thread isn't about Apple.


----------



## fractionMan (May 19, 2011)

magneze said:


> Surely the easiest fix is shortening the authentication token life. 14 days is way too long.


 
it's user experience/security balance.  They don't want to force people to log in very often.


----------



## magneze (May 19, 2011)

fractionMan said:


> it's user experience/security balance.  They don't want to force people to log in very often.


Android phones don't force you to sign in every 2 weeks, although under the hood they probably do it seems from that diagram. So this sounds like it was a speedup to stop your phone having the reauthenticate more often.

Maybe they should make the auth process faster rather than have tokens hanging around for 2 weeks. Lazy buggers.


----------



## mauvais (May 19, 2011)

It doesn't matter how long/short the period is - if someone is going to the trouble of eavesdropping, they are likely to use it there and then.

As for reauthentication, to use this again:






Step 1 can happen as little as once, through you adding your Google account on the phone. Step 2 has to happen every 14 days or more, and steps 3-6 are optional, so this is essentially transparent to all but developers. Long periods mean that developers don't have to worry so much about the token changing - best practice to handle it, but I bet most don't.


----------



## lobster (May 23, 2011)

It is now possible to fake and revoke app permissions.


----------



## editor (May 23, 2011)

lobster said:


> It is now possible to fake and revoke app permissions.


So long as you undertake the following on a rooted phone  first:





> In order to activate the functionality, you’ll need to navigate to CyanogenMod Settings, then Permissions, and finally Enable Management. From there, permissions can be enabled or disabled through the Settings -> Applications -> Manage Applications menu. Most permission changes will go live immediately. Enabling "Network Communications" will require a reboot.


----------

