6 ms·

Thousands of secret keys found in Android apps

58 points by matlecu 12y ago

kareemk 12y ago
Blog post by the author of PlayDrone: http://velvetpulse.com/2014/06/18/a-measurement-study-of-google-play/ http://velvetpulse.com/2014/06/18/a-measurement-study-of-goo....
lostmsu 12y ago
What are the alternatives? You have to ship secret keys with your app to be able to access public APIs
- matlecu 12y ago
  Some APIs should be accessed from your backend, not the app (eg the user can authorize you on Facebook without you sharing your API app secret). The paper also says they found amazon tokens, with which you can spawn instances. I think you can use other kind of authentication that don't give access to the whole account.
  - girvo 12y ago
    What if you app doesn't have a backend? That's an honest question, I've been trying to come up with some way of using authe/autho keys on a fully client-side app (be it a mobile or desktop one) that is still secure; I can't think of a way to, as to communicate it requires the keys to be in memory, thus, vulnerable. I dunno. I've wondered about all this myself quite a lot, perhaps its a non-issue?
    - matlecu 12y ago
      Yes I don't know of any good solution for client side only applications. And it's a real issue I think. For instance if I have your key, it may be possible for me to access data, post on behalf, etc... of people who signed in with the service on your application
    - AUmrysh 12y ago
      I think your only choice for doing this securely is to hide the keys behind your own server.
  - cheald 12y ago
    AWS keys should belong to IAM users who have constrained permissions to only perform the things you want them to perform. If you're shipping root account AWS keys in any app, you're doing it wrong.
- garraeth 12y ago
  I know at least with Google you can authenticate "cross-client": https://developers.google.com/accounts/docs/CrossClientAuth https://developers.google.com/accounts/docs/CrossClientAuth Best writeup for Google I've found: http://www.riskcompletefailure.com/2013/10/google-android-client-server-sign-in.html http://www.riskcompletefailure.com/2013/10/google-android-cl... (author talks about "PlusClient" which is now deprecated in favor of "GoogleApiClient", but other than that, the article is accurate - but missing server-side details). It's a lot harder. So I'm guessing many devs just skip it.
- Groxx 12y ago
  Frequently: none. Well, you could proxy the request through your servers, but that could get relatively costly. Ideally: either the service allows you to generate short-lived tokens (server-side, ideally without a request to the service), or you sign requests for the client. In the latter, you generally gain some measure control over what apps can do, with relatively small cost. Basically that's what you can do with S3 file uploads - your server can generate a signed URL, then the client can upload to it, all while you retain complete control of your API secrets.
jrochkind1 12y ago
> This can mean several things, but it also means that users can never be 100 percent certain that the app they are downloading is entirely secure. I wonder in what circumstances the author thinks users can be 100% certain that the app they are downloading is entirely secure. Cause, yeah, there aren't any.
- derefr 12y ago
  Presumably, if 1. the user is side-loading an app they wrote themselves (or is an internal Apple/Google developer who uploaded an app to their app store and audited the entire sausage-making process as it transpired), and 2. the app does literally nothing, then the user can be 100 percent certain that the app does what it does securely.
  - GotAnyMegadeth 12y ago
    Only if your compiler/build process is trust worthy ;-)
pan69 12y ago
What a non article. As if iPhone apps don't have these keys in them. So, now you have those keys. What are you going to do with them? Just because you have the "app" key doesn't mean you have access to any sort data. The worst you can do is write an authentication flow with some other companies app keys, and then what? Can someone please explain what the security issue here is?
- userbinator 12y ago
  I wouldn't really consider these "keys" or "secrets", they're more like a user identifier. Having them probably means you can now write another app to access the same data... and if that was in any way considered a security issue, it wouldn't be solved by not having those identifiers in the app either. (Of course there might be some APIs that allow doing more by interacting with them directly than what the app originally allowed, but I think those are just cases of bad design.)
