Discovering a Major Security Hole in Facebook's Android SDK | Hacker News Reader

Discovering a Major Security Hole in Facebook's Android SDK

blog.parse.com

139 pointsdepoll40 comments

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!

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.

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

);

OCD kicking in.

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

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!

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?)

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.

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.

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.

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.

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.

You are absolutely correct: Google already provides substantial crash details if you opt in, including all system log entries from your own app.

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.

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.

Err... so you're okay with typing your username and password into a personal computer running software configured under another person's control? That's about as far away from "trusted" as possible.

The author describes getting into other folks' FB accounts by having them log in on his own device. Not their own devices.

You've misunderstood the exploit. Logging into someone else's phone is an artifact of the test (because clearly he's not going to push a malicious app to the market!), not a requirement for the exploit. Any app with the log reading capability can do that. And any app can request that capability. As pointed out elsewhere there's a Bible app that does it.

I follow the issue of defeating the purpose of the sandbox -- the token is sent to a log where other apps can read it, so an app that has "read sensitive log files" and "access network" rights could run amok over the user's FB. The article goes on to describe getting access to other folks' accounts, but only after convincing them to enter credentials. But there are already plenty of drawbacks to installing malicious apps on your own smartphone, and lots of reasons not to enter credentials on some random device.

I still cannot follow your line of thought.

If a user had FourSquare (or Parse) installed during the time of the vulnerability, that exploit would've worked. Maybe hidden in an obscure (partly useful? Wallpapers of a hot movie at that time?) and simple app.

Although the user 'just' logged in to known apps and services on his very own device. So your argument about not entering credentials on random devices seems off to me. The one about not installing each and any application out there is correct and spot on, of course.

> Amazing how this code passed code review!

This statement presupposes that a code review took place.

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

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

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.

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

[edit: unintentional use of slang]

"Defense in depth" is the usual phrase.

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

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

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

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

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.

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

Well done. Handled like a boss on both sides.

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

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!

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.

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

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

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

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

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.

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

Reply on news.ycombinator.com