On May 21st, 2015, a researcher from the Sakuruty group published a bug about a race condition in Starbucks' payment module.

To understand this vulnerability, let me explain what a race condition is. In the computer science, there are shared resources, for example, the memory, data, and environmental variables. So, what happens if process A wants to access the same resource as process B? Well, the first process that accesses it will use it, but not necessarily this resource will be blocked—it could be used at the same time by the other process with unexpected results.

Researchers from Sakurity bought three Starbucks' cards, and registered them in the web application. This application had the feature of being able to transfer money between cards. The researcher analysed the request to transfer money, and found that the process was as follows:

• Take the values origin, destiny, and the session: After the money was moved, the application cleared the session. This process was made by two POST requests.
• The application controls the session: Clearing the session was the only mechanism to avoid multiple transfers. The researchers found a method to prevent the application from clearing the session, so that in this moment, the value could be used more than once, to get extra money. To do that, they created the following exploit:

# prepare transfer details in both sessions
curl starbucks/step1 -H «Cookie: session=session1» --data «amount=1&from=wallet1&to=wallet2»
curl starbucks/step1 -H «Cookie: session=session2» --data «amount=1&from=wallet1&to=wallet2»
# send $1 simultaneously from wallet1 to wallet2 using both sessions
curl starbucks/step2?confirm -H «Cookie: session=session1» & curl starbucks/step2?confirm -H «Cookie: session=session2» &
  

Why does it work? Well, the developers always expected that the transference was made by the web browser. Why? Because everybody needs to use a browser to access an application. Wrong! If you know the correct request, you can make it using the command line, like the researchers, with CURL, a command-line tool in *NIX systems, or you can even use an HTTP proxy. This scenario, where a user avoided the use of the browser and made the request directly to the application, was never considered by developers, allowing the bug bounty hunters to get free credit on the cards.

How can we find vulnerabilities such as this? Use the Repeater tool to modify the application's requests and analyze the responses with little variations. To do that in Burp Suite, you can stop a normal request by using the Intercept is on button in the Proxy tool:

Then, use the secondary button to show the menu, and send the request to Burp's Repeater tool:

The next time you want to send the same request to see the response to certain modifications in the request, you do not need to follow all of the application's flows. You just need to resend the request directly in the Repeater tool. For this vulnerability, the developers used CURL to make the proof of concept.

CURL is a command-line tool that's used to make requests from the console to an application. Sometimes, it is normal to use CURL to automate requests in a script. To learn more about CURL, type the following from the command line in any UNIX-like system:

    $ man curl