

Discovering a Major Security Hole in Facebook's Android SDK - depoll
http://blog.parse.com/2012/04/10/discovering-a-major-security-hole-in-facebooks-android-sdk/

======
dude_abides
_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!

~~~
dirkdk
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
[http://developer.android.com/reference/android/Manifest.perm...](http://developer.android.com/reference/android/Manifest.permission.html#READ_LOGS)

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...](https://play.google.com/store/apps/details?id=com.nolanlawson.logcat&hl=en)
\- 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...](https://play.google.com/store/apps/details?id=com.sirma.mobile.bible.android)
-> Why does a Bible need to read from system logs?)

~~~
fpgeek
The Bible app is particularly strange because they explain some of the other
permissions they use, but not why they need access to system log data.

~~~
joelhaasnoot
There are more apps out there that use this permission to submit crash reports
and logs to the developer for debugging. The Bible app probably has a large
enough scale, high adoption rate, and enough moving parts to make for a bad
app if they didn't get that feedback.

Edit: Have this app, contributed some translations. This app is pretty popular
across many countries and locales, meaning the crash reports are essential for
good user experience.

~~~
fpgeek
Yeah, that's something that should be fixed in Android, IMO. You shouldn't
need system log permissions to capture a crash report - the OS should give you
a standard way to say "I want crash reports" (might be as simple as an email
address to send to). After a crash, the user should be given a dialog from the
system (not the app) about whether or not they want to send the crash report
data. I thought I'd seen something like that in the past, but it might have
only been for system apps or something.

~~~
tesseract
In some kinds of apps there can be issues that are not necessarily crashes,
but where a log from the user's system is still helpful in diagnosis. Perhaps
the answer is to make an app's own log and relevant system logs - but not the
logs of other apps - available to that app.

~~~
fpgeek
Good point, though the more I think about it the issues are tricky. Access to
the app's own log seems like a reasonable convenience (since the app could
have recorded that anyway). On the other hand, there are cases I can see (e.g.
confidential documents in a word processor) where you don't want the app
developer to have access to everything you do with the app (which is what
giving access to the app's own log can easily turn into).

The nice thing about the crash reporter case is that even if the crash report
is ready-to-go the user still gets to decide whether or not to send it, so
they still have direct control. Perhaps the right line would be an "own log"
permission.

------
po
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/...](https://docs.djangoproject.com/en/dev/howto/error-
reporting/#filtering-sensitive-information)

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

~~~
objclxt
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
and yet, accidents happen. Sometimes it is not wrong to use overlapping
security measures.

[edit: unintentional use of slang]

~~~
pacaro
"Defense in depth" is the usual phrase.

"Belt and suspenders" means something totally different in British and
Commonwealth English - the mind boggles.

------
codesuela
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

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

~~~
mbell
>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.

------
stuartrexking
Well done. Handled like a boss on both sides.

------
mirsadm
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 ;)

------
alanbyrne
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!

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

------
jyap
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>

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

~~~
tptacek
This comes up _all the time_ in mobile app reviews. It is probably the #1 or
#2 unique-to-mobile security flaw.

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

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