- kuschku 12y ago
  Some Websites require you to pay money for access to their API. Some of them also have a HTML5-App (with a wrapper) available for Android. This app uses the same API. So some malicious developer could just unzip the app, read the JavaScript and find the API-key, and use their key instead of paying for one. And as the website usually has many accesses from the same IP (due to mobile users being behind NATs), the Website will never find out that someone is abusing their API.
  - Guillaume86 12y ago
    And some websites do not have public APIs at all. I've already used this technique to "discover" the private API and the access keys, nothing sensitive and only for personal use of course.
peterkelly 12y ago
Someone should explain to the author of this article the difference between API keys and passwords/authentication tokens
web007 12y ago
Thousands of secret keys found all over the place. https://github.com/search?o=desc&q=_CONSUMER_SECRET&ref=searchresults&s=indexed&type=Code https://github.com/search?o=desc&q=_CONSUMER_SECRET&ref=sear...
bbuc 12y ago
Alexey Troshichev, "Strike to the infrastructure: a story about analyzing thousands mobile apps" ZeroNights 2013: http://2013.zeronights.org/includes/docs/Alexey_Troshichev_-_Strike_to_the_infrastructure_a_story_about_analyzing_thousands_mobile_apps.pdf http://2013.zeronights.org/includes/docs/Alexey_Troshichev_-...
deleted 12y ago
[deleted]
junto 12y ago
So this relates to the API keys used by developers to access their own backend APIs and the APIs of third parties, such as Facebook or Twitter. There are suggestions in comments here that you hide your third party API keys in your own backend server, and your app queries for the API keys and then makes the call from the client using the temporary downloaded keys. So how do you secure your own server's API keys? That's just a Russian doll implementation. I can't see a valid way to access an API key using a consumer key / secret without storing them in the application. Any suggestions?
- junto 12y ago
  Having read the paper [1], the authors suggest the following as a solution to the API key conundrum: To avoid the need of storing secret tokens on a mobile device, Facebook leverages the presence of the official Facebook Android application on Android devices. The Facebook SDK allows third-party applications to use Android intents to proxy requests for user access tokens through Facebook's Android application, where the user is already authenticated. To retrieve a user's access token with the Facebook SDK, the Android application identifier of a third-party application must be registered on its Facebook application settings page. This allows Facebook's Android application to respond to the third-party application's access token request by verifying the application identifier in the intent to the one officially registered online. Only the application identifer is needed and no secret key is compromised since it is retrieved at runtime. This technique relies on the robustness of Android since the source of the Android intent is assumed not to be spoofable. Does anyone have a clearer description of this process. I've now read this extract three times and I'm none the wiser. [1] http://www.cs.columbia.edu/~nieh/pubs/sigmetrics2014_playdrone.pdf http://www.cs.columbia.edu/~nieh/pubs/sigmetrics2014_playdro...
  - leoedin 12y ago
    Facebook require you to create an "Application" on their developers website which corresponds to your Android app. Within the settings for your Facebook application you have to register details of your Android application - the package name and some sort of information on the key it's signed with (If my recall is correct - I've not done it for about 6 months). Because you've registered this information, Facebook will only allow your app to perform actions if it not only has the correct API key but also matches the registered details. I suppose this means that if someone decompiles your app and steals your key they can't perform actions pretending to be you.
x0054 12y ago
I am surprised that more developers do not run a code scrambler on their code before compiling a release. Also, why would you name the variable where you store the key "FACEBOOK_CUSTOMER_SECRET" rather than "AKED223KWN" or something else random. And, why wouldn't you at least pad and scramble the key, so it would be a little harder to pick it out of memory.
- baby 12y ago
  security through obscurity, not a good idea.
  - x0054 12y ago
    Why not. Is security through obscurity better than nothing at all?
- lucian1900 12y ago
  That doesn't really help either, though. At runtime, the data will have to exist in memory at some point.
