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.
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 on GitHub, Gitlab, and other online repositories of code
- At CI pipelines and automation tools on the cloud
- When copy pasting code to places like Stack Overflow, Forums, Issue 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 that 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
$ sudo docker run --rm -it python bash
[email protected]:/# pip install truffleHog
[email protected]:/# git clone https://github.com/approov/shipfast-api-protection.git
[email protected]:/# 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, let’s try to run it again, but this time, we will do it against the public URL for our
$ sudo docker run --rm -it python bash [email protected]:/# pip install truffleHog [email protected]:/# 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 the 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.
Now that you are aware of the dangers of leaking API Keys and other secrets, it is time to start removing them from your code and improve the security of your mobile app and API
As a final note, I would