Denial of Service: Creating Mayhem was never so Easy
In this blog, I will be talking about a very critical vulnerability in the authentication mechanism of a web application that leads to Denial of Service (DOS).
A Denial of Service, as the name suggests is a scenario where a service becomes unavailable for a legitimate user. The reason could be anything like the whole application went down, or the user’s account got terminated (remember what happened with Trump?), or anything which causes a disruption of service to a legitimate user.
Whenever a user creates his account on a web portal, his credentials are stored in a backend database. The user’s password is a very sensitive information so a sane developer will not store the plaintext password in the database, rather he stores the hash of the password. During login the web application again converts the password input by the user into a hash and matches it to the one already present in its database. If the hash matches then the user is logged in otherwise NO NO.
A hash of a string or a file is calculated after passing it through a very complex mathematical function. This hash, once generated cannot be reversed. Well, psychopaths can reverse it by guessing. These mathematical functions are so complex that it sometimes uses up a lot of memory space and processing power of the underlying system.
So, suppose if an attacker provides a very large string in the password field during account registration and the web application accepts it, then during login the web application will have to convert the long string input into a hash and it may take up a huge part of the processing capacity of the underlying machine, simply leaving it hung. This will now cause a disruption of service because the web application has gone down, or in other words DOS.
To demonstrate this issue, I have used an outdated version of Organizr which is vulnerable to the same issue and has CVE-2022–1698 named to it.
Create an account on the portal and log in, we have the reset password functionality. Create a very long string using the python shell.
'marty' * 255684
Copy this long string, put it into the new password field and submit. Observe that after some delay it gets accepted.
Log out now and try logging in again using the new long password. Observe that there is a significant delay of around a minute in the server’s response.
This is a clear sign of a flaw in the web application.
Start replaying this request using a bruteforcer such as Burp Suite’s intruder. Only 20 consequent requests are more than enough to crash the web application.
It will come back up eventually within 3–5 minutes after the bruteforcer ends, but the existence of the vulnerability is clear.
Even after it comes back up, it does not behave as intended. I tried logging in with the same user credentials but it shows a blank page and another Login button at the top which doesn’t work.
The root cause of this problem is the fact that the web application does not validate the length of the string that the user provides for the Password. Implementing a check on it and rejecting anything that is above 30 characters is the best way to resolve this issue. 30 is not my lucky number BTW, its just more than enough long to remember as a password.
Conclusion
In conclusion, a Long Password Denial-of-Service (DOS) attack is a type of cyber attack that can cause significant damage to a targeted system or network. By flooding the system with large and complex password attempts, attackers can overwhelm the server and make it difficult or impossible for legitimate users to access the system.
Lets get in touch: Add me on Linkedin, or Instagram works too.
