Simon McCabe

OSCP · OSWP · PWPP · PWPA · PAPA · EnCE · Linux+ · LPIC-1 · Network+ · Security+ · Pentest+ · eJPT · eWPT · BSc · PGCert

CafeClub Writeup


CafeClub — Bugforge.io
CafeClub — Bugforge.io

Video tutorial and also writeup below video so you can choose which option to go with.

Video walkthrough

Step 1: Register

It may come as no surprise but you must first register on CafeClub before we can do anything special, like order coffee! and….do malicious things.

Step 2: Order an item

Before we do anything interesting, lets order an item and test the flow. Essentially we can order an item by adding it to the basket…

Step 3: Check out

From here, we can simply add our payment info (not real, obviously!)

and check out. Everything is as expected. 19.99 order earns us 19 points. Great.

Step 4: Repeat the same again

Go through the process again but this time capture the request as you’re about to hit “Place Order” and send it to repeater.

Step 5: It should look something like this

Your request (if you scroll down) should look as follows:

Step 6: Drop the request (in the proxy tab)

Drop the request you captured in your proxy tab now that it’s safely in repeater. You’ll see this screen, but you can safely ignore it:

Next, go and add an item to order and capture it as you add it to your basket. Send it to repeater and drop the packet too.

Step 7: Repeat in Repeater

In repeater, right click and “Send to repeater” so you’ve got multiple tabs.

Ensure each tab has a different product_id number:

Step 8: Add tabs to a group

Right-click and add your tabs to a group.

Give the group a name:

And add each tab to the group (the original request that was about to be checked out and the requests to add items to the basket). Select a colour and hit “Create”. You’ll end up with this:

Step 9: Send group

From the drop-down menu select “Send group in parallel”.

Step 10: Send group

Send the requests which will trigger a race condition which grants you the flag!

Notes:

A race condition in a checkout occurs when multiple requests are processed simultaneously, exploiting timing vulnerabilities in how the system validates and updates data.

How it works in this example:

1. The server checks your account balance/points and processes orders in separate steps

2. By sending multiple “add to cart” requests in parallel (at nearly the same instant) along with a checkout request, you can:
a) Make the system check your balance once but process multiple purchases before the balance is updated
b) Essentially “spending” the same points/money multiple times

3. If sent sequentially, each transaction would update your balance before the next one. But when sent simultaneously, they all see the same initial balance and can all pass validation.

As for real-world impact. This could allow attackers to:
a) Purchase items without sufficient funds
b) Earn points multiple times for a single payment
c) Bypass purchase limits or restrictions

The fix requires implementing atomic transactions or proper locking mechanisms to ensure balance checks and updates happen as a single, indivisible operation.

Thanks for reading!

LinkedIn X YouTube GitHub