Strict Rate Limiting Policy Leads to Massive DoS
The following article is written based on my personal experience penetration testing web applications. Hope you enjoy it!
Introduction
As we all know, authentication endpoint has always been the first line of defense of web applications. It functions as the endpoint which verifies the identity of a currently existing user in the database or from a third-party authentication service (OAuth). In a glimpse of an ordinary eye, authentication endpoints are perceived as a security mechanism, but for black hat hackers, it is an additional attack surface that can cause devastating impact. Therefore, it is important for developers to implement policies and additional mechanisms to support their authentication endpoint. In this article, I will be discussing an interesting observation on how policies implemented on authentication endpoint could backfire and turn into massive DoS.
One of the main vulnerabilities on authentication endpoints is Brute Force Attack. According to forcepoint.com, a brute force attack, also known as an exhaustive search, is a cryptographic hack that relies on guessing possible combinations of a targeted password until the correct password is discovered. This means that every web application with authentication endpoints is susceptible to Brute Force Attack by default. Although this is a simple and ‘dumb’ way to guess user’s credentials, 5% of confirmed data breach incidents in 2017 stemmed from brute force attacks.
Current Solutions
As we all know, Brute Force Attack relies on requesting the authentication endpoint until the user’s credential is guessed, therefore thousands even millions of requests will be sent to the server in order to perform the attack. How do we combat this? Rate Limiting! It is a policy implemented in order to limit network traffic by putting a maximum number of requests allowed in a timeframe. Going in-depth, Rate Limiting can be implemented in a couple of different ways, but two of the most popular ways are:
- IP Based
- Account Based
IP Based Rate Limiting
In an IP based Rate Limiting, unusual network activities will be detected by the web application or server via the incoming IP Address. If an IP address has exceeded the maximum number of requests allowed during a specified timeframe, the webserver will not fulfill the IP address requests for a certain amount of time. A typical response from the web application or server will be an ‘HTTP 429 Too Many Requests’ status code. The problem emerges when other arbitrary users on the same network decide to send requests to the authentication endpoint to authenticate themselves. Since they are sending their request from the same network, the web application will respond with the ‘HTTP 429 Too Many Request’ status code too. A potential attack scenario will be executing a brute force attack on the target company’s Wi-Fi network. This will block their employee’s authentication endpoint access and therefore inflicting denial of service throughout the company’s Wi-Fi network. Note that proxy can be used to bypass IP Based Rate Limiting mechanism.
Account Based
On the contrary, an Account Based Rate Limiting allows the web application or server to block unusual activities coming from specific accounts. When the web application or server detects an unusual amount of authentication attempts, the rate-limiting solution will block the account according to the rate-limiting policy implemented. This means that trying to authenticate the account using other networks will be pointless since the account has been flagged. At a glance, this might look like a better solution in comparison to the IP Based Rate Limiting, but an even bigger problem emerges here. An attacker could create a simple script or even use existing security existing software to exhaust the rate-limiting policy and potentially block a huge number of accounts.
Since the denial of service only happens on the authentication endpoint, logged in users will not be affected by the attack, but another creative way to completely block off access to the web application is by chaining Logout CSRF with the Brute Force attack. This will have an even tremendous impact if inflicted on companies with a time-sensitive business model such as; Trading, Loan, and etc.
Optimal Solution
As we all know, both common practices of Rate Limiting stated above have their pros and cons. In order to create a close to perfect solution for rate limiting, web application owners could implement the following:
- Implementing a Stronger Password Policy: A strong password policy must be at least 8 characters long and should contain uppercase letters, lowercase letters, numbers, and characters. In addition, new passwords should be unique from previously used passwords and should not contain personal details.
- Implementing CAPTCHA: A very good and effective defense is using CAPTCHA. This would prevent attackers from automating their Brute Force attack.
- Implementing Exponential Time Ban: Rather than permanently blocking the account for a specific time frame, it is recommended to have an exponential time ban (e.g. 1hr, 4hr, 16hr, 24hr, and Contact CS). This will hinder the attacker’s attack flow.
I have seen multiple big companies still implementing ‘half-baked’ Rate Limiting Policies. The solution above should be taken into consideration for all web application owners with ‘unprotected’ authentication endpoints. At the end of the day, it is important for web application owners to maintain the highest level of security for their users. A simple action of putting CAPTCHA on their authentication endpoint would entirely change the game. Drop a clap and comment if you enjoy this article. Thank you for your time. Have a nice day!
