To create Shodan queries, I needed to modify the Windows names in the dictionary and the CPEs to match each other. I then formulated the queries in the following format:

“OS Build: (build number)”

An example of Microsoft Windows build number Shodan search results:

Each CVE has several CPEs, and each CPE has a corresponding build number. To consolidate the results for each CVE, I added up the number of Shodan appearances for all of the CPEs associated with that CVE.

Microsoft Exchange The process for searching for Microsoft Exchange vulnerabilities on Shodan was quite similar to that for Microsoft Windows. I started by extracting all of the CPEs related to Microsoft Exchange from NVD using a Python script that utilized the requests module to retrieve the webpage of each CVE. I then extracted the CPEs from the ‘input type=”hidden” id=”cveTreeJsonDataHidden”’ line in the output.

Like Microsoft Windows, Shodan presents a field in the returned response header that represents the Microsoft Exchange version:

Next, I used the Microsoft Exchange build-numbers-and-release-dates page to export the information for the build number associated with each Exchange server version. I combined this information with the data from NVD to formulate the Shodan request in the following format: “Microsoft Exchange: (build_number)”.

To identify the Shodan appearances for each known exploited vulnerability, I looped over the CPEs and determined which build numbers correspond to each Exchange version. I then aggregated the requests for each vulnerability.

An example of Microsoft Exchange build number Shodan search results:

Linux Kernel To extract all Linux Kernel versions, I used this link. I then wrote a Python script to check the version boundaries for each CVE. I also discovered that Shodan presents a field in the returned response header that represents the Linux Kernel version:

Then, formulated the Linux Kernel versions with corresponding Shodan query using the following format and aggregated the requests for each vulnerability:

“SERVER: Linux/(linux_kernel_version)”

An example of Linux Kernel version Shodan search results:

Jenkins To determine the Jenkins versions, I used this link and then cross-referenced the information with the affected version ranges for each CVE in the NVD using the CPE.

I also discovered that Shodan presents a field in the returned response header that is called X-Jenkins which represents the Jenkins version.

After using the resource I mentioned above to identify the Jenkins versions affected by each CVE, I wrote a Python script that generates the Shodan queries based on the affected versions range.

It should be noted that Jenkins has Long-Term Support (LTS) releases that are selected annually and produce three versions (x.1, x.2 and x.3).

The script iterates over the Jenkins versions and selects those versions that have three octets and are less than or equal to the LTS release, as well as those versions that have two octets and are less than or equal to the normal release, and then aggregates the results. An example of a Jenkins versions Shodan search results:

Elasticsearch For products like Elasticsearch, their versions are available in Shodan. To extract the necessary data, I simply needed to determine the affected version ranges using the CPE in the NVD, and then aggregate the results from the corresponding page.

An example of a “product” Shodan query and the appearances for each version:

Favicon Hash One method for identifying the product running on a website is through the use of Favicon Hashes. This involves calculating a hash of the website’s icon using the mmh3 Python library, which can provide information about the underlying product.

You can find a helpful explanation of this technique in this link, which provides guidance on where to find common Favicon Hashes and how to calculate them.

However, it is important to note that Favicon Hashes are limited in their usefulness for identifying vulnerable versions of a product. This is because they typically do not provide information about the specific version being used, making it difficult to accurately determine which versions may be affected by a vulnerability. As a result, this technique may not be suitable for all research purposes.

The Shodan header field for “Favicon Hash” is:

http.favicon.hash:(hash)

An example of a “favicon hash” Shodan query for HIKVISION and search results:

Conclusion Searching for vulnerabilities on Shodan can be a challenging task, as not all CVEs are covered by the platform’s filters. However, it is possible to extract information on vulnerable products and vendors, and match it with their corresponding versions to formulate effective queries. In this blog post, we have seen how to use Shodan to track down vulnerable components for Microsoft Windows, Microsoft Exchange, Linux Kernel, Jenkins, and Elasticsearch. By using the process described here, researchers can identify potentially vulnerable devices or systems and help prevent future cyber attacks by taking active steps to decrease the numbers we saw in the results.

It is important to note that not all devices or systems returned in the search results may be exploitable or compromised, as other components may also need to be addressed in order to exploit a vulnerability. Therefore, further investigation is highly recommended before taking any action based solely on the results of the query. It is crucial to understand the context and the specific details of the devices or systems identified as potentially vulnerable before making any decisions.