GitHub repositories can disclose all sorts of potentially valuable information for bug bounty hunters. The targets do not always have to be open source for there to be issues. Organization members and their open source projects can sometimes accidentally expose information that could be used against the target company. in this article I will give you a brief overview that should help you get started targeting GitHub repositories for vulnerabilities and for general recon.
Mass Cloning
You can just do your research on github.com, but I would suggest cloning all the target’s repositories so that you can run your tests locally. I would highly recommend @mazen160’s GitHubCloner. Just run the script and you should be good to go.
$ python githubcloner.py --org organization -o /tmp/output
Static Analysis
When it comes to static analysis it is very important to start by actually understanding the project you are targeting. Run the project and use the main features. I call this the “Jobert step”, because I have heard that Jobert spends the first 30 minutes of every hunt using the project and understanding the target before finding vulnerabilities.
Manual analysis
This is where the “learn to make it, then break it” mentality comes into play. If you can familiarize yourself with a programming language, you should know the ins and outs of what to do and what not to do in terms of security.
Once you understand the target and its architecture, you can start grepping! Search for keywords that you are interested in, understand best or know that developers tend to mess up. Here is a basic list of some of the keywords I will look for during a general first assessment:
- API and key. (Get some more endpoints and find API keys.)
- token
- secret
- TODO
- password
- vulnerable 😜
- http:// & https://
Then I will focus on terms that make me smile when developers mess things up:
- CSRF
- random
- hash
- MD5, SHA-1, SHA-2, etc.
- HMAC
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 vital step is to look through the commit history. You will be amazed at the amount of information you can gather from commits. Sometimes I see contributors thinking they have removed credentials, when they stay in the commit history. I have come across old endpoints that still work thanks to the git history. Aside from current issues, you might discover past issues that could potentially be bypassed thanks to old commits.
Tools
Sometimes automating the boring tasks can help give you a basic overview of what to look for. It is important to note, that you should never copy and paste findings from scanners into your reports. You will get a lot of false positives, therefore you must always look into the possible issue manually to ensure exploitability.
When I target Python projects, the main tool that I use is Bandit. Bandit will find common issues, but will often return low hanging fruit or false positives. So be careful when using it. It should definitely not be relied on.
$ bandit -r path/to/your/code -ll
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.
$ gitrob analyze acme,johndoe,janedoe
For finding high entropy strings (API keys, tokens, passswords, etc.), you can use truffleHog.
$ truffleHog https://github.com/dxa4481/truffleHog.git
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.
$ python linkfinder.py -i 'path/to/your/code/*.js' -r ^/api/ -o cli
Social Engineering
OK, seriously do not social engineer the project owners.
Reporting your Findings
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. 😉
Top comments (0)