10 ms·

Discovering a Major Security Hole in Facebook's Android SDK

139 points by depoll 15y ago

stuartrexking 15y ago
Well done. Handled like a boss on both sides.
codesuela 15y 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
- deleted 15y ago
  [deleted]
drivebyacct2 15y ago
I'm no security expert but people seem to be quite happy to output all sorts of data to the Android log.
seanalltogether 15y 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 15y 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 15y ago
    and yet, accidents happen. Sometimes it is not wrong to use overlapping security measures. [edit: unintentional use of slang]
    - pacaro 15y ago
      "Defense in depth" is the usual phrase. "Belt and suspenders" means something totally different in British and Commonwealth English - the mind boggles.
- deleted 15y ago
  [deleted]
- nupark2 15y ago
  Or, rather, simply never commit code that logs authentication credentials, in production or otherwise.
alanbyrne 15y 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 15y 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 15y 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 15y ago
  ;) Fair enough. At least we agree that it's a wolf!
  - deleted 15y ago
    [deleted]
- twiceaday 15y ago
  ); OCD kicking in.
- ktizo 15y ago
  Is that like a wolf squared, or is it just a really emphatic wolf that looks pretty pissed?
- dirkdk 15y 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!
  - huggyface 15y ago
    http://developer.android.com/reference/android/Manifest.permission.html#READ_LOGS 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.nolanlawson.logcat&hl=en 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.mobile.bible.android https://play.google.com/store/apps/details?id=com.sirma.mobi... -> Why does a Bible need to read from system logs?)
mirsadm 15y 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 15y ago
Reading this my first thought is: What other Apps/SDKs are vulnerable to the same issue ?
- tptacek 15y ago
  This comes up all the time in mobile app reviews. It is probably the #1 or #2 unique-to-mobile security flaw.
idunno246 15y 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.
- deleted 15y ago
  [deleted]
- cgranade 15y 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 15y 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 15y 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/#filtering-sensitive-information https://docs.djangoproject.com/en/dev/howto/error-reporting/...
jyap 15y 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 https://gist.github.com/2327073
Shank 15y 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 15y 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 15y 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.

139 points by depoll 15y ago

Well done. Handled like a boss on both sides.

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

deleted 15y ago
[deleted]

drivebyacct2 15y ago

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

seanalltogether 15y 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 15y 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 15y ago
  and yet, accidents happen. Sometimes it is not wrong to use overlapping security measures. [edit: unintentional use of slang]
  - pacaro 15y ago
    "Defense in depth" is the usual phrase. "Belt and suspenders" means something totally different in British and Commonwealth English - the mind boggles.
deleted 15y ago
[deleted]
nupark2 15y ago
Or, rather, simply never commit code that logs authentication credentials, in production or otherwise.

alanbyrne 15y 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 15y 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 15y 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 15y ago
;) Fair enough. At least we agree that it's a wolf!
- deleted 15y ago
  [deleted]
twiceaday 15y ago
); OCD kicking in.
ktizo 15y ago
Is that like a wolf squared, or is it just a really emphatic wolf that looks pretty pissed?
dirkdk 15y 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!
- huggyface 15y ago
  http://developer.android.com/reference/android/Manifest.permission.html#READ_LOGS 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.nolanlawson.logcat&hl=en 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.mobile.bible.android https://play.google.com/store/apps/details?id=com.sirma.mobi... -> Why does a Bible need to read from system logs?)

mirsadm 15y 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 15y ago

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

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

idunno246 15y 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.

deleted 15y ago
[deleted]
cgranade 15y 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 15y 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 15y 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/#filtering-sensitive-information https://docs.djangoproject.com/en/dev/howto/error-reporting/...

jyap 15y 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 https://gist.github.com/2327073

Shank 15y 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 15y 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 15y 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.