Simple Tool for Testing CVE Mitigation in Web Apps

Image for post
Image for post
Photo by VADIM GHIRDA/AP — source

With Internet exposed web applications prompt mitigation of CVE (Common Vulnerabilities and Exposures) is critical. When a new CVE has been announced the response drill is all too familiar to InfoSec teams. First, evaluate the details of the CVE to determine if any of their applications are impacted. In many cases, it’s a scramble to try and discover if the vulnerable framework or code is even being used in their environment. Next, Google searching to find any proof of concept (PoC) exploit code that may have been published. Finally, once vulnerable web applications have been identified, initiate the patching process as soon as a patch is available.

Patching a CVE as quickly as possible is critical as published PoC exploit code is typically weaponized within malicious automation that is continuously scanning the Internet for vulnerable victims.

In some situations patching the vulnerability is either not an option or it could take weeks for the patch to be deployed in production. In these cases, applications are left exposed, so an alternate mitigating control is required. This often comes in the form of a new rule in the Web Application Firewall (WAF) or some other web server filter. When deploying these rules, validation of its efficacy is important (trust but verify). To perform validation there are a few options:

  • Vulnerability scanner — scanners generally try to determine if you are vulnerable in a passive manner, e.g. looking for version strings in headers or looking for other attributes that indicate the vulnerable code is present. For some vulnerabilities, not all, a scanner can attempt a benign exploit attempt to determine if the application is vulnerable. However, it does not actively validate if your mitigating control is effective. If your mitigating control returns a result the scanner did not expect then the scanner would report the application is not vulnerable.
  • PoC exploit code — PoC exploit code can be a good way to validate a mitigating control. They are crafted for the specific vulnerability and will attempt to exploit it and perform some level of exploit verification. However, PoC exploits can come from multiple sources, Github is a typical source. It’s common for single CVE to have multiple sources for a PoC exploit — spread across several projects on Github or other repositories. This can become a bit cumbersome to manage. However, Metasploit can help to consolidate the management effort as it will have exploit modules for many of the CVEs.

In addition to mitigating the risk of an attack, adding CVE specific rules to your WAF for detection purposes can be useful — even if the vulnerability is patched. The information gathered from attack attempts can be fed into your threat intelligence or anomaly detection systems.

A Simple Tool

This simple tool is a Python script and does not have a fancy name, it’s just humbly called web-cve-tests. You can find it on Github here:

It currently contains tests for 26 CVEs (see the full list here), but I’ll continue to update it as often as I can, and as new CVEs impacting web applications are announced. As an open source project, contributions are always welcome. Especially, if the broader community finds this tool useful and would like to see it evolve. If you are in AppSec and are handy with the Python — hint hint ;-)

By just passing the target URL, web-cve-tests will launch all CVE tests. You can also specify a single CVE to test or a group of CVEs. For example, if you only want to test all Struts CVEs you’d pass the command line option --group struts.

Below is an example of execution and output. In this example, a status code of 406 is expected to confirm detection, a single CVE is specified for the test (CVE-2017–9791), and output is set to verbose. Each test has a variant attack payload for the one CVE.

./webcve.py --url https://target-site.com --status-code 406 \
--cve CVE-2017-9791 -v

The Struts 1 plugin in Apache Struts 2.3.x might allow remote code execution via a malicious field value passed in a raw message to the ActionMessage.
Test passed (406)
Test passed (406)
Test passed (406)
Test passed (406)


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store