Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
99% of Android phones leak secret account credentials (theregister.co.uk)
81 points by joeshaw on May 17, 2011 | hide | past | favorite | 11 comments


As the post below says, this may not actually be an important leak. But, it does highlight the issues with the "fragmentation" issue in a much more real way than we've seen before.

What happens to all these Android handsets sold that don't get updated if a major security hole is found in Android 2.2? Almost none of them have official upgrade routes to 2.3 at this point, and I find it hard to imagine that they would be able to get out a 2.3 release to fix security hole in a reasonable amount of time if they haven't been able to get it out in general for about six months now.

I obviously hope there isn't any security holes that are discovered. But it would be interesting to see how the Android vendors would react to that situation — especially if it was something Google couldn't fix easily in an Android Market-distributed patch, like the "malware" earlier this year.

(Apple is no better here, fwiw: the iPhone 2G was excluded from any fix to the remote "JailbreakMe" exploit, and the iPhone 3G never got any fix to the location "tracking" controversy.)


If there was a major security hole in 2.2, I expect there'd be a patch for 2.2 that'd get pushed out as an urgent update.


As it came to light during previous instances: there are different types of updates deployed by the carries and device makers that vary in urgency, one type is 'critical' updates that get deployed quickly, all the phones don't have to be running the latest version to be patched.


Oh for the love of God.

This just in, 99% of websites on the Internet leak secret account credentials. Can we please ban The Register here?

Account credentials != Auth Token. And this is a result of not using SSL to share the auth token back. Is it a mistake? Yes. Is it nearly as bad as this headline or the article implies? No.


(I work for Mozilla, but no real bone to pick here)

I dunno dude, that looks pretty bad. Isn't this kind of exposure fodder for the wall of shame at every hacker conference? If The Register is accurate[1], the token will expire in 14 days, but that's plenty of time to read lots of email.

Hopefully they can fix it on the server. Otherwise, it'll take a while to update all of those Android devices.

[1] I know, I know


It is bad and it's trivial to fix and it should have been obvious. But it's not leaking your username/password like the title implies (at least to me).

This is just like logging into ANY website without using SSL... except that it's much more likely that they're on 3G since it's a mobile device rather than a laptop.


It's trivial to fix, then?

Can this issue be fixed by changing the server? Otherwise this trivial fix will take a long time to deploy.


Well, trivial from a code perspective. I would presume that attempting to fix it from the servers would not work, unless they can 302 to an SSL server, but I don't know exactly how that would work, if ClientLogin can handle that.

Additionally, as noted elsewhere, security fixes are distributed to more devices and faster than os upgrades for Android devices.


So let's summarize:

1. The AuthToken's are easy to sniff

2. Hard for the end user to fix and require code changes to fix completely which may not be available for your model of phone from your carrier

3. Valid for 14 days

4. "the adversary can subsequently use the captured authToken to access any personal data which is made available through the service API. For instance, the adversary can gain full access to the calendar, contacts information, or private web albums of the respective Google user. 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."

And in conclusion not a big deal and we should ban the register for spreading such vicious truths.

And we know all of this because of our love of god.


Even if they can modify the server to 302 to an HTTPS URL, that still wouldn't prevent MITM. An attacker could still intercept the HTTP request and forward on to the HTTPS URL.

It would have some value because it would prevent passive sniffers, but it wouldn't be a complete fix. The fix needs to be on the client side.


El Reg is link-baiting again. They are hardly 'leaking account credentials'.

A patch could be pushed separately, the phones don't all have to get 2.3.4 to fix a venerability, they've done so before.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: