How to Find Vulnerable IPs by CVE ID | The Methodology
Target research is usually a long and tedious process and it’s always a good idea to speed up and simplify the methods of obtaining information. That’s why we’ve decided to describe some frequent data gathering cases that can direct and speed up your reconnaissance process, as well as help utilize the Spyse search engine to its fullest potential.
In this article, we describe the easiest ways of finding vulnerable IPs and domains according to a specific CVE ID.
The topic will be explained using the Spyse cybersecurity search engine which will give us access to a massive amount of information about different internet entities and allow us to easily obtain data in real-time.
One of the features we will be using is called Advanced Search. This feature lets us apply a few search parameters in our search query to get more precise results. The parameters for this search query will be the characteristics of the vulnerable software running on an IP host. It could be a substring in an HTML document, a specific open port, a software version, or a certain web-server behavior.
From here on out the term software will mean a web framework, CRM, CMS, content platform, web server, or any other system/application that can be located on the internet.
There are four common steps of how to find vulnerable IPs or hosts by vulnerability ID:
1. Find the software versions affected by this specific vulnerability
2. Reproduce the environment in which the vulnerable software is running
3. Identify unique software characteristics for this particular version
4. Ask the right questions
Step 1: Find affected software versions
The only thing we have to do in this step, is to get the affected software versions from the CVE description.
CVE stands for Common Vulnerabilities and Exposures. It is an open database of publicly available IT security vulnerabilities (see NVD Vulnerabilities library). Each entry in this database contains details about vulnerabilities, their severity, reference URLs, common weakness enumeration numbers and affected software configurations.
For example, if we are looking for vulnerable Solr servers according to CVE-2019-0192, the versions are 5.0.0 to 5.5.5 and 6.0.0 to 6.6.5:
Step 2: Reproduce vulnerable environment
In this step, we are looking for a way to reproduce the environment in which the vulnerable software is running. The implementation of this step heavily depends on the software’s license, its availability, and type. You could try reproducing the environment on your local system, but this can lead to the file system cluttering, making it work slower. The other downsides of installing everything on your local system are configuration and dependencies conflicts which may appear when you run several versions of the same software at the same time.
There are two more convenient ways to achieve our goal: environment and OS virtualization.
If the software is a service that is simply running on a certain port (for example a web server), you could try to virtualize the environment by creating your own docker image or finding some ready-to-use images on docker hub:
Docker allows you to find and run a software environment of a certain version in a single CLI command allocating a small number of resources compared to a virtual machine in minutes.
Let’s say you need to run Apache httpd 2.2. Instead of searching for this version in official repos, building and installing it on your local system, you could find this particular version in the docker hub and quickly get it up and running.
Here’s an example of how you could find an old version of the software environment:
Another nice feature about using docker is that after you have done research on some software, you can easily remove it without leaving any software-related files on your local system. This will keep it fast and clean.
For more details about what is docker and how to use it see the docker official site.
OS virtualization: pre-built boxes
In case when the software requires a specific environment that may not be containerized with Docker, it could be reproduced in a virtual machine. Deploying the virtual machine may be very time consuming, so it would be better to start from pre-installed boxes.
For most Linux and Unix flavors, virtual machines can be found at osboxes.org. To this day, Windows provides VMWare, Hyper-V, VirtualBox, and Parallels of Windows 10 boxes with a limited license period for software developers. If you need an older version, you will probably need to install it by yourself.
Once the virtual machine is up and running, the next step is to install a specific version of the software we are going to analyze. It’s common that the software of an old version is not available from official repositories so it should be found and built from other sources.
Step 3: Identify software characteristics
Now that we’ve got our environment and software running, the next step for finding vulnerable IPs is identifying software characteristics.
In this step, we should analyze the content and behavior markers that are common for all software deployment configurations.
Here is a list of markers that could be a good start for further analysis:
- Banner. Sometimes services running on ports are chatty and say too much. Port banners may tell you a lot about the service including its version.
- HTTP headers. For example “x-powered-by” header may give you some clue about the running application.
- HTML title tag contents. It may contain some standard prefix or postfix like ‘Confluence’ in Confluence Server.
- Meta tags. Usually, they contain plenty of useful information characterizing a particular application.
- Styles and Scripts. CSS stylesheet links may contain a specific path identifying this app or a GET parameter, that contains the app version.
- URL paths. Some web frameworks have naming conventions that force developers to name URL paths in a specific way.
- Redirects. Some servers may redirect users to a specific path, so you could search the server by contents of the HTTP ‘Location’ header.
In the next articles, we will look at more detailed examples on how to find these characteristics.
Step 4: Ask the right questions
Once we’ve defined the features and characteristics of the software, it’s time to create a fine-tuned query for finding vulnerable IPs using the Spyse search engine.
Let’s say that we are looking for Apache Solr 6.5.0 and from the previous step we’ve found out that usually, this web app has a “Solr” substring in HTML title tag and a “6.5.0” substring as a GET parameter in CSS styles URL.
Now let’s ask the search engine to find such hosts by specifying two search filters: title contents and stylesheets contents.
The query instantly returns the desired hosts available for further research.
In this article, we’ve discussed a basic step-by-step methodology of finding vulnerable IPs or hosts by CVE ID using the Spyse search engine, and shared a few tips about how to do it efficiently.
In the next articles, we will use this methodology to find hosts affected by common vulnerabilities.