From Low to p0wn (Part 1 of 3) 

Remember to Remediate Those Low Severity Findings

There is a growing trend in the information security and risk management world of ignoring low severity findings from security testing. Perhaps it stems from PCI allowing organizations to pass audits with outstanding, low severity vulnerabilities. Perhaps it is a result of the volume of findings needing remediation coupled with insufficient resources. Whatever the cause, the result is low severity findings being deprioritized and forgotten. This series explores some of the possible consequences of failing to include low severity vulnerabilities in an organization’s remediation strategy.

In this first installment we’ll take a look at a group of vulnerabilities that OWASP categorizes as “security misconfigurations.” Specifically, we’ll look at cases where the application infrastructure and libraries reveal version information. This comes in a handful of flavors: HTTP headers disclose the version of the web server or the content management system, comments left in JavaScript files reveal the version of a library, or application errors and default error messages disclose the version information of an application server. In all of these cases, the vulnerabilities are generally classified as low severity.

The issue arises the day a critical vulnerability is identified somewhere in the application stack, and becomes severe the day that vulnerability is disclosed.

The Shodan web search allows users to search for web resources not based on the content of the page, but based on the HTTP header information. This gives attackers an easy way to search for vulnerable systems advertising the out-of-date versions of software they are running. Shodan also supports an API, allowing attackers to quickly and programmatically identify likely vulnerable resources.

The figure below demonstrates a search for IIS 6.0; for which support ended with the support of Windows Server 2003 on July 14, 2016.

Figure 1: Shodan search for IIS 6.0

According to the 2016 Verizon Data Breach Report, half of all exploitation occurs between 10 and 100 days following the initial publication of a vulnerability. Based upon the report, the average time to exploitation is 30 days. Once an exploit has been published and is in the wild, the clock is ticking on any server running the vulnerable software. 

In most cases, version disclosure vulnerabilities can be remediated quickly by modifying the server configuration. While the disclosure is not directly exploitable, leaving the finding unfixed increases the exposure to other vulnerabilities.

We’ve demonstrated how a low severity misconfiguration can increase the exposure when an unpatched vulnerability exists within your environment. In the next installment of this series we will investigate common pitfalls related to session management.