Discovering a Major Security Hole in Facebook's Android SDK

http://blog.parse.com/2012/04/10/discovering-a-major-security-hole-in-facebooks-android-sdk/

by depoll • 14 years ago

139 40 14 years ago

blog.parse.com

Well done. Handled like a boss on both sides.

codesuela• 14 years ago

you can hate Facebook all day but the handling of this issue shows that they have very good understanding of how to deal with exploits reported by white hats

drivebyacct2• 14 years ago

I'm no security expert but people seem to be quite happy to output all sorts of data to the Android log.

seanalltogether• 14 years ago

The iPhone log is also globally accessible to any running app, so be careful what you're writing to it in production code.

objclxt• 14 years ago

It's just laziness on the part of developers: it's trivial (on both platforms) to have your logging disabled or filtered on production builds.

aiscott• 14 years ago

and yet, accidents happen. Sometimes it is not wrong to use overlapping security measures.

[edit: unintentional use of slang]

nupark2• 14 years ago

Or, rather, simply never commit code that logs authentication credentials, in production or otherwise.

alanbyrne• 14 years ago

There are also a lot of web sites that store that same access token in plain text cookies...

Well done for discovering the hole and the way you handled it. Glad to see you wearing that white hat!

dude_abides• 14 years ago

Log.d("Facebook-authorize", "Login Success! access_token=" + getAccessToken()

This is not wolf in sheep's clothing, it is wolf in wolf's furry clothing. Oauth access token is pretty much as powerful as a password, and it is being written to debug log here. Amazing how this code passed code review!

inlined• 14 years ago

It's probably a shame that the technology is abbreviated OAuth(orization) because people think OAuth(entication) and forget to handle the string with the reverence it needs.

depoll• 14 years ago

;) Fair enough. At least we agree that it's a wolf!

twiceaday• 14 years ago

);

OCD kicking in.

ktizo• 14 years ago

Is that like a wolf squared, or is it just a really emphatic wolf that looks pretty pissed?

dirkdk• 14 years ago

the fact that my Android app can read log statements of other apps is also helping creating this security hole. Sandbox each app I would say!

huggyface2• 14 years ago

http://developer.android.com/reference/android/Manifest.perm...

This was a similar issue with the CarrierIQ thing. Apps have to explicitly request this permission, and it's a strange one that should raise red flags unless it is explicitly intended for such a purpose.

Indeed, the app that the author links to - https://play.google.com/store/apps/details?id=com.nolanlawso... - under permission there's the READ SYSTEM LOGS.

Sadly a ridiculous number of apps demand it for questionable reasons (for instance https://play.google.com/store/apps/details?id=com.sirma.mobi... -> Why does a Bible need to read from system logs?)

sk5t3• 14 years ago

At least in OAuth 1.0a, the access token is only useful if you also know the consumer secret (provided the PLAINTEXT signature method is not in use). Of course, the consumer secret probably isn't difficult to fish out, and besides, this 'attack' relies on the user typing his password into an untrusted device... so, yeah.

ajross2• 14 years ago

What? It relies on the user typing his password into a personal smartphone that just happens to have a trojan app installed. How much more "trusted" can you get? Relying on users never to install malicious software is not a valid security model (as witnessed by decades of experience in the PC market), and I'm shocked that you think so.

bitops• 14 years ago

> Amazing how this code passed code review!

This statement presupposes that a code review took place.

mirsadm• 14 years ago

I've seen this myself while using the Android Facebook SDK (which is quite poor). I'm still debating with myself whether the article overstates the implications of this issue though.

To really make use of it you'd need to create an Android service which extracts/parses the logs from logcat when the device is awake. Then when you find an access token you'd need to try a few opengraph requests to see what permissions you have for that particular token. I suppose such an app could do damage but it does depend on a lot of circumstantial events. But I guess most exploits do.

Edit: You may as well just ask for the READ_CONTACTS permission and take the entire data from there ;)

ig1• 14 years ago

Reading this my first thought is: What other Apps/SDKs are vulnerable to the same issue ?

tptacek• 14 years ago

This comes up all the time in mobile app reviews. It is probably the #1 or #2 unique-to-mobile security flaw.

idunno246• 14 years ago

"Any Android application that has the "READ SENSITIVE LOG DATA" permission has access to this data."

Is the user prompted for this(don't have android)? Seems pretty explicit.

cgranade• 14 years ago

Yes, the user is prompted on install. This is actually one of the permissions I look for when I'm installing new apps, given how often it's abused.

mbell• 14 years ago

>Is the user prompted for this(don't have android)? Seems pretty explicit.

Explicit to you, I and the majority of the HN readership. However, I'd venture that the vast majority of users have absolutely no idea what that means. It may as well be gibberish.

po• 14 years ago

If you are a Django developer, please be aware of (and use) the capability to mark data as sensitive to exclude it from error reports. Most people won't need this feature since very often as you don't often define your own new sensitive variables, but it's important to know that it is there:

https://docs.djangoproject.com/en/dev/howto/error-reporting/...

jyap• 14 years ago

This is similar to something I reported to Flipboard for iOS where I noticed device log files showed the failed login password attempts in clear text.

https://gist.github.com/2327073

Shank• 14 years ago

Having used Logcat for a lot of development, I feel like everyone dumps sensitive data there. CarrierID did, Facebook's API did, and a few others did as well (notably Qik specifically sent API keys every ~30 seconds, but patched it later).

djb_hackernews• 14 years ago

Nice catch, but something tells me if this hole were exploited, it'd be easily and quickly shut down.

The next question is, I'm guessing most apps store the access token somewhere for future use, is there a permission that apps can have that let them at this storage? Hope the FB SDK encourages safe handling (encryption, etc) of the access token.

mattgmg1990• 14 years ago

Sure, Facebook fixed it, but there are probably hundreds of apps on the market that are using older versions of the Android SDK. A lot of independent developers might not be upgrading their apps regularly, much less realize that Facebook added an important security update to the Facebook Android SDK. ...This problem could affect apps for some time to come.

Discovering a Major Security Hole in Facebook's Android SDK

Related Stories