- Cthulhu_ 12y ago
  That's not how API keys work; scramble them and they're different. What I gathered is that the authors didn't look for glaringly obvious things like variable names, but did a more generic scan for strings or keys that look like encryption keys. Obfuscation won't help there. I don't know if it's possible to encrypt your entire codebase and still end up with a workable app - after all, the decryption would still need to be done on a potentially unsafe device.
  - x0054 12y ago
    Obviously a scrambled key wouldn't work if you try to use it subsequently in it's scrambled from. But you can store the these keys in a safer way. There are numerous ways you can obfuscate the key. For instance, convert the key to binary and store it 1 bit at a time, every 8 bits, in a bitmap log. Or think of something more elegant. Write the accessor function that pulls the key on the fly and returns a string. I know, you can still read the key our of memory, but all of the sudden you need to do a lot more work to pull it. Also, scrambling function and variable names is always a good idea, it makes reverse engineering your app a lot harder. And there are many programs on the market that will do this for you automatically.
thewarrior 12y ago
I m wondering if there is any alternative to storing API keys and tokens in the source of the app ? Proxying all calls through our own server seems like an expensive way of solving this problem. Because if the client is compromised it doesn't do much anyway.
- chr7z 12y ago
  There is a tool for moving API keys out of the source: Keystok stores encrypted API keys and tokes in a cloud service and lets the App / client retrieve them during runtime. Its not just about moving keys out of the source, but about getting rid of local config files altogether. Related post on their blog: http://blog.keystok.com/why-i-stopped-using-local-config-files-and-you-should-too/ http://blog.keystok.com/why-i-stopped-using-local-config-fil... Disclosure: I'm a developer at Keystok.
  - lucian1900 12y ago
    That is much worse, though: you're actively disclosing your API keys to a third party (keystok).
  - kuschku 12y ago
    And a developer with Apktool could still modify the app and get the keys, you win nothing with this solution.
- HarrietJones 12y ago
  Shoot me down if I'm missing something obvious here, but: One solution would be for Apple and Android to have an "environment" section for applications. You'd be able to set these environment keys when publishing the app. Apple and Android could provide an API to these environment keys, and they'd be published in an encrypted form as part of the application manifest. Bonus Points: It would be relatively simple to provide the facility from the AppStore provider for changing / cancelling these keys.
  - jaegerpicker 12y ago

58 points by matlecu 12y ago

Blog post by the author of PlayDrone: http://velvetpulse.com/2014/06/18/a-measurement-study-of-google-play/ http://velvetpulse.com/2014/06/18/a-measurement-study-of-goo....

lostmsu 12y ago

What are the alternatives? You have to ship secret keys with your app to be able to access public APIs

matlecu 12y ago
Some APIs should be accessed from your backend, not the app (eg the user can authorize you on Facebook without you sharing your API app secret). The paper also says they found amazon tokens, with which you can spawn instances. I think you can use other kind of authentication that don't give access to the whole account.
- girvo 12y ago
  What if you app doesn't have a backend? That's an honest question, I've been trying to come up with some way of using authe/autho keys on a fully client-side app (be it a mobile or desktop one) that is still secure; I can't think of a way to, as to communicate it requires the keys to be in memory, thus, vulnerable. I dunno. I've wondered about all this myself quite a lot, perhaps its a non-issue?
  - matlecu 12y ago
    Yes I don't know of any good solution for client side only applications. And it's a real issue I think. For instance if I have your key, it may be possible for me to access data, post on behalf, etc... of people who signed in with the service on your application
  - AUmrysh 12y ago
    I think your only choice for doing this securely is to hide the keys behind your own server.
- cheald 12y ago
  AWS keys should belong to IAM users who have constrained permissions to only perform the things you want them to perform. If you're shipping root account AWS keys in any app, you're doing it wrong.
