Capitalising on simplicity, brute-force attacks have long been the noisy and least elegant method of exploiting authentication mechanisms. The origins of brute-force techniques date back to the wartime code breaking of Bletchley Park and have since evolved to become a well known but elementary approach attackers use to gain unauthorised access to services and user accounts.

Brute-force attacks are not strictly limited to exploiting authentication mechanisms. Web applications in particular can have many logic flaws that allow attackers to take advantage of the app’s rich functionality through brute-force techniques. However, for the purposes of this article we will focus predominantly on how they relate to web app authentication.

This article will help you to understand what brute-force login attacks are, what impact they can have, and how we can attempt to prevent the techniques that attackers use.

What Are Brute-Force Login Attacks?

Brute-force login attacks involve working through a list of possible username/password combinations in order to gain successful login access to an application or to attain higher privileges. This process is typically automated, utilising computer logic to send several login requests per second to the victim system or application.

Were these attacks are successful, the attacker may gain access to confidential user data and system functionality, which could have a detrimental impacts such as compromised user data and an organisation’s reputation.

There are three main types of brute-force login attacks:

1. Credential Stuffing

Credential stuffing is a technique were the attacker attempts to log in using known username/password pairs that may have been obtained in previous attacks or data breaches.

Often users will use the same or similar passwords across all their accounts. This can be dangerous if one system or web application suffers a data breach and password hashes become public, as attackers may use these compromised passwords to login to other apps.

2. Traditional Brute-Force

The traditional technique involves trying several username/password combinations by iterating through a list of common passwords for each known username in order to gain login access.

This is often the least effective technique due to lockout policies that are typically implemented in most login mechanisms and it is also the noisiest technique.

3. Password Spraying

Password spraying is similar to the traditional technique but instead of using a list of common passwords for each username, a few common passwords are targeted against all usernames.

This technique allows the attacker to try a few common passwords against a list of valid users in the belief that at least one of these users may use this password. This method can reduce the risk of locking accounts since you can attempt each password for all accounts up until you reach the lockout threshold.

The Anatomy of a Brute-Force Login Attack

Typical Requirements

There are a few things an attacker will typically need for their brute-force login attack to be successful:

•   A valid username list: This could be obtained through brute-force username enumeration techniques or can be compiled through open source intelligence.

•   A vulnerable login mechanism: The attacker needs a login form that either has no brute-force protection mechanisms or a viable way to bypass these protections. These protections also include IP address whitelisting and similar strict access controls.

•   A weak password policy: Although not strictly a necessity, attackers will use a list of common or likely passwords that will typically be more successful against applications were users have weaker passwords.

The Basic Steps of an Attack

For the purposes of this article we will be using PortSwigger’s Burp Suite Pro:

1.   The attacker will intercept login request through Burp Suite’s web proxy.

2.   The attacker will then send this request to Intruder (Burp Suite’s automated request tool).

3.   The value of the username parameter is then set to a valid username and the password parameter’s value is highlighted as the field the attacker wants to brute-force.

4.   The attacker provides a list of potential passwords that will be tried against the victim username.

5.   The attacker initiates the attack and receives a 302 redirect code among the results, signifying that authentication was successful for that password. The attacker can now login with that username-password combination and gain unauthorised access to that user’s account.

Prevention Methods

Although brute-force attacks are relatively simple for attackers to perform, prevention methods can be misleadingly difficult to implement effectively. Due to the stateless nature of the HTTP protocol, many prevention methods can be weakened or bypassed altogether by attackers. Developers will also need to consider the user experience, striking a balance between ease-of-use and security which can be a challenge.

Account-Based Lockout

Account-based lockouts are the most well-known form of brute-force prevention. This protection mechanism will prevent any attempts to login to the account after a certain number of failed login attempts have been received. The account will typically lock for a given duration or until and administrator unlocks it, stopping any further username/password pair guessing. This essentially stops an attacker from gaining access to the account via brute-force attacks or at the very least will slow them down significantly.

Risks and Bypasses

While account based lockout mechanisms are highly effective at preventing attackers from accessing specific accounts, this prevention method opens the application to Denial-of-Service (DoS) vulnerabilities. Let’s say that the attacker obtains access to a list of valid usernames either through open-source intelligence gathering or through username enumeration on the application itself. The attacker could potentially send the required number of failed login attempts to lock the account for all valid users on their compiled list, denying availability to all these users.

Account-based lockout protection is also ineffective against password spraying, as the attacker is likely to avoid passing the threshold for the number of failed login attempts.

Recommendations

When thinking about implementing account based lockout, try to set a duration for the lockout so that it unlocks automatically after a given amount of time. This will reduce the impact if a large number of accounts are locked out by an attack (rather than an administrator unlocking them manually or the users needing to make a recovery request). It’s important that you don’t make this duration too short. For example, if the lockout duration is set for one minute, and the threshold is set at four attempts, the attacker could potentially try 240 combinations per hour, which can add up if you then multiply this by the number of valid usernames the attacker has. Setting the duration for at least 30 minutes is a good standard for implementing this type of protection.

