Task 18, Day 12 Web timing attacks If I can’t steal their money, I’ll steal their joy!

Web Timing and Race Conditions

Type of vulnerability isn’t about sending bad data, it’s about how the data is sent. Simplest form, web timing attack means gleaning information from a web application by reviewing how long it takes to process our data. By making tiny changes in what is sent or how it’s sent and observing the response time, we can access information we’re not authorized to. Race conditions are a subset of web timing attacks where you can cause the web application to do unintended actions on our behalf. Time differences from 1300ms to 5ns have been used for attacks. They can be hard to detect, but HTTP/2 has made it a bit easier to find and exploit them.

HTTP/2

HTTP/2 supports feature called single-packet multi-requests. With single-packet single-request, couldn’t tell if delays were from processing or network latency. Stacking multiple requests in the same TCP packet with single-packet multi-request eliminates network latency from the equation. All that remains is server latency.

Typical Timing Attacks

Two main categories:

  • Information disclosures: Leveraging differences in response delays can uncover information a threat actor shouldn’t have. Timing differences can be used to enumerate usernames, making it easier to stage a password=guessing attack.
  • Race Conditions: Similar to business logic flaws in that they can cause unintended actions. The root cause is how the application processes requests. I.e. sending the same coupon request several times at once may allow applying it more than once.
    Rest of task focuses on race conditions and the Time-of-Check to Time-of-Use (TOCTOU) flaw.

The Practical

Need to be able to intercept traffic, so using Burp Suite and the Burp browser. Intercepting POST request for transfer and sending to repeater. From Repeater window, after clicking on the request, use CTRL+R to copy the tab 10 times. Click plus sign to create a tab group. Click down caret at Send botton and select Send group in parallel (last-byte sync), then send the request.

Fixing the Race

Since this flaw was caused by python code running the transaction and the balance check separately, there are a few recommended fixes.

  • Use Atomic Transactions: Atomic database transactions can be used to ensure all the steps of a fund transfer are performed as a single unit. This ensures that either all steps succeed or none do, preventing partial updates.
  • Implement Mutex Locks: The dev could have ensured only one thread accesses the shared resource (like account balance) at a time. This would prevent multiple requests from interferring with each other during the concurrent transations.
  • Apply Rate Limits: Should have implemented rate limiting on critical functions like transfers and withdrawals. This limits number of requests processed within a specific time frame, reducing risk of abuse through rapid, repeated requests.

The Task

Grab the flag from one of the transactions performed.

Race Conditions room.