This week security researcher Laxman Muthiyah published his bugbounty write-up “How I Might Have Hacked Any Microsoft Account“. For his finding, he was paid a bugbounty of $50,000 by Microsoft. The researcher describes a vulnerability that theoretically can be used to bypass a rate limit which results in brute-forcing a code. Theoretically, a 6-digit code (1 million necessary attempts) can be guessed. To do this, you would need to send 1 million requests from 1,000 different IP addresses with all possible code variants at the same time. As a result, it can brute-force the 6-digit code of the “forgot password” function and the 6-digit code of the multi-factor authentication. Thus, theoretically, any Microsoft account can be hijacked.
He did not perform a real attack, because as Muthiyah writes “It is not at all an easy process to send such large number of concurrent requests, that would require a lot of computing resources as well as 1000s of IP address to complete the attack successfully.” A PoC with 1,000 successful requests and the described procedure were already enough for Microsoft to validate the finding and pay out the $50,000 bounty.
It is not named in his write-up, but this vulnerability is a race condition in the rate limiting function. The researcher describes that he managed to circumvent the rate limiting by making a high number of simultaneous requests: “After a few days, I realized that they are blacklisting the IP address if all the requests we send don’t hit the server at the same time, even a few milliseconds delay between the requests allowed the server to detect the attack and block it.”
It’s just perfect timing that I developed a tool with such a approach. So the attack can be done not only in theory, but also in practice.
Exploiting Race Conditions
For six months I have been writing my master thesis about race conditions in web applications. This bugbounty write-up comes just in time. Because for the process described by Muthiyah to send up to 1 million simultaneous/concurrent requests I wrote a tool which introduces a distributed architecture. There I chose a new multi-server approach. This has the advantage that the requests come from different IP addresses and are closer to the destination depending on the race servers used. Therefore, one could also call it a Distributed On Race vulnerability because multiple resources are required.
Race conditions are very difficult to find. I am not aware of any automated SAST and DAST tools to find this type of vulnerability (if there is something out there, please DM me!). The toolset is very limited. Unfortunately, race conditions are rarely in the scope of penetration tests and they are hard to find, as they sometimes only appear under heavy load.
Raceocat – Make exploiting race conditions in web applications highly efficient and ease-of-use.
The tool I developed is a Browser add-on and comes with two scripts for the server infrastructure. Additionally I also created an OWASP ZAP plugin. I am looking forward to publish these tools by end of the year 2021 (see update section below).
Further resources
There are great tools to test your applications for Race Conditions such as Burp Turbo intruder and race-the-web. However, these are executed locally on the attacker’s computer. To perform the described attack a distributed architecture with different IP addresses is needed.
I recommend the following websites to learn more about race conditions:
- https://defuse.ca/race-conditions-in-web-applications.htm
- https://wiki.owasp.org/index.php/Reviewing_Code_for_Race_Conditions
Update 2022-03:
- Master Thesis: Race Condition Vulnerabilities in Web Applications (in German)
- GitHub Repository: Raceocat
really informative