What is the main idea of version-based vulnerability detection, especially for Web Applications? With an access to the HTTP response (html, headers, scripts, etc.), you can get the name and version of some standards web application (e.g. CMS, CRM, wiki, task tracker) or names and versions of software components that this web application uses: web server, libraries, frameworks, and so on.

Next step is to get all known vulnerabilities and exploits for this software. This is the typical task for Vulners.com – largest database and security content searching system (see “Vulners – Google for hacker“).

So, guys from Vulners Team made a set of useful regular expressions for detecting software names and versions – https://vulners.com/api/v3/burp/rules. You can use this rules in your own scripts and if you want something that will work out of the box, you can try existing plugins for Burp Suite and Google Chrome.

In this post I would like to show how the detection rules work, present new Vulners Burp API and vulnerability detection plugins for Burp Suite and Google Chrome.

Detection rules

Each rule has it’s own name, alias, that will be used in Vulners search request, regex for detecting the version of software and the rule type (“software” or “cpe”). Here are some different rules from the rule-file on github:

... "AngularJS, script": { "alias": "Angular", "regex": "/([\\d.]+(?:\\-?rc[.\\d]*)*)/angular(?:\\.min)?\\.js", "type": "software" }, ... "IBM HTTP Server, headers": { "alias": "IBM HTTP Server", "regex": "Server:\\s*IBM_HTTP_Server(?:/([\\d.]+))?", "type": "software" }, ... "Apache, headers": { "alias": "httpd", "regex": "Server:\\s*(?:Apache(?:$|/([\\d.]+)|[^/-])|(?:^|\b)HTTPD)", "type": "software" }, ... "Apache Tomcat, headers": { "alias": "cpe:/a:apache:tomcat", "regex": "X-Powered-By:\\s*\bTomcat\b(?:-([\\d.]+))?", "type": "cpe" }, ... "Atlassian Confluence, html": { "alias": "cpe:/a:atlassian:confluence", "regex": "Powered by a href="[^">]+atlassian\\.com/software/confluence(?:[^>]+>Atlassian Confluence ([\\d.]+))?", "type": "cpe" }, ...

As you can see, “AngularJS” rule will check the scripts, “Apache Tomcat” will check the response headers and the last one, “Atlassian Confluence” is for html content. The regexp will return version of the software. If the rule type is “software”, we will search something like “Angular 1.11.4”, and if the type is “cpe” it will be “cpe:2.3:a:apache:tomcat:7.0.27” or “cpe:/a:atlassian:confluence:6.0”.

Vulners Burp API

Vulners Team presented special Burp API calls, different from the common search API calls that I reviewed earlier. With this new API you can specify the software name and version or the CPE id, and get the list of vulnerabilities in json. For example, try this urls:

Output of the last one:

{ "result": "OK", "data": { "search": [ { "_index": "bulletins", "_type": "bulletin", "_id": "CVE-2017-9505", "_score": 0.019028645, "_source": { "lastseen": "2017-07-04T10:46:34", "bulletinFamily": "NVD", "description": "Atlassian Confluence starting with 4.3.0 before 6.2.1 did not check if a user had permission to view a page when creating a workbox notification about new comments. An attacker who can login to Confluence could receive workbox notifications, which contain the content of comments, for comments added to a page after they started watching it even if they do not have permission to view the page itself.", "modified": "2017-07-03T10:42:36", "published": "2017-06-15T12:29:00", "id": "CVE-2017-9505", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-9505", "title": "CVE-2017-9505", "type": "cve", "cvss": { "score": 4.0, "vector": "AV:NETWORK/AC:LOW/Au:SINGLE_INSTANCE/C:PARTIAL/I:NONE/A:NONE/" } }, "highlight": { "history.bulletin.reporter": [ "<span class=\"vulners-highlight\">NVD</span>", "<span class=\"vulners-highlight\">NVD</span>" ], "bulletinFamily": [ "<span class=\"vulners-highlight\">NVD</span>" ], "history.bulletin.description": [ "Atlassian <span class=\"vulners-highlight\">Confluence</span> starting with 4.3.0 before 6.2.1 did not check if a user had permission to view", "An attacker who can login to <span class=\"vulners-highlight\">Confluence</span> could receive workbox notifications, which contain the content", "Atlassian <span class=\"vulners-highlight\">Confluence</span> starting with 4.3.0 before 6.2.1 did not check if a user had permission to view", "An attacker who can login to <span class=\"vulners-highlight\">Confluence</span> could receive workbox notifications, which contain the content" ], "description": [ "Atlassian <span class=\"vulners-highlight\">Confluence</span> starting with 4.3.0 before 6.2.1 did not check if a user had permission to view", "An attacker who can login to <span class=\"vulners-highlight\">Confluence</span> could receive workbox notifications, which contain the content" ], "cpe": [ "<span class=\"vulners-highlight\">cpe</span>:/<span class=\"vulners-highlight\">a:atlassian:confluence</span>:5.5.2", "<span class=\"vulners-highlight\">cpe</span>:/<span class=\"vulners-highlight\">a:atlassian:confluence</span>:5.10.7", "<span class=\"vulners-highlight\">cpe</span>:/<span class=\"vulners-highlight\">a:atlassian:confluence</span>:5.9.10", "<span class=\"vulners-highlight\">cpe</span>:/<span class=\"vulners-highlight\">a:atlassian:confluence</span>:<span class=\"vulners-highlight\">6.1.4</span>" ], "history.bulletin.bulletinFamily": [ "<span class=\"vulners-highlight\">NVD</span>", "<span class=\"vulners-highlight\">NVD</span>" ], "reporter": [ "<span class=\"vulners-highlight\">NVD</span>" ] }, "sort": [ 0.019028645, 1497529740000 ] } ], "exactMatch": null, "references": null, "total": 1 } }

