Articles and blogs

Next to this research, we found multiple blogs of primarily security researchers and testers explaining certain race condition exploitation techniques. Sometimes, they even include a proof of concept tool. As findings written in blogs cannot be trusted with the same confidence as academic and peer-reviewed papers, these sources were only included based on the following requirements.

The blog had to be written by a recognised security specialist or be published by an established security institution or company. Next to this, the focus of the blog should be descriptive of the tests that they conducted and easily verifiable. The latter requirement can either be fulfilled by the availability of a proof of concept tool, or a proof that developers of a vulnerable application acknowledged the issue. Six blogs that seem to abide by these requirements and display the most significant insights and findings were selected, and we discuss them in chronological order.

SANS security blog In the SANS security laboratory: Methods of Attack Series by Northcutt (2007), one entry is about race conditions. He describes races as "(..) that small window of time between when a security control is applied and when the service is used". This is similar to the TOCTOU type of race condition as described before. However, the main focus of this blog is not on web apps but native low-level languages like C++. So, unless the developers of a web app have also written the server-side in C++, this approach is not directly comparable to our research.

Defuse security blog Another blog about practical race condition vulnerabilities in web apps by Defuse Security (2011) is much more similar to our research. The proof of concept target is a multi-process bank account web app written in PHP and run on an Apache server. It contains a typical TOCTOU bug as the database is first queried to check the balance of the user, and if allowed, it withdraws the desired amount. Many concurrent requests are shown to withdraw more money than originally available: an exploitable race condition. Instead of using transactions or SELECT FOR UPDATE Structured Query Language (SQL) methods to avoid these races, the author proposes to use System V-like semaphores or use locking files to synchronise the requests within the PHP language.

McAfee security blog We also look at a McAfee blog by Pandey (2016). Inter- estingly, he also notices that security tests often omit race conditions: "The general consensus is that race-condition attacks are unreliable and cannot be identified us- ing the black-box/grey-box approach.". At the same time, they conclude that modern tools have a real potential to identify race condition from the tester perspective. Sim- ilar to the banking test app, a web app is written in Java with Servlets (framework for Java web development) on Apache. Using the Intruder tool in Burp, they con- currently replayed the request to transfer money between accounts for 25 times and this resulted in the source account having a negative balance.

Independent hacker blog Another blog written by Franjkovi´c (2016) is dedicated to "(..) raise awareness about race condition attacks in both developers and se- curity people (..)". This bug hunter was able to find and report all kinds of bugs related to race conditions. He found a race in the voucher redeem functionality in Facebook, Mega and DigitalOcean that allowed for redeeming the vouchers multiple times. Another exciting part of the blog is the bugfix for a race condition in Keybase invites-system that created a new race condition bug. The first bug made it possible to send out more than the allowed single invite, but the fix allowed for using a single

invite multiple times. Both resulted in the same issue of allowing a user to invite more users than he is permitted to invite.

The blog contains a link to writeups of all issues, but no proof of concept tool is included to verify the results. Finally, the author encountered another fascinating and complex race condition bug in Facebook account registration, where he could confirm an email address that he did not own. After creating an account, but not yet verifying his email, he sent several parallel requests to change his email address to both the email under attack and his own. The requests would trigger the send- ing of a new email-address-verification email to his original address, but this would often contain the token to validate the email address under attack (instead of his own).

Lightning security hacker blog The next blog is written by Cable (2017), a hacker at Lightning Security. This is the only blog that contains a live example of a race condition. The example, written in NodeJS, simulates the transfer of money between banking accounts with a TOCTOU bug. It allows for transferring more money than available by quickly clicking the send button multiple times. Next to this, he discusses some real race condition hacks like a Bitcoin transfer site where he could act similar to the banking example and a HackerOne report on single-use vouchers that could be redeemed multiple times. The suggested solution is using locks in the database or back-end language. Regarding the detection of race conditions he concludes that "(..) you should look for race conditions whenever a one-time action occurs, whether sending money, redeeming coupons, or casting a vote."

Second independent hacker blog The last blog we would like to discuss is writ- ten by professional bug hunter Jadon (2018). It uses the examples from the McAfee blog and then shows how he used Burp to trigger a race condition as well, but now on a real web app. This web app provided free console (command-line interface) service, but this was limited to two consoles per user. By using 100+ intruder re- quests to add consoles while he also removed consoles manually, he was able to get three consoles. He concludes with the suggestion that a tester should make changes to a source while sending concurrent requests as "(..) there are higher chances you get it executed".

Conclusions Based on the published research regarding race conditions, we see that in the first and third work, static and dynamic white-box analysis of race condi- tions in external resource access of PHP scripts can yield valuable results. These

works are more similar to our purposes than the race condition tools for single-tier applications that were described in the introduction. In fact, we see no reasons why they could not become a part of the white-box aspect of system testing or secu- rity audits of source code in the future. However, our work is focused on black-box testing of web applications and any source code analysis is not possible. Both tech- niques, when used together, could improve the security test as a whole, but in and of itself, this work cannot use any of their methods.

Regarding the second work, as said before, the concrete ’hacking’ steps for black- box race condition testing will be used as a starting point for our systematic method- ology. Finally, regarding the fourth work, this is the most similar to our research. The differences lie in the fact that they created an automatic tool for testing for race conditions in collaborative web applications only, where we actually have created a systematic method that educates the tester himself to find all kinds of race conditions in web apps using our toolset. Next to this, their research only targets on functional race conditions where we primarily target intentionally adverse attacker behaviour that impacts the security of applications. That is why their toolset does not seem to be specifically tailored for triggering race conditions using high-speed parallel re- quests and might only be usable when the race window is rather high.

Based on the six security blogs, we can make the following conclusions. First, race conditions in web apps are not limited to a single language, framework, or server type but occur across the whole spectrum and can often be feasibly exploited. Next to this, most sources admit that the awareness of the widespread existence and consequences of these bugs is significantly below par. Furthermore, The primary bugs that are found in practice are vouchers, links or functionality that the tester can use more times than allowed. These bugs could cause direct financial damage, but do not interfere with the confidentiality, integrity, or availability of the web app. Sometimes a more sophisticated race bug is found that requires several steps, but could actually in a confidentiality or integrity infringement. The first type could be considered the low-hanging fruit regarding race conditions, and the more complex variant the hard-to-reach fruit. It is clear from these blogs that none of these types is tested for systematically either by developers or security testers. Not only that, but the sources also confirm that there is no systematic method available to them regarding the testing for race conditions.

Based on these sources, the thesis tries to improve on the current situation in two ways. Primarily, by creating the first effort towards a systematic security testing method for race condition vulnerabilities in web apps and also, by creating an elab- orate tool to support this.