May 21, 2015 at 12:01How I Hacked Starbucks for Unlimited Coffee
This is the story of how I found a way to redeem an unlimited amount of money for Starbucks gift cards, thereby securing a free lifetime coffee, well, or stealing a couple of millions from them in other ways.
So, not so long ago, the idea came to me to buy 3 Starbucks cards for $ 5 each.
Starbucks.com has a personal account where you can add these cards, watch the balance and even transfer money between cards.
There is such a little-known class of vulnerabilities “race condition” . I can confidently say that most applications that may be vulnerable are most likely vulnerable to this attack, because not every programmer takes into account factors such as parallel execution of code and its consequences when designing programs.
In web applications, it also occurs, usually in functions related to the transfer of money / points / wrappers / vouchers. I’ll talk about all the intricacies of exploitation another time, but for now let’s get back to the transfer between cards in Starbucks.
The translation was built from several stateful requests. Schematically, the first request POST / step1? Amount = 1 & from = wallet1 & to = wallet2 laid all these values in a session on the server, and only the second POST / step2? Confirm translated the data already stored in the session and cleared it.
This greatly complicates the operation of the classic race, where you only need to repeat the same request several times at the same time. After all, as soon as the first request clears the session, the second one stumbles upon an empty session! And in order to somehow make it work, one would have to make a complex composition of requests, writing to the session immediately after it is cleared by the first request and before executing the second request. This could work out of a million attempts, or not at all.
But there is always a workaround for such "semi-protection" - you can log in to the same account from two different browsers / sessions. Then the operation looks something like this:
# we put the transfer parameters 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”
# simultaneous approval of the transfer of $ 1 from card 1 to card 2.
curl starbucks / step2? confirm -H “Cookie: session = session1 "& curl starbucks / step2? confirm -H" Cookie: session = session2 "&
After 5 attempts, nothing interesting happened and I wanted to give up. The peculiarity of the race condition is that you can only try to find it to a third-party attacker, because it is not known what protections are there (the number of IP requests? Account requests? Action requests?) And the only way to check whether you are vulnerable is to carefully audit the source code on the presence of proper pessimistic locks in the database.
A miracle happened on the 6th request - the transfer was made twice and I had two cards with 15 and 5 dollars, 20 in total. To consider this a proof of concept, it remains to make sure that the store will accept these cards.
I went to the nearest working Starbucks on market st.
- Give me something for $ 16.
- O_o.
- Well, what is the most expensive?
“There are those sandwiches.”
$ 16.70 came out.
So, $ 15 was invested in our little operation Y, and purchases were made at 16.70. Knowing the attitude of the most humane US court towards hackers, I returned home and immediately credited another $ 10 from a credit card to Starbucks’s card so as not to be indebted to the corporation for as much as $ 1.70.
The hardest part is the reporting process. Sapport honestly replied that he could not connect me with the technical team, well, nothing at all, and they are very sorry that I feel this way. I wrote to InformationSecurityServices@starbucks.com on March 23, silence (by the way, they answered already on April 29). Through familiar acquaintances, I had to find people who care and only after 10 days the vulnerability was fixed.
Nobody said thanks, but there was an ambiguous hint that I had committed fraud and malicious actions and that they would still think what to do with me.
What could I do? I could start a farm from fake gift cards bought in various stores around the world, generate a lot of money for them and sell them on special promo sites with a 50 percent discount (so as not to cause suspicion) for bitcoins. So, after working a year or two, you could suck a couple of million dollars from this friendly company with sweet coffee.
So, not so long ago, the idea came to me to buy 3 Starbucks cards for $ 5 each.
Starbucks.com has a personal account where you can add these cards, watch the balance and even transfer money between cards.
There is such a little-known class of vulnerabilities “race condition” . I can confidently say that most applications that may be vulnerable are most likely vulnerable to this attack, because not every programmer takes into account factors such as parallel execution of code and its consequences when designing programs.
In web applications, it also occurs, usually in functions related to the transfer of money / points / wrappers / vouchers. I’ll talk about all the intricacies of exploitation another time, but for now let’s get back to the transfer between cards in Starbucks.
The translation was built from several stateful requests. Schematically, the first request POST / step1? Amount = 1 & from = wallet1 & to = wallet2 laid all these values in a session on the server, and only the second POST / step2? Confirm translated the data already stored in the session and cleared it.
This greatly complicates the operation of the classic race, where you only need to repeat the same request several times at the same time. After all, as soon as the first request clears the session, the second one stumbles upon an empty session! And in order to somehow make it work, one would have to make a complex composition of requests, writing to the session immediately after it is cleared by the first request and before executing the second request. This could work out of a million attempts, or not at all.
But there is always a workaround for such "semi-protection" - you can log in to the same account from two different browsers / sessions. Then the operation looks something like this:
# we put the transfer parameters 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”
# simultaneous approval of the transfer of $ 1 from card 1 to card 2.
curl starbucks / step2? confirm -H “Cookie: session = session1 "& curl starbucks / step2? confirm -H" Cookie: session = session2 "&
After 5 attempts, nothing interesting happened and I wanted to give up. The peculiarity of the race condition is that you can only try to find it to a third-party attacker, because it is not known what protections are there (the number of IP requests? Account requests? Action requests?) And the only way to check whether you are vulnerable is to carefully audit the source code on the presence of proper pessimistic locks in the database.
A miracle happened on the 6th request - the transfer was made twice and I had two cards with 15 and 5 dollars, 20 in total. To consider this a proof of concept, it remains to make sure that the store will accept these cards.
I went to the nearest working Starbucks on market st.
- Give me something for $ 16.
- O_o.
- Well, what is the most expensive?
“There are those sandwiches.”
$ 16.70 came out.
So, $ 15 was invested in our little operation Y, and purchases were made at 16.70. Knowing the attitude of the most humane US court towards hackers, I returned home and immediately credited another $ 10 from a credit card to Starbucks’s card so as not to be indebted to the corporation for as much as $ 1.70.
The hardest part is the reporting process. Sapport honestly replied that he could not connect me with the technical team, well, nothing at all, and they are very sorry that I feel this way. I wrote to InformationSecurityServices@starbucks.com on March 23, silence (by the way, they answered already on April 29). Through familiar acquaintances, I had to find people who care and only after 10 days the vulnerability was fixed.
Nobody said thanks, but there was an ambiguous hint that I had committed fraud and malicious actions and that they would still think what to do with me.
What could I do? I could start a farm from fake gift cards bought in various stores around the world, generate a lot of money for them and sell them on special promo sites with a 50 percent discount (so as not to cause suspicion) for bitcoins. So, after working a year or two, you could suck a couple of million dollars from this friendly company with sweet coffee.