search_vulns: Simplifying the Surprising Complexity of Finding Known Vulnerabilities

A common challenge in the realm of IT security is determining whether a specific software has any known vulnerabilities. In our previous post we illustrated that finding known vulnerabilities is surprisingly complex. In that post we initally described several requirements a good tool for this purpose should meet. Thereafter, we used these requirements to evaluate multiple existing tools and identified several weaknessses in all of them. As a consequence, we decided to develop our own tool, search_vulns, which aims at solving all of the identified challenges. In this second post, we introduce our tool, highlight some of its core features and conclude the comparison from our last post. How search_vulns works in detail will be explained in our third post.

As a short teaser, here is a brief overview of our tool in action, showing vulnerabilities and exploits for Wordpress 5.7.2:

If you want to skip ahead and simply use our tool, click on the image above. Also, click here to get to the code.

Introducing search_vulns

We're happy to announce our new tool search_vulns, which provides you with advanced features for retrieving known vulnerabilities and exploits for software. Some of the most prominent features are as follows:

• Unrestricted input: Simply enter the software name and version you're looking for. search_vulns takes care of matching your input to a software ID. Alternatively, you can also enter your own software ID, i.e. Common Platform Enumeration (CPE) string.
• High Result Quality: Since your input is matched to a software ID, search_vulns can use this ID to selectively search for vulnerabilities affecting the queried software version. For vulnerability retrieval, search_vulns primarily uses the National Vulnerability Database (NVD), like many other tools do. In difference to these other tools, search_vulns uses more advanced techniques to correct inconsistencies in the NVD's dataset. Adding to this, we're currently working on including data from the official Ubuntu, Debian and Red Hat security APIs. Once finished, this enables users to append operating system information to their query. In doing so, they can enhance and "correct" the NVD's results if the OS provides backpatches.
• Data Timeliness: Our public web instance is updated daily, meaning you always get access to the latest data. In addition, search_vulns manages to be ahead of time by creating software IDs (CPEs) itself if they don't exist in the NVD's software database yet.
• Data Sources: search_vulns incorporates different data sources, like the NVD, the Exploit-DB, PoC-in-GitHub and endoflife.date. We also plan on including data from the GitHub Security Advisory Database to achieve even more complete and precise results.
• Export Functionalities: Our tool provides rich exporting functionalities for the identified vulnerabilities and exploits. Vulnerability data can be exported in a Markdown, JSON or CSV format. Furthermore, you can filter which vulnerabilities should be exported in which order and with what information.
• Usability: search_vulns can be used in many ways. First, it can be deployed as a web application, as our public instance shows. Second, a command line interface is provided, which means it can be used by other tools in local and automated workflows. The fact that search_vulns works fully offline further increases its usability in such scenarios. In all of these different applications, search_vulns works quickly and without long lookup times.
• Open Source: Our tool is open source, such that anyone can check out the code and contribute.

Next, we describe how our tool with all of these features compares to similar solutions. A more detailed description of how all of these features are implemented will be provided in a third post.

Comparing search_vulns with Other Tools in Regards to Our Requirements

In our last post we identified several requirements a good vulnerability search engine should fulfill. We then compared existing solutions with regard to these requirements. As a brief overview, we provided the following table:

To conclude our comparison, we detail how well search_vulns satisfies these requirements.

Recall and Precision

From our observations, search_vulns' recall and precision outperforms all similar tools we evaluated.

We managed to properly work with and solve the NVD's rare inconsistencies and internal contradictions. Thus, search_vulns manages to find all relevant vulnerabilities for our examples Proftpd 1.3.3c and Thingsboard 3.4.1 from the previous post. At the same time, it does not return any irrelevant or unfitting vulnerabilities.

In addition, search_vulns solves the challenge of deprecated CPEs we mentioned in our previous post. As a result, it does not matter with search_vulns if you search for Piwik or Matomo: both products are considered equal and the queries return good results. search_vulns also partially solves the problem where two CPEs for one product exist without any (known) reason. Since we do not know of an existing resource that contains information about these entries, we manually keep track of such a list. This also enables search_vulns to return good results for our previous example Redis 3.2.3.

Moreover, search_vulns can compare complex version numbers properly, meaning it returns good results for the example in our first post (Huawei Uma V200R001C00SPC100).

