Real Life Exploit Validation - CODA Intelligence

Footprint Real Life Exploit Validation (RLE)

Too many times vulnerabilities are overlooked or hyper-inflated because there is little information around them. CODA is committed to support IT & Security professionals reduce their attack surface by increasing the accuracy of vulnerability detection, reducing the number of false positives and reducing the mean time to remediation (MTTR). Through the implementation of the RLE capability, Footprint is able to accurately score complex vulnerability scenarios by making practical validations which take into consideration the live environmental and temporal factors of complex vulnerabilities as they exist within customer environments.

How RLEs increase accuracy

Footprint’s RLE capability is able to account for a series of alternative mitigations such as Group Policy Settings, Service Settings, service configurations, which are measured live within the actual environment, for each device which may be theoretically affected by a vulnerability.

Let’s take Tomcat’s critical RCE vulnerability (CVE-2019-0232) which requires 7 steps to be able to actually exploit this vulnerability in the wild. We call them Exploit Validation Scenarios and treat them independently by validating the service configuration against the vulnerable configurations that enable exploitation. Failing any one of the 7 validation steps renders this vulnerability unexploitable in real-life, thus rendering it useless for the attackers. However, if only step 7 is failing, attackers can try to exploit other vulnerabilities in order to upload malicious files, which they can later trigger to exploit the attack killchain.

Reduce Exposure Time

Patching may not be the quickest or the best way to fix a vulnerability in short-term. This is especially applicable for zero-days, which by definition don’t have a patch released just yet. Therefore RLE checks help remediation teams implement alternative security measures (workarounds) that can make that vulnerability more difficult or even impossible to exploit.

Let’s take the PrintNightmare example, also known as CVE-2021-34527, patches were made available after 7 days since the vulnerability disclosure. However, Microsoft provided alternative solutions which were applicable from the get-go.

Furthermore, patching may not be sufficient at all times. In the same PrintNightmare vulnerability, applying the patches may not be sufficient, it the registry keys have been changed over time away from the default settings. Therefore, relying solely on the patch being applied, may generate a false sense of security (or a False Negative in terms of Vulnerability Detection).