Accuracy

It’s important to understand that vulnerability will be correctly detected only if there were no errors at all stages:

Formalization of vulnerability description. What versions of the software are actually vulnerable? Can you say for sure that software is vulnerable by knowing only it’s version? In many cases installed patches, including various “cumulative” patches, should be take in into consideration. And you will not get this information from the unauthenticated scan only. Software detection (name and version). Were the software software name and version detected correctly? It’s pretty common situation when software was patched, real version of the software increased, but the version in software banner remained the same “vulnerable”. Version comparison. Sometimes it is tricky to say what version is bigger, because of the epoch numbers and so on.

Why am I writing this? Don’t be surprised if there will be false positives. Version-based detection always requires some post-processing.

Burp Suite plugin

Vulners plugin for Burp Suite is called “Software Vulnerability Scanner“. It is available only in Burp Suite Professional, that costs now $ 349.00 per user, per year.

You can install it in Extender tab -> BApp Store:

In Software Vulnerability Scanner tab you will see a link to json file with all detection rules. You can easily add your own set of rules as well:

There is a good video describing the work with Vulners Burp plugin. In this video Burp-user randomly opens sites from google search results in his web browser with configured Burp Proxy and Vulners Scanner detects vulnerabilities on these sites.

The output of plugin looks like this:

You can see here WordPress CMS version 4.7.5 and the list of vulnerabilities for this version. If you click on each vulnerability, you will get the detailed description and the links to other Vulners.com objects, including exploits.

You can also run Burp Suite with Software Vulnerability Scanner plugin in fully automatic mode. Here is an official manual “Using Burp As a Point-and-Click Scanner“. However, this manual is quite long and is a bit outdated. Here is my short version:

Go to the Burp menu and choose “Restore defaults” for all options.

Project options -> Restore defaults -> ALL. Copy url you want to scan (for example, https://corporation.com) in clipboard. Go to Repeater tab, right-click on the request panel to open the context menu, and select “Paste URL as request”. Press “Go” button. Open the same context menu again, and select “Add to site map”. Go to Target tab, and the Site map sub-tab. Select the domain name for your target application, right-click to open the context menu, and select “Add to scope”. Select the relevant location, right-click to open the context menu, and choose “Spider from here”.

Google Chrome plugin

Let’s see how to get similar functionality without Burp. Install Google Chrome web bowser. And then install Vulners Web Scanner Plugin.

That’s all. Just browse the Internet. If you see an active icon, click on it:

And see the list of vulnerabilities:

All links lead to the Vulners.com website. It’s pretty much like Burp Plugin, but it is completely free.

In conclusion

It works. 🙂 Vulners plugins for Chrome and Burp Suite can detect vulnerabilities. There are, however, plenty of false positives. You have to look through the list of vulnerabilities carefully, make a lot of additional clicks and checks. It’s not easy to automate it yet. Buying Burp Suite Professional only for this plugin seems to be an overkill. And the Chrome plugin is suitable only for casual use: “Look, this site is vulnerable, cool”. It would be great to make a separate scanner script in Python or NSE nmap plugin (upd. the did it, see “Vulners Nmap plugin“). As input, you can use Vulners collections (mainly NVD CVE and Exploits). This would allow to automate the work with such utility, for example, to analyze the entire perimeter of the organization. It would be possible to implement additional heuristics on top to reduce the number of false positives.