From Low to p0wn (Part 3 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 looked at information disclosure due to security misconfiguration. In the second installment, we explored examples of vulnerability stacking. In the final installment, we will again be looking at an instance of vulnerability stacking, this time, however, we’ll be focused on account management.

I have seen the set of issues I will discuss in this post all reported as low severity. I have also seen instances where the severity has been increased due to the ability to combine the vulnerabilities associated with an application to perform a more advanced attack. This analysis of the vulnerabilities is a significant benefit to having a true application penetration test performed rather than a tools-based vulnerability scan.  

The majority of web applications continue to use a simple username and password form for authorization. The combination of vulnerabilities we’ll examine is username enumeration, weak password requirements, and lack of account lockout. 

Username enumeration comes in many flavors. The majority of applications I’ve assessed have stopped returning specific errors on login telling the user if the account name or password are incorrect. Its most common form recently is in the “forgot password” process for an application. Another common instance is an error message during account creation notifying the user that an account name has already been created. The screenshot below demonstrates one example where a username, email in this case, was enumerable through the account registration process.

Figure 1: Usernames enumerated through brute force

Once an attacker is able to identify valid usernames, the next step in exploitation is associating a password to the account. This is easily automated and is made trivial if the application does not lock out accounts after a set number of failed attempts. In this case, the attacker can potentially try thousands of passwords in a matter of minutes. If users are able to use weak passwords, there is likely not even a need to try that many passwords before an attacker is able to take over an account.

Most users, given the opportunity, will choose poor passwords for their accounts. The following list shows 25 of the most commonly used passwords. These change a little from year to year depending on popular culture events and what the source of the password list is, but the top 10 are fairly consistent. 

123456  

password  

12345678  

qwerty  

12345  123456789  

football  

1234  

1234567  

baseball  welcome  

1234567890  

abc123  

111111  

1qaz2wsx  dragon  

master  

monkey  

letmein  

login  princess  

qwertyuiop  

solo  

passw0rd  

Starwars  

These three fairly common web application vulnerabilities are sufficient to lead to an account takeover. Many times, application scanning tools won’t even identify these vulnerabilities, and when they do, the significance of the combination of vulnerabilities is seldom recognized.

Throughout this series we have investigated a number of issues that commonly go unresolved due to their low severity. These issues when taken individually, at the time of the assessment, may pose little risk, but given the evolving landscape of vulnerabilities, that risk must be reviewed regularly. Additionally, it is important to view all of the application vulnerabilities and evaluate the risk associated when vulnerabilities can be combined to create a more significant attack scenario.