Using account based lockout protection in combination with other preventative mechanisms can often be an effective way of staving off an attacker’s interest and keeping your web applications safe.

IP Address-Based Lockout

Lockouts based on IP addresses are similar to account based lockouts but instead of locking out individual accounts after a given number of failed login attempts, the IP address of the attacker is locked from making any further login attempts. The failed login attempts can be against any user as the counter for these attempts is linked to the IP address of the requestor. This can allow applications to identify IP addresses that are attempting to brute-force the login form and block any further brute-force attempts.

Risks and Bypasses

The greatest issue with implementing IP address-based lockouts is determining how to effectively track the right IP address for each request the web application receives. For example, as many users browse the application, it would make sense to block based on the direct IP address of the HTTP connection. However, difficulty arises when you consider that requests may be sent through a public proxy. By blocking the direct IP address you would block any requests sent through that proxy, effectively denying access to any user that uses it. Many websites will therefore use the IP address specified in the X-Forwarded-For header that is typically added when passing through a proxy to tell the application what the origin IP address is for the sender.

Unfortunately, because this X-Forwarded-For header is supplied by the client, attackers can manipulate the X-Forwarded-For header to mask their IP address, allowing them to fool the application into thinking the request is coming from a different address each time. This bypass is just one technique that could be used to circumvent your controls. Another notable bypass, this time for direct IP address blocking is where an attacker rotates their IP address for each request using a list of public proxies.

Recommendations

Since there are many ways that attackers can get around IP address-based lockout, it’s generally a good idea to employ a defence-in-depth strategy and combine both lockouts for IP addresses and accounts themselves. This way even if the attacker can circumvent an app’s IP-based lockout controls, they will hit the account-based lockout controls which will make brute-forcing more difficult and less attractive to the attacker.

Non-Lockout Rate Limiting

There are other rate limiting factors that are not lockout-based and are useful for slowing down attackers and making your application a less attractive target. The most notable mechanism is the CAPTCHA form, that requires human input in order for the request to be accepted and sent to the server. This can be effective at stifling the bot-led automated brute-force attacks, especially when employed on an account basis rather than an IP basis. Another simple but effective technique that slows down attackers is increasing the time it takes for the login request to be completed.

Recommendations

Using a CAPTCHA form can be very effective when applied on an account basis, as the attacker can rotate their IP address trying to brute-force an account but after a certain number of failed attempts a human input will be needed to send the request limiting the effectiveness of their automated tools.

It will also increase the time taken for a login request to be processed. For the end user, a small increase in time for the login request will likely go unnoticed. However, for the attacker who is sending a large number of requests per second, it’s likely to slow them down dramatically.

Additional Impact Reduction Measures

In the event that an attacker is able to successfully bypass your brute-force defences, there are many ways that you can reduce the impact of the attack. Some of these are outlined below:

•   Two-Factor Authentication (2FA): Ensuring users set up two-factor authentication may prevent attackers from gaining immediate access to the account were they find a valid username/password pair.

•   Strong Password Policy: Enforcing a strong password policy will prevent users from using weak passwords that can be easily guessed during a brute-force attack. This will reduce the number of accounts that are successfully accessed by the attacker.

•   Keep Usernames Safe: There are many ways an attacker can abuse the functionality of an application to generate a list of possible usernames. By ensuring that your application doesn’t leak any valid usernames, the attacker may have a smaller list to work with and a lower chance of success with password spraying techniques.

•   Hide Admin Login Pages: The web path to admin login panels should be changed from their default placement so that attackers can’t easily find the page to execute their attacks.

•   Effective Monitoring: Having some form of access log monitoring will allow an organisation to be alerted when malicious traffic is observed which gives them time to react before there has been a significant impact to the app’s security.

Conclusion

Brute-force login attacks will continue to be a threat for as long as password-based authentication mechanisms remain popular. When protecting your own login mechanism from brute-force attacks, it’s important to have a defence-in-depth mindset, implementing security controls wherever you can were it doesn’t impact the user experience too much.

If you are looking to test the security of your web application, including the posture of your authentication workflows, then consider having a third party conduct a penetration test. The testing will determine where your web application security is weak and provide recommendations on how to secure these vulnerabilities so that they can’t be exploited by attackers going forward.

Predatech is a cyber security consultancy that offers a range of services including CREST accredited penetration testing and Cyber Essentials/Cyber Essentials Plus assessments. What makes us different? We combine expert cyber security with great customer service and value for money. If you would like to find out more about how Predatech can help you secure your web application, please contact us for a free consultation.