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:
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.
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.