How to Test for Account Lockout Vulnerabilities
A web application uses an account lockout policy to protect against clients attempting to log into accounts not belonging to them. However, this protection mechanism can be abused for malicious purposes. Account lockout bugs occur when attackers use an account lockout policy to lock out a legitimate client, thus putting the victim client in a denial-of-service (DoS) situation.
Follow these steps to test for account lockout bugs:
- Step 1: Understand attack scenarios
- Step 2: Analyze causes and countermeasures
- Step 3: Start testing and exploring
Step 1: Understand Attack Scenarios
An account lockout attack is a variant DoS attack aimed at preventing a legitimate client from accessing the application. The attacker needs to know a valid credential from the target client, such as the email address or username that the client uses to log into the application. Once this valid credential is discovered, an attacker launches the account lockout attack simply by trying to log into the application using the valid credential but an invalid password. The login attempt is repeated until the application’s account lockout policy locks the account. If the attack is successful, the victim is then unable to access the application until the account is unlocked.
- Attacker finds out valid credential from target client (username, email address, etc.).
- Attacker tries to log in to application using valid credential but an invalid password.
- Attacker repeats step 2 until the application indicates that the account has been locked.
EBay is a classic example of how attackers exploit account lockout bugs. In one example, a malicious user who wanted to beat his bidding competitors placed a bid for an item and then tried logging into the application three times using the email addresses of the competing bidders, but using incorrect passwords. As a result, eBay locked the accounts of the competitors, who were unable to log in and place a higher bid, allowing the attacker to win the auction.
Step 2: Analyze Causes and Countermeasures
Account lockout bugs exist by design. Locking an account after a certain number of failed login attempts protects users from the risk of credential brute-force/dictionary attacks. To fully avoid this vulnerability, the application must apply an account lockout policy that doesn’t block a legitimate client from using the application, which is insecure because it opens the application to brute-force/dictionary attacks. Therefore, account lockout bugs can be seen as a necessary side effect of implementing credential brute-force protection. To protect against his bug, stakeholders must weigh the risk of an account being locked (thus putting the legitimate user in a DoS scenario) against the risk of an account being broken into using credential brute-force/dictionary attacks.
Setting an account lockout policy in ASP.NET
To use ASP.NET account lockout functionality, developers are encouraged to implement Forms Authentication instead of coding their own account management scheme. Forms Authentication provide a framework for credential storage and management, either by integrating ASP.NET user accounts with Windows or Active Directory accounts or by using a SQL Server membership provider and storing account information in a SQL database.
Once you have selected a membership provider and added the necessary authentication controls and code to your ASP .NET application, you can modify the Web.configfile to specify the account lockout options as follows:
<add name=MyProvider maxInvalidPasswordAttempts=3 and passwordAttemptWindow=10 …/>
Note the maxInvalidPasswordAttempts is the maximum number of invalid login attempts allowed in a time period before locking an account. This time period is indicated by the second variable above, named passwordAttemptWindow, which specifies the time window within which this maximum attempts number applies. If the time of the current failed attempt exceeds the time period from the last failed attempt, it is considered the first invalid password attempt.
Protecting against account lockout attacks
A possible defense against account lockout attacks is to set a loose account lockout policy, but to enforce strong passwords. Ideally, a password must be strong enough to resist brute-force/dictionary attacks, reducing the importance of account lockout policies. Complex passwords are difficult to attack, and in most cases require an automated attack; an account lockout policy can allow more failed login attempts if the password policy enforces complex passwords.
To lessen the impact of account lockout attacks on administrator accounts, it is recommended that administrators use a different account instead of relying on usernames such as administrator, admin, and root. An attacker is likely to use such usernames, since these often exist and since the impact of locking those accounts poses a higher risk to the application.
Another setting that should be looked at is the period time that an account is locked. Account policies that permanently lock down accounts enable attackers to execute permanent DoS attacks on legitimate clients, while account policies that temporarily lock down accounts only allow for temporary DoS attacks. Again, these different scenarios must be discussed in the security context of the specific application.
Additional countermeasures consist of hosting your ASP.NET application in a restricted network environment such as a VPN, thus preventing login attempts that originate from a non-trusted network address. However, such countermeasures rely on network security and are susceptible to network attacks.
Step 3: Start Testing and Exploring
Now that you’ve revised all the theoretical aspects of account lockout bugs, it is necessary to execute test cases to check if your application is vulnerable.
Harvest valid account names
As stated in the attack scenarios section, an account lockout attack requires the knowledge of a credential such as a username or email address. Harvesting valid account names can be done in different ways, including using registration pages that enable anyone to create an account and trying to create an account using a username that already exists. Additional methods include executing social engineering and information disclosure attacks that specifically look for a valid username (not passwords). Once you have a valid user account to attack, you can continue with the account lockout test cases.
Test for account lockout bugs manually
Follow these steps to test for account lockout bugs manually:
- Open an internet browser and navigate to the login page.
- Enter a valid username and an incorrect password, and submit the page.
- Check the response to see if the account was locked out. If the account is locked down, the test case is finished; if not, repeat step 2 for 10 times. The number of failed login attempts can be increased, but it is recommended to use an automated tool for an increased number of login attempts (see the next test case).
Expected result: The application is vulnerable if the account is locked out.
Test for account lockout bugs automatically
You can use a network password cracker tool to automate the login process. Keep in mind that the goal here is to execute repeated login attempts rather than to discover a password.
Follow these steps to test for account lockout bugs automatically:
- Download and install Brutus from http://www.hoobie.net/brutus/.
- Run Brutus.
- Type a target URL and authentication type.
- In the Pass Mode dropdown list, select Brute Force.
- Select range of characters to use. You must use these setting to determine how many failed login attempts you want to try.
- Click Start.
Expected result: The application is vulnerable if the account is locked out.
Account lockout bugs may result in denial-of-service attacks on specific user accounts. They exist as a consequence of protecting against credential brute-force/dictionary attacks with an account lockout policy. To protect against this vulnerability, it is recommended that you analyze the risk of credential-brute force attacks against the risk of account lockout attacks and set the account lockout policy accordingly. Testing for this bug is trivial; it requires harvesting a valid username so that it can be targeted during the attack. Testing can be executed manually in a few steps or by running a network password cracking tool that automates the login process.