How a security researcher made $10,000 in bug bounties from GitHub secret leaks
You don’t have to skim through the codes for flaws, you don’t have to use engines like Metasploit or Wireshark, you don’t even have to code – you can make lots of money just by GitHub Search Dorking. This what Tillson Galloway did and earned a respectable $10,000 as bug bounty.
Galloway is a security researcher and the co-founder of Invenovate. He is a student at Georgia Tech studying Computer Science and has found a unique way to make money. He lists his bug bounty making adventure on his blog detailing how he made $10,000 just by using advanced search methods on GitHub.
Search Dorking on GitHub
Galloway noticed that simply by searching Github for passwords and keys he could claim bug bounty. By searching for specific keywords, he found all sorts of interesting, unintentional things. For example, the “vim_settings.xml” contains recently copied and pasted strings, and “.bash_history contains” a record of commands that have been run. Galloway found that GitHub search dorks can present interesting things.
GitHub provides rich code searching that scans public GitHub repositories (some content is omitted, like forks and non-default branches). Queries can be simple like uberinternal.com or can contain multi-word strings like “Authorization: Bearer”. Searches can even target specific files (filename: vim_settings.xml) or specific languages (language:SQL). Searches can also contain certain boolean qualifiers like NOT and >.
Galloway discovered that filename: vim_settings.xml targets IntelliJ settings files. The vim_settings.xml file contains recent copy-pasted strings encoded in Base64 and can reveal sensitive customer information. Galloway made $2400 from a bug bounty using this dork and finding that SaaS API keys and customer information were exposed in vim_settings.xml.
He found he could use more than vim_settings.xml to search for vulnerable data. He wrote a 14-line script which skims through repository’s commit history to find the entire copy-paste history. This can be used to access any GitHub user’s data.
He basically categorizes his findings as below:
- SaaS API keys – Companies rarely impose IP restrictions on APIs. AWS, Slack, Google, and other API keys are liquid gold. These are usually found in config files, bash history files, and scripts.
- Server/database credentials – These are usually behind a firewall, so they’re less impactful. Usually found in config files, bash history files, and scripts.
- Customer/employee information – These hide in XLSX, CSV, and XML files and range from emails all the way to billing information and employee performance reviews.
- Data science scripts – SQL queries, R scripts, and Jupyter projects can reveal sensitive information. These repositories also tend to have “test data” files hanging around.
- Hostnames/metadata – The most common result. Most companies don’t consider this a vulnerability, but they can help refine future searches
Galloway has written an App specifically for GitHub Search Dorking called GitHound. He has released GitHound as an open-source tool designed to automate the process of finding keys across GitHub. GitHound can sift through all of GitHub, using Code Search queries as an entry point into repositories and then using context, regexes, and some other neat tricks to find some surprising secrets.
Fix for GitHub search Dorking
He says that there is no cure other than being aware while using GitHub. To limit secret leaks from source code, GitHub users must update API frameworks and DevOps methodologies to prevent API keys from being stored in Git/SVN repositories entirely. They can use software like Vault which safely stores production keys. Some API providers, like Google Cloud Platform, have updated their libraries to force API keys to be stored in a file by default thereby limiting its exposure to the outside world.