From Low to p0wn (Part 2 of 3) 

Remember to Remediate Those Low Severity Findings

This series explores the potential risk of de-prioritizing and ignoring low severity application vulnerabilities. In the first installment of this series, we discussed information disclosure due to security misconfiguration. In this installment we look at an example of vulnerability stacking. If an application is vulnerable to the right combination of low severity vulnerabilities, the result can be a situation where the risk of a successful attack is significantly increased.

In the scenario, we focus on session management. The most common session management mechanism is a session cookie. We commonly see session cookies without the secure flag. Issues like weak SSL encryption ciphers, the presence of an invalid SSL certificate or missing the HTTP Strict Transport Security (HSTS) header weaken the security posture of the application and increase the likelihood of an attacker being able to intercept and view the application communications.

On a shared Wi-Fi network, like in a coffee shop, all an attacker needs to do is convince the victim to visit an application over an insecure HTTP connection. The application in question doesn’t host content over HTTP though, right? If the session cookies are not marked secure and the HSTS header is not set, an attacker can convince the user to access a specially crafted URL and the session cookies will be sent unencrypted.  As an example the URL would be http://www.example.com:443, the specially crafted URL connects to port 443 but does not utilize HTTPS. 

In another scenario, the victim is again on a shared network but the attacker this time is using a Wi-Fi Pineapple. In this scenario, the attacker is intercepting and controlling network traffic using Karma and SSLstrip, to remove any TLS protections from the victim’s request and thus observing their session cookies. Simply, the attacker is requesting the HTTPS page and sending them a HTTP version of the page. The user will most likely never notice that they are not seeing the HTTPS header on their browser.

Versus:

If the application hasn’t set the HSTS header in a previous session, the browser will proceed over the insecure connection, providing the attacker with the session information and all transmitted data.

Each of these vulnerabilities if taken individually pose little risk to the application or its users. Application vulnerability scanners commonly report all of these as a low severity. It is only with the addition of a trained penetration tester with the knowledge of how vulnerabilities are related that the true risk of combining these vulnerabilities can be assessed.

In our third and final installment of this series, we will investigate authentication issues including enumeration, password strength and missing account lockout mechanisms.