It’s way too easy to grab free API keys off the web. You would assume that you have to go through some elaborate hack or even some ruse to gather someone else’s API keys, but it is actually extremely easy to grab API keys.
One of the rookie mistakes most programmers make is hard coding keys into code. Now hard coding keys in plain sight is obviously bad for a million reasons, but it happens. For casual people who use public source control to host their files or people new to versioning control, the problem of hard coding keys may not seem obvious. Even seasoned programmers finding themselves making this mistake. I myself am guilty of this when hacking together late night projects.
The problem exacerbates itself with the fact that most side projects or even projects in general end up on public source control repositories.
Now if you match two and two together, you can see how it is possible to gather keys, just build a web scraper to farm for keys on public source control repository channels.
Better yet, you don’t even need a web scraper, Github, an extremely popular source control provides you a web scraper for free for the code hosted on their website! The search feature was obviously not designed specifically for finding keys, but for searching the public space of all Github repos for code that might be cool or good to look at. Finding keys just happens to be a side effect of the ability to search.
Here are some examples of keys you can find in Github.
As you can see, it is way too easy to find keys; it’s a trivial task. Those queries were the first things that popped into my head as well. You can obviously get very creative here and find extremely obfuscated API keys if you really wanted. If you were really persistent, you could even dig into commit histories to find when inexperienced developers thought by pushing a commit that deleted the key would be sufficient enough to erase the key off of their repo.
There are many reasons why people end up writing bots for finding these keys. One is to be malicious and two going off the first point, to having free API access.
AWS keys, for example, are extremely valuable to have as they provide highly extensible computing power. In malicious cases, access to unauthorized keys is a goldmine for those looking to have unlimited computing power for mining bitcoin. There are multiple accounts of this actually happening. Here posted below is one account where he posted his AWS API Keys publically in Github accidently, he woke up the next morning with a bill for $2375. YIKES!!! He ended up calling Amazon and fortunately Amazon customer support understood his situation and was kind enough to drop the charges (this time). My $2375 Amazon EC2 Mistake
And if you still don’t, believe me, here is another account of this happening. Unauthorized Litecoin Mining
There must thousands more of these fraudulent activities happening so the best thing to do is to secure your keys.
Well stupid, don’t push API Keys. Much easier said than done. I’ve obviously scrubbed all traces of keys since then but just understand that this is a very easy mistake to make.
Step 1:
Delete sensitive files containing keys
Github makes it clear in their policy that when you upload any keys consider them compromised. Danger: Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised.If you committed a password, change it! If you committed a key, generate a new one. This article tells you how to make commits with sensitive data unreachable from any branches or tags in your GitHub repository. However, it’s important to note that those commits may still be accessible in any clones or forks of your repository, directly via their SHA-1 hashes in cached views on GitHub, and through any pull requests that reference them. You can’t do anything about existing clones or forks of your repository, but you can permanently remove all of your repository’s cached views and pull requests on GitHub by contacting GitHub support.
Therefore delete those sensitive files. Refer to this link to do so (Removing Sensitive Data).
Step 2:
Regenerate API Keys
As stated in step 1, consider your API Keys compromised, therefore, regenerate new keys. Just refer to the developer portal which provides you the API Key and just regenerate one.
Step 3:
Store keys in environmental variables!!!
Since I do not want to draw this article out too long, I will refer you to this post to do so.
Uploading sensitive information to Github including keys is a bad idea whether that be by accident or not. If you did, consider that key compromised. Therefore scrub all records of that key, regenerate keys, and leverage environmental variables. See part II to see how to secure your API keys.
I’m @steventsooo on Twitter. I would love to hear what you think!