App updates may not seem like a big deal. Sure, they fix bugs and provide fun stuff like new features and enhanced user interfaces. But they can also patch potentially serious security holes.
Case in point: a recent Facebook vulnerability found in the company’s Android software developer kit (SDK). A developer for San Francisco-based mobile cloud service provider Parse stumbled across some peculiar activity in his code and did some digging. As it turns out, that code could have been extraordinarily painful for developers, users, Facebook and any app that uses its SDK. Only an app update could keep that from happening.
Where It Came From
Parse developer David Poll was working on the Facebook features for the company’s Android client when he noticed that a certain line of code was showing the entire access token in his “logcat” viewer. Logcat is a common Android debugging tool that tracks what applications and system processes can write.
Facebook also apparently uses logcat. Whenever Poll logged into his test application through the Facebook SDK, he got this line of code:
This wasn’t a problem as long as it was only Poll’s logcat and he was the only one that could see it. So Poll tested a couple other applications from large developers like Zynga and Foursquare – and found the same line!
Poll knew that there was an Android on-device logcat viewer called CatLog that let developers see logcat information while debugging an application. Poll figured that he could write a simple app that could scrape the output of the Facebook SDK to steal Facebook access tokens from the device.
This could be a big problem. If you can scrape the Facebook SDK for access tokens, you basically have full permission to do as you please with that person’s login information. A developer with malicious intent could spam a user’s Facebook profile or carry out any other sort of bad behavior – and the culprit would look like the app that had been hacked, not the user or the token thief. Imagine how embarrassing it would be if it looked like Foursquare was posting spam and spyware to Facebook through an unknowing user’s app!
Poll created a proof-of-concept app that he called “FacebookThief.” With 20 lines of code, the app could “masquerade as any Facebook user that logged into any app on the device that used the Facebook SDK.” Poll and Parse reported the issue to Facebook (and were paid through Facebook’s “bug bounty” program). Within 24 hours, the issue was fixed and Parse was able to integrate the new version of the SDK into its service.
Lots of Lessons
This scenario offers lessons for both consumers and developers.
As Poll points out in Parse’s blog post, the Facebook Android SDK is, “software that runs on the client and is built into other applications, so Facebook has no real way to push this update out to all of its developers.”
Developers need to download the new version of the SDK and manually implement it and then resubmit their apps to various app stores. There is no guarantee that app publishers are going to do that either because they have stopped supporting the app in question or are just lazy (yes, there are lazy developers out there).
Relying on third-party client SDKs means that you are running someone else’s code in your app. When there is a problem with that SDK, you are at the mercy of that client. Facebook is fairly responsive when it comes to updating its developer tools. Other companies are not. Before you use third-party SDKs, ask yourself if you trust the provider of the software and make sure it is responsive to bugs and can quickly iterate patches.
Ultimately, the Facebook Android SDK exploit came down to one line of code:
Another lesson for developers: There are right ways and wrong ways to announce security vulnerabilities in other companies’ software. In this case, Parse notified Facebook in February and respected the social platform’s wishes not to make the bug public until now. Facebook worked with major publishers to update their apps before allowing Parse to announce the bug.
The lessons for users are simple:
1. Make sure you know what permissions your Android app is requesting.
2. Make sure to keep your apps up-to-date.
In this case, any application that has “READ SENSITIVE LOG DATA” has the ability to obtain the access tokens in the Facebook SDK. “There are legitimate reasons to request this permission, but users should be wary of any app that requests this permission unnecessarily,” Poll wrote.
While Facebook has squashed the bug, that does not mean it has been eradicated. It still exists in Android apps using the old Facebook SDK. It also exists on users’ devices that have not updated apps from publishers who have fixed the hole.
The ultimate lesson here is that you can never be too careful. That goes for developers and consumers. The only way to avoid these kinds of vulnerabilities is to be diligent: for developers in how you write your code, and for consumers in how you approve permissions with the apps you update.
Update — Fred Wolens of Facebook’s policy communications team:
We applaud the security researchers who brought this bug to our attention for responsibly reporting the bug to our White Hat Program. We worked with the team to make sure we understood the full scope of the vulnerability, which allowed us to fix it and get an updated SDK in the hands of developers without it being exploited. 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.
Images courtesy of Shutterstock.
