Introduction

As organizations mature, stronger security controls such as strict firewall rules, WAF, VPN, etc., are implemented to ensure they are safe from attackers. Attackers target web authentication methods like simple username / password combinations, which are commonly implemented in all applications.

As part of web application security testing, one of the things security testers do is to check if the application has implemented any form of weak / default passwords which can be easily guessed. The Open Web Application Security Project (OWASP), as part of Web Application Security Testing Guide (WASTG), has dedicated a chapter on Testing for Weak Account Lockout Mechanism.

Configuration Changes / Tools Used

Security testers commonly use Burp Suite, an integrated platform containing various tools such as Scanner, Intruder, Decoder, etc., which allows for a good and seamless testing experience, from initial mapping of the application attack surface to finding and exploiting various application vulnerabilities. Using Burp, one can have full control over manual techniques, including automation, which makes testing easy and convenient.

Using built-in tools such as Intruder present in Burp Proxy, attackers can perform password spraying attacks as Intruder tests multiple passwords in a short period of time.

Common Issues Encountered

Weak passwords are an industry wide problem and there are several news articles about data breaches which have happened due to default passwords or employees using easily guessable passwords. Customers from all industry verticals, specially Banking, Financial Services and Insurance (BFSI) and other allied industries, should pay more attention to this as there is a huge financial impact if there are no safeguards in place for their applications.

Password Spraying of credentials if there is no lockout implemented is part of the OWASP Top 10 2017 and comes under the A2: Broken Authentication category. Given the importance of this, there are several ways to test for account lockout mechanisms.

The below screenshot shows how to enable proxying in Mozilla Firefox. To get to the Connection Settings follow the below steps:

The proxy options will vary from browser to browser.

Proxy in this context is a piece of software sitting on the tester’s machine which allows the requests going to the server to be intercepted by the tester and manipulated before it is forwarded to the server.

The below screenshot shows the port used by Burp and the IP of the localhost (the computer where Burp is installed) and used to capture the traffic. The same IP and port details need to be entered in to the browser’s proxy configuration.

Set Up for Testing

For the purpose of this demo the following tools will be used:

Once the application is installed and traffic is captured in Burp, the color in the Intercept tab will change to orange as shown below. Ensure that the Intercept button is turned on to intercept the requests.

To begin brute forcing, first enter a user name and password in the login page and capture the request in Burp Proxy.

Once the request is captured the Intercept tab will show the login request in either a GET / POST format along with cookie values, header information along with the login credentials which is required by the server.

Burp Suite contains Intruder, one of the suite of tools integrated along with Proxy, which allows for automation of many common attacks. Intruder is one of the tabs present in Burp.

To send the request to Intruder, right click anywhere in the request window and from the menu options, select Send to Intruder. The tester needs to be in the Proxy tab viewing the request that needs to be sent to Intruder.

Once the request is sent to Intruder, the Intruder window is automatically shown with the selected request.

Intruder auto selects the positions based on the parameters present in the request. When the request is sent to the Intruder, the parameters present in the GET / POST request and cookies are automatically populated with the § symbol, indicating all these will be targeted in the attack.

These can be left as is (if required) or customized by clicking the clear button and selecting the required parameter and clicking the “Add §” button present at the right hand side. This will place the § symbol in the start and end positions of the required parameter as shown in the screenshot below.

In this scenario, as we are performing a brute force attack, we want to target the password as we already know the username. Select Sniper as the Attack Type. This is the default attack type and can be changed from the drop-down based on the type of testing being conducted.

Intruder has different attack types such as Sniper, Cluster Bomb, Pitchfork and Battering Ram. These can be used based on different attack scenarios.

As we have decided to target the password, a predefined list of passwords can be used. The passwords can be generated using various tools or, if the tester already has list of passwords, they can be pasted in.

Go to the payloads tab and Load the password file if a list is already prepopulated or add individual passwords manually by clicking on the Add tab.

Once all the passwords are added, click the Start Attack button. Intruder will iterate through the various password combinations. In this example, upon finding the correct password, the response will show up in Intruder with a different status code and length.

The meaning of the status codes are given below:

200 OK – This indicates the request has succeeded. The information returned with the response is dependent on the method used in the request.

302 Found – This indicates the requested resource is residing in a different URI. In this example as the Intruder uses the correct password, the request is redirected to a different URI after a successful authentication from the server.

The response varies for each attack scenario, and the tester needs to pay attention to the response behaviors to notice the difference when Intruder uses the correct password.

Conclusion

This blog post illustrates how the Intruder tool in Burp Suite can be used to automate testing for weak / easily guessable passwords.

The example shown will not work if the application has implemented a password lockout after a certain threshold of failed attempts were made. Further configurations could integrate Single Sign On into the application, which could allow authentications to follow corporate established password policies. Additionally, implementing a multi-factor authentication (MFA) mechanism in place as MFA is one of the best methods to prevent unauthorized access to applications. Showing a CAPTCHA after specific number of attempts are exhausted is another way to prevent brute forcing.