Is your Mobile App Leaking Secrets?

In Why Exposed API Keys and Sensitive Data are Growing Cause for Concern, Janet Wagner points out that the exposure of sensitive data through code is a growing cause of concern as developers rely more and more on the cloud for the overall workflow during development and deployment of their applications and in accessing third part services at run-time from within them.

Here are some examples of places where exposure of API Keys, tokens, passwords, cloud credentials, and other secrets have been found:

• In code that is committed to github, gitlab and other online repositories of code.
• At CI pipelines and automation tools on the cloud.
• When copy pasting code to places like Stackoverflow, Forums, Issues trackers, etc.

The simplest approach to check for secrets in our code is to perform a search in your editor of choice or using a simple command in the shell to look for common string names used to reference them. The problem with this approach is that we need to remember all the string names in our code which reference secrets, making it not an effective way to ensure our code is free of sensitive information which we do not want to be leaked.

Open Source is often our best friend, and this time is not an exception. A quick search for better alternatives may lead us to a tool like the truffleHog package in Github, which scans all git commits in a repository for any secrets that may exist within them by using entropy or regex patterns.

Let's use a docker container to run TruffleHog against the Approov ShipFast Code with the following commands:

$ sudo docker run --rm -it python bash
root@4781429bcc7c:/# pip install truffleHog
root@4781429bcc7c:/# git clone https://github.com/approov/shipfast-api-protection.git
root@4781429bcc7c:/# truffleHog shipfast-api-protection

and we will be presented with a very long output where we can find API Keys being leaked, like in this partial screenshot:

Now lets try to run it again but this time we will do it against the public url for our Approov ShipFast Demo in Github, with the commands:

$ sudo docker run --rm -it python bash
root@4781429bcc7c:/# pip install truffleHog
root@4781429bcc7c:/# truffleHog https://github.com/approov/shipfast-api-protection.git

and once more we will have a very long output, where we can find another example of the API Key being leaked:

Ah but wait! Do you think that you are safe because you have removed your sensitive data immediately after you have committed it?

Well I have bad news for you... it seems that some services cache all Github commits, thus hackers can check these services or employ the same techniques to immediately scan any commit sent to Github in a matter of seconds.

Hackers can, for example, use exposed cloud credentials to spin up servers for bitcoin mining, for launching DDOS attacks, etc and you will be the one paying the bill in the end as in the famous "My $2375 Amazon EC2 Mistake" that can be found in Reddit or here.

Oh and did I mention already that in the case of mobile apps their binaries may be reverse engineered with tools like the Mobile Security Framework despite some techniques you may have employed to protect the secrets in your mobile app at run-time or to hide them from being reverse engineered from your binary?

For a demo on how several techniques can be employed to secure secrets in your mobile app and at same time how they can be bypassed or reverse engineered, you may want to go through the ShipFast App Demo. This demo will show you how API Keys, HMAC, OAUTH2 and other techniques can be bypassed in order to tamper your App or retrieve secrets that will allow unauthorized access to the API server or any third part services directly accessed by the app. Check this series of articles for more detailed info around API abuse.

By this time you may be worried about how you are going to protect your mobile app and API server from all these abuses. Well stop scratching your head and just dive into the Mobile App Attestation service provided by Approov(I work here).

Now that you are aware of the dangers of leaking API Keys or other secrets in your code, it is time to start removing them from your code and improving your mobile security.

Do you have anything to say, ask, recommend? Please leave your comment below, your feedback will help me improve my future blog posts.

See you in my next article The Top 6 Mobile API Protection Techniques - Are they Enough?.

This article was first published here.

Comments

[Rémi Lavedrine]

I really like this kind of article.
It is very interesting.

Thanks for writing it.

[adnanganie]

What about data, stored in app shared preference.

[FunkyMuse]

It can be extracted as well but has to be populated first, to make it harder you can apply some XOR or encryption functions but since the keys are stored somewhere in the app it ain't safe, it's up to the guy who's going to decompile the app and his will to go as further as it can be.

Exporting the app as app bundles helps a bit when apps are decompiled.

[Paulo Renato]

Using an introspection framework like Frida, xPosed and others, will allow an attacker to hook on the method that gets the secret from shared preferences and extract it, even if you have encrypted it.

Any secrets stored on the client side will be always possible to extract, its just a question of how much effort and knowledge the attacker needs to put in.