Hunting for secrets on GitHub

It seems that there is a bit of a cottage industry of “bug bounty hunters” who specialize in searching public repositories on GitHub for exposed credentials such as AWS and Azure access keys, passwords, API keys and the like. When they find them, they then contact the repo owners and offer to point out the exposed credentials for a fee. Of course, there are also people out there who look for exposed credentials with darker motives in mind, choosing to use them to gain access to systems, steal information in cloud storage, aid and abet their extortion schemes, etc.

We need to educate developers about just how bad of an idea it is to store credentials in their code and how much worse of an idea it is to commit secrets to code repositories (whether they are public or private). When secrets get committed to public repos, attackers can use tools like git-wild-hunt to quickly identify and exploit them.

Git-wild-hunt is a set of Python scripts and regular expression libraries which, when combined with a freely available GitHub API key, can quickly scan the thousands of public repos for dozens of types of security credentials. Want a bunch of AWS access keys? A recent run of the tool revealed almost 400 of them sitting out there waiting for someone to abuse them.

Installing and running the tool is dead simple – even a CISO could do it (so I have heard). Sign up for a GitHub API key, boot up your Linux box, cut and paste a few commands from the documentation and you are off to the races.

I can’t think of a law that one would be breaking by running this tool, although I AM NOT A LAWYER and do not even play one on TV. After all, GitHub public repos are, well, public and the data is sitting there for the world to see. As long as one doesn’t use the credentials, I don’t see a problem. However, I definitely would not run this tool from a machine owned by my employer and I would warn those who might want to play with the tool that after running it, you will be in possession of lots of login information that you should not have and you should make sure to securely erase and overwrite the data so as not to further expose it to bad people accidentally.

GWH looks like ir could have a couple of uses for defenders – monitoring for exposures of credentials by searching the results (and throwing away anything that is not yours) and demonstrating to developers just how easy it is for attackers to find any credentials that they place in a public repo.

We need to work with system designers and developers to make them understand that using a secure credential vault with programmatic access is not an optional luxury – it is a basic security requirement. Credentials do not belong in code, even if that code is stored in a safe inside a vault inside a volcano.

GWH is not a new tool, but I first saw it demonstrated at BlackHat 2021 – an example of one of the values of attending conferences. There is so much work going on in the security community today that keeping on top of every interesting new tool and technique is impossible – especially if you are a pointy haired CISO who has been off the SOC desk for a while. Knowing what tools your team is up against helps you frame risk properly for yourself, your team and your security stakeholders.

Leave a Reply