> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/hack-smarter-labs/2026/race-conditions.md). # Race Conditions {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## Environment The diagram below gives a brief idea of how these three websites are interconnected. We have a banking website MWR Bank `http://mwrbank.loc`, a mobile wallet MWR MOMO `http://mwrmomo.loc` and a meme swag shop `http://mwrswag.loc`.

## Credentials Furthermore, the following credentials are provided to us. ``` { 'ben.taylor' : 'pw_Ben!02', 'cara.jones' : 'pw_Cara!03', 'daniel.k' : 'pw_Daniel!04', 'emma.smith' : 'pw_Emma!05', 'felix.ng' : 'pw_Felix!06', 'grace.lee' : 'pw_Grace!07', 'hugo.m' : 'pw_Hugo!08', 'ivy.chen' : 'pw_Ivy!09', 'jack.r' : 'pw_Jack!10', 'kira.patel' : 'pw_Kira!11' } ``` ## Race 1: Transaction Limits - MWR Bank The first challenge begins with the bank app. We need to authenticate with any given credentials and need to find the arbitrary limit being imposted. We are advised to play arround with the transaction function. We log in as `ben.taylor`.

We identify the following account numbers, which we will use to perform transactions between them. Our goal is to transfer arbitrary amounts from `acfcf96c-5c55-4f02-9c44-449991f49f6b` to `f66d041f-e264-41dd-9a60-8ccf59d88912` in order to determine whether any transaction limits exist. If such limits are present, we will assess whether they can be bypassed using a race condition that exploits a timing window in the limit-checking logic. ``` acfcf96c-5c55-4f02-9c44-449991f49f6b ``` ``` f66d041f-e264-41dd-9a60-8ccf59d88912 ``` First, we try to transfer an amount that exceeds our limit. We capture the request in Burp Suite and redirect the request to the repeater module. We see that our transaction is stopped with a message stating that we have an insufficient balance.

Okay, so let's try to execute several transactions at the same time that are below the limit but would exceed our balance in total. We add the tab to a group.

Next, we send the same request to the repeater by right clicking it and chosing that option. Furthermore we edit the amount to `5000` for each request. Next we chose the option to Send the request in the group in parallel (last-byte-sync). Last-byte sync is a technique where Burp Suite sends almost the entire request but holds back the very last byte of data; once all requests are ready, it releases those final bytes simultaneously to ensure they hit the server at the exact same moment.

We see that both transactions are made.

We reload the page in but do not spot the flag, but a negative balance on `f66d041f-e264-41dd-9a60-8ccf59d88912`, we exceeded the limit.

If we scroll through the HTTP history in Burp Suite we are able to spot the flag in the response of the request `/api/v1.0/account`.

## Race 2: Account Logon Limit In Race 2 we are tasked to bypass the logon limit and get access as `violet.c`. If we have had multiple bad log in request the account gets locked. We remeber the password structure from the given credentials list. The password structure consists of the prefix `pw_`, followed by the user's capitalized first name, an exclamation mark, and a two-digit sequential number. ``` { 'ben.taylor' : 'pw_Ben!02', 'cara.jones' : 'pw_Cara!03', 'daniel.k' : 'pw_Daniel!04', 'emma.smith' : 'pw_Emma!05', 'felix.ng' : 'pw_Felix!06', 'grace.lee' : 'pw_Grace!07', 'hugo.m' : 'pw_Hugo!08', 'ivy.chen' : 'pw_Ivy!09', 'jack.r' : 'pw_Jack!10', 'kira.patel' : 'pw_Kira!11' } ``` Furthermore we get a hint the account is anywhere between 12-40 on the list of accounts. That might be the two-digit sequential number, the id. > A little hint, this account is anywhere between 12 - 40 on the list of accounts. Remember, you probably only got one shot at this! So we end up with a password like the following but have only less than 5 tries. ``` pw_Violet!XX ``` We apply the knowledge gained from the first task and compile a list of request in a group with increasing sequential numbers in the password. Next, we use the `Send group in parallel (last-byte sync)` option to ensure the requests hit the server simultaneously, aiming to bypass the 'wrong password' increment check before the account lockout triggers. {% hint style="info" %} The numbering of the tabs is arbitrary and based on previous requests in Burp. I recommend trying at least up to sequential number 30 in the password. {% endhint %}

We check each request and end up with a valid session token.

Next, we add that token in the browser and refresh the page. We are logged in as `violet.c`.

As described in the task, we find the flag in the session token. We decode it and find the second flag.

## Race 3: Mo Money Mo Limits In Mo Money Mo Limits, we interact between the banking app and the wallet app. We have the option to transfer money from the banking app to the wallet app. We try to do the same as in the first task and attempt to transfer more money to the wallet than the limit allows. If we succeed, we have the opportunity to generate more money than we possess. We continue with the user account `ben.taylor`. We log in to the `ben.taylor` to the wallet and notice that the account numbers to the bank app are the same.

We make a MoMo transaction that does not exceed our limits, but that is high enough if it is executed twice to exceed the limit. We intercept the request using Burp Suite.