garraeth 12y ago
I know at least with Google you can authenticate "cross-client": https://developers.google.com/accounts/docs/CrossClientAuth https://developers.google.com/accounts/docs/CrossClientAuth Best writeup for Google I've found: http://www.riskcompletefailure.com/2013/10/google-android-client-server-sign-in.html http://www.riskcompletefailure.com/2013/10/google-android-cl... (author talks about "PlusClient" which is now deprecated in favor of "GoogleApiClient", but other than that, the article is accurate - but missing server-side details). It's a lot harder. So I'm guessing many devs just skip it.
Groxx 12y ago
Frequently: none. Well, you could proxy the request through your servers, but that could get relatively costly. Ideally: either the service allows you to generate short-lived tokens (server-side, ideally without a request to the service), or you sign requests for the client. In the latter, you generally gain some measure control over what apps can do, with relatively small cost. Basically that's what you can do with S3 file uploads - your server can generate a signed URL, then the client can upload to it, all while you retain complete control of your API secrets.

jrochkind1 12y ago

> This can mean several things, but it also means that users can never be 100 percent certain that the app they are downloading is entirely secure. I wonder in what circumstances the author thinks users can be 100% certain that the app they are downloading is entirely secure. Cause, yeah, there aren't any.

derefr 12y ago
Presumably, if 1. the user is side-loading an app they wrote themselves (or is an internal Apple/Google developer who uploaded an app to their app store and audited the entire sausage-making process as it transpired), and 2. the app does literally nothing, then the user can be 100 percent certain that the app does what it does securely.
- GotAnyMegadeth 12y ago
  Only if your compiler/build process is trust worthy ;-)

pan69 12y ago

What a non article. As if iPhone apps don't have these keys in them. So, now you have those keys. What are you going to do with them? Just because you have the "app" key doesn't mean you have access to any sort data. The worst you can do is write an authentication flow with some other companies app keys, and then what? Can someone please explain what the security issue here is?

userbinator 12y ago
I wouldn't really consider these "keys" or "secrets", they're more like a user identifier. Having them probably means you can now write another app to access the same data... and if that was in any way considered a security issue, it wouldn't be solved by not having those identifiers in the app either. (Of course there might be some APIs that allow doing more by interacting with them directly than what the app originally allowed, but I think those are just cases of bad design.)
kuschku 12y ago
Some Websites require you to pay money for access to their API. Some of them also have a HTML5-App (with a wrapper) available for Android. This app uses the same API. So some malicious developer could just unzip the app, read the JavaScript and find the API-key, and use their key instead of paying for one. And as the website usually has many accesses from the same IP (due to mobile users being behind NATs), the Website will never find out that someone is abusing their API.
- Guillaume86 12y ago
  And some websites do not have public APIs at all. I've already used this technique to "discover" the private API and the access keys, nothing sensitive and only for personal use of course.

peterkelly 12y ago

Someone should explain to the author of this article the difference between API keys and passwords/authentication tokens

web007 12y ago

Thousands of secret keys found all over the place. https://github.com/search?o=desc&q=_CONSUMER_SECRET&ref=searchresults&s=indexed&type=Code https://github.com/search?o=desc&q=_CONSUMER_SECRET&ref=sear...

bbuc 12y ago

Alexey Troshichev, "Strike to the infrastructure: a story about analyzing thousands mobile apps" ZeroNights 2013: http://2013.zeronights.org/includes/docs/Alexey_Troshichev_-_Strike_to_the_infrastructure_a_story_about_analyzing_thousands_mobile_apps.pdf http://2013.zeronights.org/includes/docs/Alexey_Troshichev_-...

deleted 12y ago

[deleted]

junto 12y ago

So this relates to the API keys used by developers to access their own backend APIs and the APIs of third parties, such as Facebook or Twitter. There are suggestions in comments here that you hide your third party API keys in your own backend server, and your app queries for the API keys and then makes the call from the client using the temporary downloaded keys. So how do you secure your own server's API keys? That's just a Russian doll implementation. I can't see a valid way to access an API key using a consumer key / secret without storing them in the application. Any suggestions?

