GitHub for Bug Bounty Hunters

For bug bounty hunters, GitHub repositories can reveal a variety of potentially useful information. There can be problems with targets that are not always open source. Sometimes information that could be used against the target company is mistakenly revealed by organisation members and their open source initiatives. I’ll give you a quick overview in this article that should get you started scanning GitHub repositories for vulnerabilities and performing general reconnaissance.

You can just conduct your research on github.com, however to enable local testing, I advise cloning every target repository. The GitHubCloner by @mazen160 is a fantastic product. All you have to do is execute the script to be ready to go.

It is crucial to actually comprehend the project you are aiming for before beginning a static analysis. Use the primary features while running the project. The reason I refer to this as the “Jobert step” is because I’ve heard that before beginning every hunt, Jobert uses the project and gets a good understanding of the target before looking for weaknesses.

The saying “learn to make it, then break it” applies in this situation. If you can learn a programming language, you should be able to understand the ins and outs of security precautions to take and avoid.

You can begin grepping once you are familiar with the target and its architecture. Look for keywords that you are interested in, are familiar with, or that you are aware developers frequently get wrong.

Here is a basic list of some of the search terms I’ll use during a first broad evaluation:

Then I will focus on terms that make me smile when developers mess things up:

When you get used to certain vulnerability types, you will start knowing exactly what to look for in a specific language. So for instance, when I want to find a timing leak in Java, I know that Arrays.equals() and HMAC combined causes that issue.

Another critical step is to review the commit history. You’ll be surprised at how much information you can glean from commits. I’ve seen contributors mistakenly believe they’ve removed credentials while they remain in the commit history. Because of the git history, I’ve discovered ancient endpoints that still operate. Aside from current concerns, you may come across historical issues that may be avoided owing to old commits.

Sometimes automating the boring tasks can help give you a basic overview of what to look for. It’s crucial to remember that you shouldn’t ever copy and paste scan results into reports. You’ll get a lot of false positives, so you should always carefully investigate any potential issues to be sure they can be exploited.

The major tool I employ when pursuing Python projects is Bandit.

Bandit will identify common problems but frequently return false positives or low hanging fruit. So use it with caution. Without a doubt, it shouldn’t be relied upon.

If you want to find outdated Python modules in a project, paste the contents of the requirements.txt in https://pyup.io/tools/requirements-checker/. This will show you if there were any security issues in the specified version of the module.

Snyk.io is a wonderful tool for checking dependencies. The platform supports a wide variety of languages.

For recon, many researchers suggest using Gitrob. This tool will look for sensitive information in public GitHub repositories.

For finding high entropy strings (API keys, tokens, passswords, etc.), you can use truffleHog.

If you are looking for an all-in-one secrets finder, git-all-secrets by @anshuman_bh is the tool for you. This tool combines multiple open source secrets finders into one big tool.

For Ruby on Rails apps, I recommend Brakeman. Brakeman is a static analysis security scanner that can find a ton of various security issues in code.

Use LinkFinder by Gerben Javado to find endpoints in the JS files of the repository.

OK, seriously do not social engineer the project owners.

As always when it comes to bug bounty hunting, read the program’s policy thoroughly. Very rarely does a program accept reports through GitHub. Contact the security team or if possible use a bug bounty platform such as HackerOne or Bugcrowd

On a side note, a cool thing about white-box testing is that since you have access to the code it can be easier to suggest a fix or submit a patch. 😉

THANKS FOR READING THIS!