We group the request and generate a duplicate. Afterwards we use the `Send group in parallel (last-byte sync)` option gain to ensure the requests hit the server simultaneously. We get the flag in the response...

... and see that the wallet receives both transaction even though it exceeded the limits.

## Race 4: Shopping Cart Full of Wonder In Shopping Cart Full of Wonder we are tasked to identfiy the arbitrary limit by ourself. {% hint style="info" %} I had various ideas here, such as paying with other accounts and exploiting the race condition when checking account numbers and passwords. Furthermore I tried multiple checkouts or adding an infinte amount of items to the cart or creating multiple carts, but it was much more simpler. {% endhint %} We proceed with the account `kira.patel` in this case. Others are valid too. We note down the credentials and the wallet adress we need to buy items. ``` kira.patel:pw_Kira!11 ``` ``` 1d2b6a37-2400-4c18-bd75-6f57f10f38a4 ```

We log in as kira.patel on `http://mwrswag.log` fill up a cart that we can afford with that account and intercept the request and redirect it to the repeater. {% hint style="info" %} The idea is to checkout while adding more items to the cart. So the cart status goes to paid on the original amount, but we are getting more value by adding more items to the cart that still get shipped to us. {% endhint %}

Again we create a group tab. Request one is our checkout. Furthermore we add more items to the cart, but intercept those requests and add them to the tab group exceeding our balance....

...like shown below. We use the `Send group in parallel (last-byte sync)` option gain to ensure the requests hit the server simultaneously.

And we get the flag in the response...

## Race 5: Local Privilege Escalation Now that we have all the flags, we can use them to form the password and log in to the machine via SSH as `lpe`. Here we see that we can execute the script `/lpe/script.py` as `root` without a password using `sudo`. ``` ssh lpe@10.1.37.129 ```

We are not able to edit the script, but we are able to read it.

In short we can see that the script does the following * It reads `/lpe/tmp/script.py` * Computes its MD5 * Computes MD5 of `/lpe/script.py` (the orginial script) * It compares the hashes and continues if they match * If they match the script updates itself with the content of `/lpe/tmp/script.py` There is a delay that enabales a TOCTOU (Time-of-Check to Time-of-Use) vulnerability. * Long loop with `sleep(0.001)` × 100 * Expensive math calls {% code title="script.py" overflow="wrap" lineNumbers="true" expandable="true" %} ```python #!/usr/bin/python3 import os, sys import hashlib from pathlib import Path import time import math class UpdateRoutine: def __init__(self): self.name = "Update System Routing" self.folder = str(Path(__file__).resolve().parent) + "/tmp/" def md5sum(self, path: str | Path, chunk_size: int = 1024 * 1024) -> str: h = hashlib.md5() path = Path(path) with path.open("rb") as f: for chunk in iter(lambda: f.read(chunk_size), b""): h.update(chunk) return h.hexdigest() def update(self): #Step one of update is to get the file and the checksum new_script = self.folder + "script.py" checksum_file = str(Path(__file__).resolve().parent) + "/script.py" #Check that these files exist if not os.path.exists(new_script) or not os.path.exists(checksum_file): print ("Please provide the update script in the working directory + /tmp/script.py") sys.exit() #Now we want to calculate the hash of the script md5 = self.md5sum(Path(new_script)) md5_current = self.md5sum(Path(checksum_file)) if (md5 == md5_current): #We have the hashes, but now we first need to make sure that our install will work. Let's remove the current script for x in range (100): val = str(x + 1) while len(val) < 3: val = "0" + val math.log10(math.pow(12,x)) time.sleep(0.001) print ("Initialing checks: " + str(val) + "%") print ("Checks done, starting patch") copy_command = "cp " + new_script + " " + checksum_file os.system(copy_command) print ('Patch complete') sys.exit() else: print ("Hashes did not match, integrity compromised. Quitting") sys.exit() if __name__ == "__main__": runner = UpdateRoutine() runner.update() ``` {% endcode %} The idea is now to replace the script in `/lpe/tmp/script.py` with a malicious one after the check has passed. We create a script that crafts us a SUID bash binary to become `root`. {% code title="mal\_script.py" overflow="wrap" lineNumbers="true" expandable="true" %} ``` #!/usr/bin/python3 import os os.system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash") ``` {% endcode %}

We will implement a mechanism to rapidly toggle the file in `/lpe/tmp/` between the legitimate and malicious versions to win the race condition. This 'spray and pray' approach relies on the high frequency of swaps to ensure the valid script is present for the hash check and the exploit script is present when the copy command executes. ``` while true; do cp /lpe/script.py /lpe/tmp/script.py cp /tmp/mal_script.py /lpe/tmp/script.py done ```

We run the script... ``` sudo /lpe/script.py ```

... and see it got replaced with our malicious one.

Now we run our malicious script and get a SUID bash binary at `/tmp/bash`. ``` sudo /lpe/script.py ```

We run the bash binary and become `root`. We find the flag at `/root/root.txt`. ``` /tmp/bash -p ```

## Further Resources {% embed url="" %}