Sunday, November 24, 2013

Low Severity Vulnerabilities

Many technology and software organizations maintain a dangerous policy for remediating security assessment findings: "We fix the highs and mediums. Everything else can wait."

I recently conducted a penetration test a web application for a client who themselves did security assessments. This was an important application for the client. Functionally it was little more than a CRUD application, allowing users of various privilege levels the ability to create, read, update, and delete highly sensitive data. Mine was the fourth such assessment that this version of the application had received and after three rounds of remediation the client expected to pass easily.

My results? I uncovered one medium-severity finding and about a dozen low-severity findings.

Was the client disappointed? Only a little. They weren’t expecting the medium. The lows they had known about, in some cases for years. Their application has been accumulating them, each round of penetration tests adding one or two before their routine push to production.

There are a few reasons why this is dangerous.

Vulnerabilities combine with each other. When they do, their impact combines in ways which are not additive or even multiplicative.

Chris Gates is an expert at finding vulnerabilities in enterprise software. His phrase for this property is "Low to Pwned," and he has collected a number of case studies here.

One of the examples he offers is of a JBOSS installation with an exposed server-status URL and GET request parameters that include the session token. Both defects are commonly ranked as low severity. When they appear together in the same system an attacker can easily hijack any current session by reading the server-status page and copying those session tokens.

In his talk Gates demonstrates several of these problems and shows how they can be exploited with high business impact. Here's a recording of the talk he gave at hash days, it's well worth a watch.

This problem is compounded where vulnerabilities are scored with CVSS. The CVSS scoring guidelines clearly state “vulnerability scoring should not take into account any interaction with other vulnerabilities.” This guideline ensures that CVSS will give a lower score to all vulnerabilities that interact with any other vulnerability.

Another danger is that penetration tests don't uncover every defect.

Consider an application that is deemed by risk management to have marginal value to the organization. Perhaps it's a blog that caters to an industry segment of the customer base. Marketing says that it drives sales and no one cares enough to disagree with them. No PII, no intellectual property, it's not even in the same DMZ as everything else. Penetration testing finds the following: "Session cookie with promiscuous domain and path settings" and "Missing HttpOnly Attribute in Session Cookie." Both are low-severity. The first is even a justified business requirement, as the blog's administration login is tied to SSO.

These two lows don’t combine in any interesting way. What happens if this site has reflected cross-site scripting along with a promiscuous cookie scope and JavaScript-accessible cookies? An attacker who discovers what a time-boxed penetration tester did not can whip up an attack that sends SSO tokens to an external server. The next effect is that the outside attacker gets an SSO session token. I wonder if webmail is tied to SSO....

Another danger is that severity ratings are estimates. By definition then, about half the time they are underestimates.

Penetration testers frequently don’t have a complete threat model to work off of. Once, a tester who worked for me wrote up a vulnerability that involved some misconfigured sudo rules on a system for which only administrators had logins. This vulnerability allowed one administrator-level role to access the files of another administrator-level role. At the 10,000 foot-view of visio documents, this is a non-issue. Just to make sure though, I stopped by the cubicle of system administrator who was responsible for the misconfiguration and asked ‘what happens if these guys can read your files? Is that a low-severity finding?’ He explained that no-no-no, it was a high-severity finding.

I recommend that organizations remediate those vulnerabilities that are worth fixing. This is a vague recommendation that I intend to flesh out later. For now, let it be known that some low-severity vulnerabilities are worth fixing.