Shhgit Your Secrets Are On Internet

Github has been an amazing tool for developers and open source software communities across the globe. It allows for developers and users to quickly communicate and for issues to be reported to teams during testing. It has also enabled large open source projects to use hundreds of individual contributors while still having visibility and documentation for each change made. Github does come with some dark sides though, the largest of which is unintentionally disclosing confidential information such as passwords, system configurations, and API keys. Shhgit is a live look at Github data that should be private or secret. Written by eth0izzle, and Shhgit can also be hosted locally if you would like to.

How does Shhgit work

Shhgit scans the public GitHub API matching entries that could contain confidential information. All of this data is already publicly available through the GitHub API and the only real limit to how much data you can intake is the 5000 request per hour limit imposed by GitHub themselves. As you can see in the following screenshots Shhgit quickly keys in on any interesting data flowing through the GitHub API.
shhgit live2

Keeping Your Secrets Safe

Keep It Safe
Before we go forward, let’s make a small list of dangerous files and configurations that could be accidentally added to a public GitHub repository.

  1. Usernames and passwords
  2. Environment configuration files
  3. Private and public encryption keys
  4. Service API Keys
  5. CI/CD configuration files
  6. Backups with credentials stored in them
  7. Database files

For those sensitive files, they should be excluded from being uploaded to the public GitHub.  For items like API keys and Passwords only placeholders should be used. Only during testing and the push to production should the API keys and passwords be added.

A Better Way

theway (2)
The best method to secure secrets in a CI/CD pipeline is to use a credential management system. Tools like Conjur for Jenkins can enable teams to write secure code using credentials that a developer may not know. This is particularly useful in situation where you may be connecting to databases and other services that you may not want individual developers knowing the credentials or keys to while they still need to be able to write code for that service.

The Future

By following the guidance provided here developers and organizations can avoid showing up on tools like Shhgit and having their secrets shared to the world. Teams wanting to learn more about SDLC can take classes offered by VDA Labs, like the course we teach at Black Hat 2020.  Join us there!