GitDorking

Regardless of whether your target performs its own development, it’s worth checking GitHub for sensitive information disclosure.

Developers use GitHub to collaborate on software projects. Searching GitHub for OSINT could reveal your target’s API capabilities, documentation, and secrets, such as API keys, passwords, and tokens, which could prove useful during an attack. Similar to Google Dorking, with GitHub, you can specify parameters like:

• filename: swagger.json

• extension: .json

Begin by searching GitHub for your target organization’s name paired with potentially sensitive types of information, such as “api key,” "api keys", "apikey", "authorization: Bearer", "access_token", "secret", or “token.” Then investigate the various GitHub repository tabs to discover API endpoints and potential weaknesses. Analyze the source code in the Code tab, find bugs in the Issues tab, and review proposed changes in the Pull requests tab.

Code contains the current source code, readme files, and other files. This tab will provide you with the name of the last developer who committed to the given file, when that commit happened, contributors, and the actual source code.

Using the Code tab, you can review the code in its current form or use ctrl-F to search for terms that may interest you (such as API, key, and secret). Additionally, view historical commits to the code by using the History button found near the top-right corner of the above image. If you came across an issue or comment that led you to believe there were once vulnerabilities associated with the code, you can look for historical commits to see if the vulnerabilities are still viewable.

When looking at a commit, use the Split button to see a side-by-side comparison of the file versions to find the exact place where a change to the code was made.

The Split button (top right of the above image) allows you to separate the previous code (left) and the updated code (right). Here, you can see a commit to an application that removed the Google Maps API key from the code, revealing both the key and the API endpoint it was used for.

The Issues tab is a space where developers can track bugs, tasks, and feature requests. If an issue is open, there is a good chance that the vulnerability is still live within the code (see Figure 6-9).

This is an example, of an open GitHub issue that provides the exact location of an exposed API key in the code of an application. If the issue is closed, note the date of the issue and then search the commit history for any changes around that time.

The Pull requests tab is a place that allows developers to collaborate on changes to the code. If you review these proposed changes, you might sometimes get lucky and find an API exposure that is in the process of being resolved. As this change has not yet been merged with the code, we can easily see that the API key is still exposed under the Files changed tab. The Files changed tab reveals the section of code the developer is attempting to change.

If you don’t find weaknesses in a GitHub repository, use it instead to develop the profile of your target. Take note of programming languages in use, API endpoint information, and usage documentation, all of which will prove useful moving forward.