Mobile app platform provider Parse is reporting having discovered a major security hole in the Facebook Android SDK. The problem was quickly patched after being reported to Facebook, but that alone may not be enough to secure affected mobile applications, the company says.
The security vulnerability affected all apps using the Facebook Android SDK, including major apps like Foursquare, and there’s no way for end users to know which app developers, outside the big ones, have implemented the fixes needed to secure users’ data. (Except for Foursquare, which we know to be patched – whew!)
Parse, for those unfamiliar, offers a mobile platform that enables developers to add scalable backend services to their applications. One of the tools the company provides makes it easier to add Facebook support to their Android apps. When used, developers can show a Facebook authentication flow to users, allowing users to sign into an app with their Facebook credentials.
To implement the feature, Parse uses Facebook’s Android SDK to get its authorized access token from the social network. This gives app developers the ability to perform common social actions on behalf of the app’s users, like posting to their Facebook Wall, for example, or accessing their Facebook profile data or friend list. Nothing malicious, of course, as the user is in control and can revoke the app’s permissions whenever they want.
Parse engineer David Poll explains via blog post how he spotted the vulnerability. Android developers often use logcat, a diagnostic log that apps and system processes can write to, he says. This is actually an executable that can run on a developer’s PC and device. Applications can capture its log for debugging purposes, which, when combined with bug or crash reports, can help developers get to the meat of a problem in an app’s code.
Again, nothing odd or malicious.
However, when working on adding Facebook integration to Parse, Poll noticed something strange: a line appeared in the logcat viewer which basically showed the entire access token that had been just granted after logging in, encoded in a URL.
But Poll’s first thought was that the token was only viewable to them, even though they knew that logcat was essentially a public diagnostic bulletin board for Android apps. But to be sure, Poll tested to see if he could discover other apps (like Foursquare) that also use the Facebook SDK to see if they showed the same thing.
And they did.
Next, Poll used an Android app called CatLog (it lets you view logcat files), which let him see the same line of code without first debugging the app.
Uh-oh.
For those that don’t follow the above dev speak, what this all means is that anyone could write a simple app that scraped the output from the Facebook SDK and steal access tokens from the user of the device.
So Poll did that, too.
And yep, his “FacebookThief” proof-of-concept app worked, running in the background, snagging user tokens.
“In less than 20 lines of non-boilerplate code, I could masquerade as any Facebook user that logged into any app on the device that used the Facebook SDK,” explains Poll. “It wouldn’t even be clear that my app was the culprit. If my app posted to a user’s profile using the stolen access token, it would show up as though it came from the application from which it was stolen!”
And why is this bad? Because with the access token, a malicious app developer could then access the Facebook API and pull down personal data for the Facebook user whose token they had grabbed.
Parse was worried about what this meant for their own developer community. “By using an unmodified version of the Facebook SDK with Parse, we were exposing our developers and their apps’ users to the same vulnerability – something with potentially broad repercussions,” says Poll.
As for Facebook’s response to the reported vulnerability – no complaints here. The issue was patched within 24 hours, and Parse quickly updated to use the new SDK with its platform.
So maybe it sounds like this whole story is sort of a non-starter? Security hole gets patched in a day. Nothing to see here, move along?
But it’s not really a story about Facebook security. Facebook handled the situation as professionally as possible.
There’s a greater issue to be examined here about developers using SDKs and apps over-reaching when asking permissions to run.
Facebook (or any SDK maker, really), doesn’t have a way to push updates into developers’ apps. Instead, developers have to be proactive and manually pull down the latest Facebook SDK, incorporate the new version into their apps, and then push out updates through the app store.
Meanwhile, users are unknowingly exposed to security issues simply because they haven’t updated their apps, or worse, because a developer hasn’t yet addressed the issue on their end.
This particular issue happened in February, and Parse was asked to wait to disclose the issue until Facebook could work with major app developers to get app updates pushed out. Foursquare, you’ll be glad to know, is fixed.
However, Poll says ominously, “there are still some major apps out there that display this vulnerability.”
Which ones, we asked?
“I honestly don’t know,” says Poll. “We worked with Facebook to make sure that the major apps had fixed this issue before disclosure, and I know Facebook has sent a broad email to all developers with Android apps on their platform asking them to update their Facebook SDKs. I’m not even sure if Facebook has a way of knowing how many apps are still out there with this issue…”
Facebook, however, confirmed that it has reached out to all major app makers to get their code resolved, and it does have ways to tell that which apps are patched or not. But its response is being determined by how serious a problem this issue really is.
Users are only vulnerable if they have a previously installed malicious application on their system that they have granted the “Read Sensitive Log Data” extended permission. Users can protect themselves by downloading the latest version of their applications and uninstalling any untrustworthy apps. Due to the responsible reporting of this issue to Facebook, no one within the security community has evidence of an application abusing this vulnerability. We have provided a bounty to the team to thank them for their contribution to Facebook Security.
Poll suggests that, for starters, users should update their apps. But also be careful when granting an app permission which it doesn’t need. Applications that request the “Read Sensitive Log Data” permission have the potential to access private data, so only grant that permission to those you trust, he says.
Frankly, while accurate, I worry about these suggestions. On platforms where apps auto-update, great, that part is handled. (Ahem, Apple – listening?). However, asking users to read complicated and confusing dialog boxes and then make judgement calls based on what’s displayed sounds like a recipe for failure.
Really, it’s up to the mobile ecosystem itself to figure out a safer way to manage issues like this on the developer side. For what it’s worth, that’s what Poll says Parse is working on (as, I would imagine, are their competitors). The company tries to future-proof its design by reviewing code for any area where there’s potential for information to be exposed, he says, and it continually adds new features to the SDK to push developers to upgrade.
But at the end of the day, getting a developer to upgrade their SDK still involves a lot of manual outreach, it seems. Meanwhile, Android still need to think for themselves about every app they install by carefully reading the permissions. Depending on where you stand on things, that situation is either better or worse than Apple’s system, where apps just steal your data because users blindly trusted Apple to weed out the bad ones.