I encountered and reported this bug over <i>three</i> years ago. I decided not to write about it but considering that they still haven't fixed it...<p><a href="http://chadscira.com/post/556999d91cb00914380006ee/Re-Starbucks-unlimited-coffee#" rel="nofollow">http://chadscira.com/post/556999d91cb00914380006ee/Re-Starbu...</a>
This is like punching a guy who hands you the wallet you just dropped.<p>This was entirely RESPONSIBLE DISCLOSURE.<p>They need to send a basket of muffins to the guy.<p>Surely they should take INTENT into account.<p>The interesting question is : How much has Starbucks lost because of this vulnerability ( the white hat may not have been the 1st to discover it ) ?
To add some context, starbucks do appear to invite whitehat security testing in a bug-bounty like manner:<p><a href="http://www.starbucks.com/about-us/company-information/online-policies/information-security-at-starbucks" rel="nofollow">http://www.starbucks.com/about-us/company-information/online...</a><p>That means that Homakov was likely not breaking the law, and you would expect starbacks to be more welcoming of the report.
I have never used a gift card at starbucks before, but that bill [0] doesn't make any sense to me.<p>He says he has two cards: One has $15, one has $5.<p>Card 3203 is billed $14.68 and card 6075 is billed $2.02.<p>The remaining balance on card 3203 is $0, card 6075 has $5.70 remaining.<p>If card 3203 had $15 and card 6075 had $5 before he used them, the remaining balance should have been $0.32 and $2.98, respectively...<p>That's really me guessing, but it could be the $5 was just an example to explain the concept and in fact he used smaller values (e.g. $0.05) to be able to trigger the bug more often without generating too much cash... but he should have explained the bill somehow.<p>[0] <a href="http://sakurity.com/img/sbcheck.jpg" rel="nofollow">http://sakurity.com/img/sbcheck.jpg</a>
I told 2 companies that they are leaking email addresses (got spam on single-purpose addresses).
One replied very kindly and asked for details, the other did not answer, after writing them publicly on twitter they blocked me there...<p>The misbehaving one was <a href="http://joby.com/" rel="nofollow">http://joby.com/</a> they build these awesome gorilla-pods. Do yourself a favor and buy one of the many clones. (got spam to joby.com.singlepurpose@mydomain.com)<p>More or less shady paypal-shops are the worst though :) (paypal hands your mail-adress out (I wonder why they do not relay communications like ebay))
Isn't it true that using an UPDATE statement referencing the existing column's value also works?<p>Pseudo-code:<p><pre><code> UPDATE account WHERE ... SET balance = balance - 5
</code></pre>
If both sides of the transfer are handled this way, and then the balance of the transferrer is checked after to ensure it's greater than 0 (rollback otherwise), won't that suffice to handle the issue without having to use SELECT ... FOR UPDATE?<p>---<p>To further simplify this, you could include a WHERE balance > [transfer amount] clause to the transferrer UPDATE query. If the number of rows updated is 1, UPDATE the transferee's row. If the number of rows updated is 0, you're done (tell the user they don't have sufficient funds). Isn't that right?
I guess the reason why they responded in such a way is to prevent any potential future "tinkerers" to get away by saying that they were just white-hats. I guess it would have been better to inform them before testing their payment system for errors.
Nice but I wouldn't attempt to purchase something at a startbucks in the US where you will go to prison for a long time even if there was no malicious intent.
Transferring balances between accounts is hard. If you have any sort of sharding, all of a sudden you don't get transaction safety in the transfer. You can have sharding for many reasons, such as different vendors, different locations, different releases and pure performance.<p>So, you transfer and hope for the best, typically everything will be fine.<p>Then you add an asynchronous job to go over the logs and reconcile the results - flagging fraud.<p>There are two ways of processing transactions. You can remove the money first and then add it to the new account. That will tend to show up as "lost" money when the customer sees a problem. Not really a good thing if you're a service business (vs a bank).<p>The other way to go is add the money first and then remove it. That will allow money to be created (as in this case), but won't result in customers seeing money disappear.<p>Finally, there may be a problem where they are reading from a cache to perform the transfer, and the read-copy is a little stale. Again, this would tend towards giving customer's money.
Simple rule: if you don't have the permission of the company to mess with their system, don't do it. Why would you anyway? You don't get paid and you spoil your integrity.
Off topic: what's up with the guillemets in the code example? Does that actually work as a replacement for single/double quotemarks in some shells? Mine just treats them as an ordinary character, e.g.<p><pre><code> print «Cookie: session=session1»
«Cookie: session=session1»</code></pre>
Unlimited starbucks coffee can also be had by visiting any large wildfire and scooping the ashes into a container full of water. It essentially the same thing.
I don't see how this is different from finding an ingenious way to jimmy open the lock of the door at night, figuring out how to take cash from the register, and then phoning them up to tell them they need to spend money on a new door.
To be fair to the relevant authorities, the author does a terrible job of not sounding malicious.<p>That last paragraph in particular sounds more like a vindictive troublemaker than a concerned hypothetical and writing like that doesn't help your case.