Overall, we tried to pick general examples for the challenges we faced during development. We realize this can be perceived as biased and welcome any feedback that helps us improve our tool.

Data Sources

search_vulns currently uses the National Vulnerability Database (NVD), the Exploit-DB, PoC-in-GitHub and endoflife.date as data sources. This enables the tool to access many vulnerabilites and databases. However, it does make search_vulns dependent on the CVE system. This means that if a vulnerability does not have a CVE identifier, search_vulns will not be able to find it. We admit this is a core weakness of search_vulns and intend to add other non-CVE data sources, like SnykDB or the GitHub Security Advisory Database, in the future.

Input Restrictions

search_vulns does not restrict user input. Users can use CPEs or software names and versions to search for known vulnerabilities. Morever, you can also use search_vulns with abbreviations of product names if search_vulns knows the abbreviation. For example, Citrix ADC is understood as Citrix Application Delivery Controller and Dell OMSA as Dell OpenManage Server Administrator. New abbreviations are are added regularly and can be requested as well.

Data Timeliness

search_vulns provides an easily accessible method to completely rebuild the local vulnerability and software database. If you manage your own instance, you can decide how often the database should be updated. The database of our publicly hosted instance is updated daily.

In our last post we mentioned that the NVD's software database is not sufficiently kept up to date. This presents the challenge that you cannot find CPEs for a lot of (more recent) software versions. To mitigate this, search_vulns creates its own CPEs based on the queried software version and existing CPEs for the software in the NVD's dataset. These created CPEs work well and enable search_vulns to successfully retrieve existing vulnerabilities. As a result, search_vulns can outperform most, if not all, existing tools that rely on CPEs for vulnerability search.

Export of Results

In general, search_vulns enables users to export their results in a Markdown or CSV format. Moreover, it allows users to specify exactly which vulnerabilities to export and with which information (CVE-ID, CVSS, description or exploits). In addition, users can rearrange the results according to these four columns, e.g. they could sort the results by year via the CVE-ID. A glimpse of the exporting functionalities in the web interface are provided in the screenshots below. However, these interactive functionalities are best tried first hand.

The CLI of search_vulns allows exporting results in a JSON format. Therefore, search_vulns has rich exporting functionalities for the retrieved vulnerability data.

Performance

In accordance with our last post, we would like to refrain from being too detailed and only provide rough performance boundaries. The query time for the web interface of search_vulns lies below five seconds on general purpose servers in the worst case. In the average case, the query time is about one second. In addition, the web interface uses a caching mechanism, meaning that results of a previous query can be retrieved faster.

When you use search_vulns' CLI, the query time is roughly identical on general purpose notebooks, as long as the same database type is used (SQLite or MariaDB). Furthermore, we observed search_vulns occupying around 65 MB of memory in the average case and 140 MB in the worst case, meaning it can be used in resource constrained environments.

Online vs. Offline

Since search_vulns downloads all necessary data and builds its own database, it can be used fully offline. Furthermore, we have a public instance running at https://search-vulns.com, meaning you can comfortably use it online as well.

Open Source

search_vulns is licensed under the MIT license and available on GitHub. This allows anyone to freely use the software and contribute.

Summary, Conclusion and Future Work

In our first post, we highlighted the need for an efficient and reliable solution to identify whether a software product is affected by any known vulnerabilities. At the same time, we discovered that all solutions we evaluated showed weaknesses with regard to the requirements we defined for a good solution. Most importantly, the solutions had difficulties with returning exactly the vulnerabilities the quried software is affected by. Other problems include input restrictions, date timeliness and exporting capabilities, rendering them less usable. For this reason, we decided to develop our own tool that meets our defined requirements and solves their various challenges.

We started this second post by introducing our tool search_vulns. Thereafter, we completed the comparison from our last post by showing how well search_vulns satisfies our requirements for a good vulnerability search engine. In our third post, we explain in detail how search_vulns works and solves the various challenges.

In the future, we intend to continue developing search_vulns and implement more features. Most prominently, this includes adding more vulnerability and exploit data sources, like the Snyk Vulnerability Database, the GitHub Advisory Database, mvnrepository or 0day.today. Finally, we plan to add support for including information about Operating System backpatches.

If you'd like to check out search_vulns, just go to the homepage and give it a try. Also, if you'd like to set up your own instance or would like to contribute, check out our tool's GitHub repository.