junto 12y ago
Having read the paper [1], the authors suggest the following as a solution to the API key conundrum: To avoid the need of storing secret tokens on a mobile device, Facebook leverages the presence of the official Facebook Android application on Android devices. The Facebook SDK allows third-party applications to use Android intents to proxy requests for user access tokens through Facebook's Android application, where the user is already authenticated. To retrieve a user's access token with the Facebook SDK, the Android application identifier of a third-party application must be registered on its Facebook application settings page. This allows Facebook's Android application to respond to the third-party application's access token request by verifying the application identifier in the intent to the one officially registered online. Only the application identifer is needed and no secret key is compromised since it is retrieved at runtime. This technique relies on the robustness of Android since the source of the Android intent is assumed not to be spoofable. Does anyone have a clearer description of this process. I've now read this extract three times and I'm none the wiser. [1] http://www.cs.columbia.edu/~nieh/pubs/sigmetrics2014_playdrone.pdf http://www.cs.columbia.edu/~nieh/pubs/sigmetrics2014_playdro...
- leoedin 12y ago
  Facebook require you to create an "Application" on their developers website which corresponds to your Android app. Within the settings for your Facebook application you have to register details of your Android application - the package name and some sort of information on the key it's signed with (If my recall is correct - I've not done it for about 6 months). Because you've registered this information, Facebook will only allow your app to perform actions if it not only has the correct API key but also matches the registered details. I suppose this means that if someone decompiles your app and steals your key they can't perform actions pretending to be you.

x0054 12y ago

I am surprised that more developers do not run a code scrambler on their code before compiling a release. Also, why would you name the variable where you store the key "FACEBOOK_CUSTOMER_SECRET" rather than "AKED223KWN" or something else random. And, why wouldn't you at least pad and scramble the key, so it would be a little harder to pick it out of memory.

baby 12y ago
security through obscurity, not a good idea.
- x0054 12y ago
  Why not. Is security through obscurity better than nothing at all?
lucian1900 12y ago
That doesn't really help either, though. At runtime, the data will have to exist in memory at some point.
Cthulhu_ 12y ago
That's not how API keys work; scramble them and they're different. What I gathered is that the authors didn't look for glaringly obvious things like variable names, but did a more generic scan for strings or keys that look like encryption keys. Obfuscation won't help there. I don't know if it's possible to encrypt your entire codebase and still end up with a workable app - after all, the decryption would still need to be done on a potentially unsafe device.
- x0054 12y ago
  Obviously a scrambled key wouldn't work if you try to use it subsequently in it's scrambled from. But you can store the these keys in a safer way. There are numerous ways you can obfuscate the key. For instance, convert the key to binary and store it 1 bit at a time, every 8 bits, in a bitmap log. Or think of something more elegant. Write the accessor function that pulls the key on the fly and returns a string. I know, you can still read the key our of memory, but all of the sudden you need to do a lot more work to pull it. Also, scrambling function and variable names is always a good idea, it makes reverse engineering your app a lot harder. And there are many programs on the market that will do this for you automatically.

thewarrior 12y ago

I m wondering if there is any alternative to storing API keys and tokens in the source of the app ? Proxying all calls through our own server seems like an expensive way of solving this problem. Because if the client is compromised it doesn't do much anyway.

chr7z 12y ago
There is a tool for moving API keys out of the source: Keystok stores encrypted API keys and tokes in a cloud service and lets the App / client retrieve them during runtime. Its not just about moving keys out of the source, but about getting rid of local config files altogether. Related post on their blog: http://blog.keystok.com/why-i-stopped-using-local-config-files-and-you-should-too/ http://blog.keystok.com/why-i-stopped-using-local-config-fil... Disclosure: I'm a developer at Keystok.
- lucian1900 12y ago
  That is much worse, though: you're actively disclosing your API keys to a third party (keystok).
- kuschku 12y ago
  And a developer with Apktool could still modify the app and get the keys, you win nothing with this solution.
HarrietJones 12y ago
Shoot me down if I'm missing something obvious here, but: One solution would be for Apple and Android to have an "environment" section for applications. You'd be able to set these environment keys when publishing the app. Apple and Android could provide an API to these environment keys, and they'd be published in an encrypted form as part of the application manifest. Bonus Points: It would be relatively simple to provide the facility from the AppStore provider for changing / cancelling these keys.
- jaegerpicker 12y ago