How I hacked Starbucks for unlimited coffee
This is a story about how I found a way to accumulate an unlimited amount of money on Starbucks gift cards, thereby securing life-long free coffee, or stealing a couple of million from them in other ways.
So, not so long ago, I had the idea 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 the cards.
')
There is such a little-known class of “race condition” vulnerabilities. I can confidently say that most applications that may be vulnerable are likely to be vulnerable to this attack, because not every programmer takes into account such factors as parallelism of code execution and its consequences when designing programs.
In web applications, it is also found, usually in the functions associated with the transfer of money / points / candy wrappers / vouchers. I will tell you about all the intricacies of operation another time, but for now let's return to the transfer between the cards in Starbucks.
Translation was built from several stateful requests. Schematically - the first POST / step1 request? Amount = 1 & from = wallet1 & to = wallet2 laid all these values ​​into the session on the server, and only the second POST / step2? Confirm translated the data already stored in the session and cleared it.
This significantly complicates the operation with respect to the classic race, where you only need to repeat the same query several times at the same time. After all, as soon as the first request clears the session, the second already comes across an empty session! And in order to somehow make it work, we would have to make a complex composition of requests that would write to the session immediately after it was cleared by the first request and before the execution of the second request. This could work out of a million attempts, or not at all.
But there is always a detour for such “semi protection” - you can log in to the same account from two different browsers / sessions. Then the operation looks like this:
# laying the parameters of the translation 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 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 an outside attacker, because you don’t know what defenses are (number of requests for IP requests for an account requests for action) and the only way to check whether you’re vulnerable is to carefully examine the source code on presence of proper pessimistic locks in the database.
On the 6th request a miracle happened - the transfer was made twice and I had two cards with 15 and 5 dollars, 20 in total. To consider this as a proof of concept, it remains to make sure that the store accepts these cards.
I went to the nearest running Starbucks on the market st.
- Give me something for $ 16.
- O_o.
- Well, what is your most expensive?
“Those sandwiches out there.”
Out $ 16.70.
So, $ 15 was invested in our small operation Y, and purchases were made at 16.70. Knowing the attitude of the most humane court of the United States to hackers, I returned home, immediately credited another $ 10 from a credit card to a Starbucks card, in order not to owe the corporation as much as $ 1.70, you never know.
Then the most difficult is the reporting process. Sapport honestly answered that he could not connect me with the technical team, well, not at all, and they are very sorry that I feel this way. I posted on InformationSecurityServices@starbucks.com on March 23, silence (by the way, they answered as early as April 29). It was necessary, through acquaintances of acquaintances, to find people who care and only after 10 days the vulnerability was fixed.
Nobody said thank you, but it was not an ambiguous hint that I committed “fraud” and “malicious actions” and what else they would think about what to do with me.
And what could I do? I could run a farm from fake gift cards purchased in different stores of the world, accumulate a lot of money on them and sell on special promotional sites with a 50 percent discount (so as not to arouse 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, I had the idea 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 the cards.
')
There is such a little-known class of “race condition” vulnerabilities. I can confidently say that most applications that may be vulnerable are likely to be vulnerable to this attack, because not every programmer takes into account such factors as parallelism of code execution and its consequences when designing programs.
In web applications, it is also found, usually in the functions associated with the transfer of money / points / candy wrappers / vouchers. I will tell you about all the intricacies of operation another time, but for now let's return to the transfer between the cards in Starbucks.
Translation was built from several stateful requests. Schematically - the first POST / step1 request? Amount = 1 & from = wallet1 & to = wallet2 laid all these values ​​into the session on the server, and only the second POST / step2? Confirm translated the data already stored in the session and cleared it.
This significantly complicates the operation with respect to the classic race, where you only need to repeat the same query several times at the same time. After all, as soon as the first request clears the session, the second already comes across an empty session! And in order to somehow make it work, we would have to make a complex composition of requests that would write to the session immediately after it was cleared by the first request and before the execution of the second request. This could work out of a million attempts, or not at all.
But there is always a detour for such “semi protection” - you can log in to the same account from two different browsers / sessions. Then the operation looks like this:
# laying the parameters of the translation 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 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 an outside attacker, because you don’t know what defenses are (number of requests for IP requests for an account requests for action) and the only way to check whether you’re vulnerable is to carefully examine the source code on presence of proper pessimistic locks in the database.
On the 6th request a miracle happened - the transfer was made twice and I had two cards with 15 and 5 dollars, 20 in total. To consider this as a proof of concept, it remains to make sure that the store accepts these cards.
I went to the nearest running Starbucks on the market st.
- Give me something for $ 16.
- O_o.
- Well, what is your most expensive?
“Those sandwiches out there.”
Out $ 16.70.
So, $ 15 was invested in our small operation Y, and purchases were made at 16.70. Knowing the attitude of the most humane court of the United States to hackers, I returned home, immediately credited another $ 10 from a credit card to a Starbucks card, in order not to owe the corporation as much as $ 1.70, you never know.
Then the most difficult is the reporting process. Sapport honestly answered that he could not connect me with the technical team, well, not at all, and they are very sorry that I feel this way. I posted on InformationSecurityServices@starbucks.com on March 23, silence (by the way, they answered as early as April 29). It was necessary, through acquaintances of acquaintances, to find people who care and only after 10 days the vulnerability was fixed.
Nobody said thank you, but it was not an ambiguous hint that I committed “fraud” and “malicious actions” and what else they would think about what to do with me.
And what could I do? I could run a farm from fake gift cards purchased in different stores of the world, accumulate a lot of money on them and sell on special promotional sites with a 50 percent discount (so as not to arouse 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.
Source: https://habr.com/ru/post/258449/
All Articles