(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
Getting to the point of this post, I want to share a tool that aims to help with validating CVE mitigation controls (WAF rules or other server filters) you’ve implemented. The tool contains various PoC payloads (collected from various PoC exploit code on Github and other sources) to test that your mitigating control is properly detecting and blocking the attacks. The tool is not attempting to exploit the vulnerability for verification, but rather it is simulating the attack based on exploit code and expecting the mitigating control to return a specific status code. The status code is the indicator that determines the attack was detected and blocked. For example, some WAFs will return a 403 status code to indicate a block has been enforced. In addition, ease of use helps make testing repeatable for regression testing.
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:
foospidy / web-cve-tests
A simple framework for sending test payloads for known web CVEs.
web-cve-tests
The goal of this tool is to send PoC payloads to verify server-side attack detection solutions. If detected, the server side should return a specified HTTP status code.
This tool is not intended to actually exploit the vulnerability or to test for the existence of the vulnerability.
Usage
Basic:
./webcve.py --url https://target-site.comSpecify detected response code (default is 403):
./webcve.py --url https://target-site.com --status-code 406Verbose (output CVE descriptions):
./webcve.py --url https://target-site.com -vTest a single CVE (with example output):
./webcve.py --url https://target-site.com --status-code 406 --cve CVE-2017-9791 -v
CVE-2017-9791
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)Test for a group of CVEs. Groups are defined in groups.json.
./webcve.py --url https://target-site.com --group strutsTest for a group type of…
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
CVE-2017-9791
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)
Conclusion
When patching a CVE is not possible or delayed, implementing a mitigating control is critical to mitigating the risk of being exposed. Vulnerability scanners can help with indicating if the presence of the vulnerability, but they don’t necessarily verify that mitigating controls are detecting attacks. PoC exploit code can be effective at verifying if the mitigating control is working as expected, but if you need to test for numerous CVEs collecting and managing the various PoC scripts can be burdensome — although Metasploit can help reduce the burden. The web-cve-tests tool aims to provide a simple way to test CVE mitigation by leveraging PoC exploit code from various sources. This tool can be leveraged for quick testing and validation and also made part of a repeatable process for regression testing.
Oldest comments (0)