Passive Recon

Passive Reconnaissance

Passive API Reconnaissance is the act of obtaining information about a target without directly interacting with the target’s systems. When you take this approach, your goal is to find and document public information about your target’s attack surface.

Typically, passive reconnaissance leverages open-source intelligence (OSINT), which is data collected from publicly available sources. You will be on the hunt for API endpoints, exposed credentials, version information, API documentation, and information about the API’s business purpose. Any discovered API endpoints will become your targets later, during active reconnaissance. Credential-related information will help you test as an authenticated user or, better, as an administrator. Version information will help inform you about potential improper assets and other past vulnerabilities. API documentation will tell you exactly how to test the target API. Finally, discovering the API’s business purpose can provide you with insight into potential business logic flaws.

As you are collecting OSINT, it is entirely possible you will stumble upon a critical data exposure, such as API keys, credentials, JSON Web Tokens (JWT), and other secrets that would lead to an instant win. Other high-risk findings would include leaked PII or sensitive user data such as SSN, full names, email addresses, and credit card information. These sorts of findings should be documented and reported immediately because they present a valid critical weakness.

Now we will check out a few passive reconnaissance techniques that can be leveraged to discover APIs. Including Google Dorking, Git Dorking, API Repositories, the Way Back Machine, and Shodan.

Google Dorking

Even without any Dorking techniques, finding an API as an end-user could be as easy as a quick search.

Google Search for Reddit's API.

However, sometimes you may not get the exact results you were hoping for. If you are getting too many irrelevant results then you could deploy some Google Dorking techniques to more effectively discover APIs.

Google Dorking Query	Expected results
inurl:"/wp-json/wp/v2/users"	Finds all publicly available WordPress API user directories.
intitle:"index.of" intext:"api.txt"	Finds publicly available API key files.
inurl:"/api/v1" intext:"index of /"	Finds potentially interesting API directories.
ext:php inurl:"api.php?action="	Finds all sites with a XenAPI SQL injection vulnerability. (This query was posted in 2016; four years later, there are currently 141,000 results.)
intitle:"index of" api_key OR "api key" OR apiKey -pool	This is one of my favorite queries. It lists potentially exposed API keys.

GitDorking

Regardless of whether your target performs its own development, it’s worth checking GitHub (www.github.com) 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.

TruffleHog

TruffleHog is a great tool for automatically discovering exposed secrets. You can simply use the following Docker run to initiate a TruffleHog scan of your target's Github.

$ sudo docker run -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --org=target-name

In the above example, you can see that the org that was targeted was Venmo and the results of the scan indicate URLs that should be investigated for potentially leaked secrets. In addition to searching Github, TruffleHog can also be used to search for secrets in other sources like Git, Gitlab, Amazon S3, filesystem, and Syslog. To explore these other options use the "-h" flag. For additional information check out https://github.com/trufflesecurity/trufflehog.

API Directories

Programmableweb.com is a go-to source for API-related information (https://www.programmableweb.com/apis/directory). To learn about APIs, you can use their API University. To gather information about your target, use the API Directory, a searchable database of over 23,000 APIs. Expect to find API endpoints, version information, business logic information, the status of the API, source code, SDKs, articles, API documentation, and a changelog.

Twilio API page on programmableweb.com.

Click through the various tabs in the directory listing and note the information you find. To see the API endpoint location, portal location, and authentication model. To see information about the APIs version history, select a specific version listed under the Versions tab. In this case, both the portal and endpoint links lead to API documentation as well. In the case of Twilio, you can see all the specs related to the current version of the REST API.

The Twilio specs page on programmableweb.com.

On the Twilio specs page, you can learn all sorts of useful information about the API. For instance, the API endpoint URL is listed, the forum for the API, the developer support URL, the authentication model, and more are all listed on this page. At the bottom of the Specs page, you can also see articles related to the API and developers of the API, all of which could prove useful when attacking the API.

Shodan

Shodan is the go-to search engine for devices accessible from the internet. Shodan regularly scans the entire IPv4 address space for systems with open ports and makes their collected information public on https://shodan.io. You can use Shodan to discover external-facing APIs and get information about your target’s open ports, making it useful if you have only an IP address or organization’s name to work from. Like with Google dorks, you can search Shodan casually by entering your target’s domain name or IP addresses; alternatively, you can use search parameters like you would when writing Google queries. The following table shows some useful Shodan queries.

Shodan Queries	Purpose
hostname:"targetname.com"	Using hostname will perform a basic Shodan search for your target’s domain name. This should be combined with the following queries to get results specific to your target.
"content-type: application/json"	APIs should have their content-type set to JSON or XML. This query will filter results that respond with JSON.
"content-type: application/xml"	This query will filter results that respond with XML.
"200 OK"	You can add "200 OK" to your search queries to get results that have had successful requests. However, if an API does not accept the format of Shodan’s request, it will likely issue a 300 or 400 response.
"wp-json"	This will search for web applications using the WordPress API.

The Wayback Machine

The Wayback Machine is an archive of various web pages over time. This is great for passive API reconnaissance because this allows you to check out historical changes to your target. If, for example, the target once advertised a partner API on their landing page, but now hides it behind an authenticated portal, then you might be able to spot that change using the Wayback Machine. Another use case would be to see changes to existing API documentation. If the API has not been managed well over time, then there is a chance that you could find retired endpoints that still exist even though the API provider believes them to be retired. These are known as Zombie APIs. Zombie APIs fall under the Improper Assets Management vulnerability on the OWASP API Security Top 10 list. Finding and comparing historical snapshots of API documentation can simplify testing for Improper Assets Management.

Check for differences between the API documentation. Later, when you are actively testing the API, make sure to test using old endpoints,

Conclusion

In this module, we covered some basic techniques that can be deployed to gather about your target's API attack surface. The first step to hacking a target's APIs is to uncover as much information about them as possible. Using these reconnaissance techniques can not only help you discover the existence of APIs, but can also lead to critical vulnerability findings. Next we will focus on active recon techniques.