Share this story

A recent scan of the Google Play market found that Android apps contained thousands of secret authentication keys that could be maliciously used to access private cloud accounts on Amazon or compromise end-user profiles on Facebook, Twitter, and a half-dozen other services.

The finding is the result of PlayDrone, a system that uses a variety of hacking techniques to bypass security measures intended to prevent third parties from crawling Google Play. The brainchild of computer scientists at Columbia University, PlayDrone comprehensively indexed Play contents, downloaded more than 1.1 million apps, and decompiled more than 880,000 of them. It is believed to be the first large-scale measurement of the sprawling Google marketplace, which offers more than one million apps and has fostered 50 billion app downloads to date.

One of the most surprising observations PlayDrone made was that many apps contain secret authentication keys that can compromise accounts belonging to both developers and end users. Source code for the official AirBnB app, for example, included secret OAuth tokens for Facebook, Google, LinkedIn, Microsoft, and Yahoo. The credentials were supplied by the service providers and act as a skeleton key of sorts that allows an app to access private account data for each user. By plucking them out of the AirBnB app, an attacker could use it to read and possibly modify or add data for millions of users' profiles.

The Columbia University researchers, for instance, were able to access the e-mail and friends lists of AirBnB users by plugging the Facebook OAuth token into this URL. Fortunately, the AirBnB app didn't have permission to post to users' walls, so attackers wouldn't have been able to add or modify content. The researchers notified Facebook of their discovery, and in a matter of hours, AirBnB published an app update that no longer contained the secret tokens. The incident, however, underscores the risks posed by unsound practices of Android app developers.

"The risk due to exposure depends on the service provider, but significant user data can be exposed," Columbia University PhD candidate Nicolas Viennot wrote in an e-mail. "For example, Facebook allows user level requests without the access_token of the given user. Just the app credentials are needed, as we explain in our paper. This can be disabled in the application settings page, but it is enabled by default. AirBnB app credentials were exposed in their app and as a result, we were able to access AirBnB users' private information without the user level tokens, and AirBnB has a huge user population!"

Cloud-based botnets

PlayDrone also uncovered secret tokens used to access app developer accounts for Amazon Web Services (AWS) and other cloud services. Of the 308 unique AWS tokens found during a June 2013 scan, most were root-level credentials that provided virtually unfettered access to all services, including creating and shutting down Amazon Elastic Compute Cloud (EC2) instances, browsing, or modifying stored data. To the surprise of the researchers, 288 tokens remained valid during a scan five months later.

"With 288 valid tokens, an attacker could potentially set up a botnet of AWS EC2 instances," the researchers wrote. "While AWS has a number of mechanisms to thwart such activities, usage patterns on AWS are elastic and inherently unpredictable, which may make it hard to detect stolen resources. Unless billing alerts are manually configured, billing statements will not reflect usage until the end of the billing cycle."

The researchers privately alerted Amazon to the discovery, and the service alerted affected customers. The researchers also privately informed Google officials, who said they planned to add checks for embedded keys and automated notices to developers as part of the Play application publication process.

The Columbia University researchers' academic paper released this week focused on apps found in Google Play during a single day in June 2013. Given the response from Amazon and other affected services, it's likely that most or all of that improperly embedded information has been removed. But it's also possible that additional secret keys have subsequently been put into apps that have been published or updated since the 2013 snapshot was taken.

PlayDrone uncovered other interesting facts about Google Play. For instance, a small percentage of free apps account for almost all downloads. The crawler also found that a quarter of Google Play contains "duplicative application content." Now that the research has become public knowledge, it will be worth watching to see if Google Play will include changes that prevent it from being crawled by PlayDrone or similar engines.

Promoted Comments

Can that happen on apps from other systems or it a thing that developers can use only on Android?

All apps, definitely.

I work at a large-ish tech company and am part of the team launching a new API that uses OAuth just like other big APIs like Twitter's, Facebook's, etc.

The problem is, developers are lazy. Private keys are supposed to never be put in a client app, but should instead live in a server-side app that helps with authentication. Developers don't want to host server-side services just to log in to Facebook - they just want to paste in a key and get going.

We've shipped our API for iOS in a manner that pushes the developer down the path of hosting a server-side service for the private key instead of pasting it into their app, since we'd value our users' security (for the reasons stated in this article) over giving developers an easy ride. Unfortunately, our new iOS API that does this has only been out a very short amount of time and we're already getting a lot of push-back.

It's a tough line to draw, really. We want our platform to be easy enough to use that we don't scare developers away, but we REALLY don't want the developers pasting in unobfuscated private keys into their apps, so we're taking the hit.

As an app developer, most of the oAuth style logins say not to hardcode your secret items into your app, instead 'putting them on a server you own'. As a small time developer that is far and above in terms of costs and complexity for the small apps I develop. I'm going to bet that's why a lot of people have them hard coded as well. Not sure about storing end-user tokens though.

Hats off to the researchers at Columbia University for demonstrating and ethical and thoughtful approach to this entire process, especially how they informed vulnerable parties.

I know some people think screaming from the rooftops might somehow expedite things, it is pretty much always the wrong approach. If informed individuals did not take due action by the time the paper was published, then it is all on them.