Hacking Starbucks for unlimited coffee
sakurity.com
sakurity.com
http://chadscira.com/post/556999d91cb00914380006ee/Re-Starbu...
I can only assume this is because gift cards are intended to behave like cash (when the balance is zero, they have no additional value), but operate under the mechanics of credit/debit cards (asynchronous transactions, network failures/delays, etc.). Debit cards have the feature of going negative with very clear legal liability assigned to the account holder. Gift cards holders are essentially anonymous, so recourse may be more difficult.
One of their first concerns should be is any facet of this affected by race conditions? It's not that complicated of a problem really..
You say in the end they "fixed" it (quotes included) and you yourself tested it and it did actually seem fixed... but it's not according to OP.
I do apologise if I've missed something blatantly obvious here!
Was your method the same as OP by the way?
Either way they should be paying more attention to this type of exploit, considering the history of the issue. I think they may have updated something and had a regression, the big question is how long has it been like this.
Believe it or not, there's a lot of software organizations out there that still get away with using anti-patterns like: not integrating code frequently, not using modern source control systems, not using automated tests, not doing security audits, and not doing incident reviews.
This was entirely RESPONSIBLE DISCLOSURE.
They need to send a basket of muffins to the guy.
Surely they should take INTENT into account.
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 ) ?
They seriously need to invest in security :/, im sure they have lost a good amount of money to this issue considering that its been around since 2012.
Perhaps they cannot fix it ?
Maybe their IT is in denial ?
Interested to see a follow-up report.
I think its more likely that they hid the fact that this happened/was happening and that resulted in this issue resurfacing.
I couldn't imagine a better boost to a security professionals career than getting sued over finding a very serious vulnerability and disclosing it in entirely good faith, only to get sued for the deed. It's outrageous enough to make headway online, you'd never actually face any repercussions, and your name would be everywhere due to the story.
http://www.starbucks.com/about-us/company-information/online...
That means that Homakov was likely not breaking the law, and you would expect starbacks to be more welcoming of the report.
Of course, I hope for Starbucks' sake that it quickly backtracks and thanks this guy with at a minimum a bunch of free Starbucks and a phone call or email from the CIO or CEO. It's not in Starbucks' interest to dissuade white hat hacking, since black hat hackers don't care about Starbucks' policies.
He says he has two cards: One has $15, one has $5.
Card 3203 is billed $14.68 and card 6075 is billed $2.02.
The remaining balance on card 3203 is $0, card 6075 has $5.70 remaining.
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...
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.
The misbehaving one was http://joby.com/ 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)
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))
Sellers used to be able to Ebay message non-winning bidders and offer them product at whatever they bid at. Sellers would also link buyers to their web-store for that item or related ones. Ebay blocks those kinds of messages. Now sellers do it with a paper pamphlet with your package.
Paypal, on the other hand, wants you to do more transactions, outside of Ebay or not, because they would likely still be the payment processor and get their cut.
It took a while for Ebay to integrate Paypal into the buying process (I'd argue they never really did), so they seemed to always operate semi-independently with non-aligned interests with their parent.
Pseudo-code:
UPDATE account WHERE ... SET balance = balance - 5
---
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?
BEGIN TRANSACTION;
SELECT balance AS balance1 FROM giftcards WHERE gift_card_id = 1;
SELECT balance AS balance2 FROM giftcards WHERE gift_card_id = 2;
UPDATE giftcards SET balance = balance1 - 5 WHERE gift_card_id = 1;
UPDATE giftcards SET balance = balance2 + 5 WHERE gift_card_id = 2;
END TRANSACTION;
Again, I'm not a developer, so what am I missing?
Note that the post says: > The only right way to do it is a pessimistic lock (FOR UPDATE clause).
This is not true. Banks deal with this problem all the time. You don't have to use a database engine as the serializer, despite what all the books tell you. My preference would be to explicitly serialize transactions rather than rely on database tricks - i.e. write accounting entries to ledgers and have a service that processes those entries on a single thread. For many scenarios this is more than good enough. If you needed lower latency, you could process this all in memory and use the database purely to replay the transaction log on restart for unprocessed transactions. In either implementation you could implement optimizations to process entries on different threads.
Look at what happens if you start two transfers of 1/2 the money from A to B.
Don't know what they're teaching the kids nowadays that they would let money be moved around without using transactions.
Repeatable read isn't super-expensive in modern databases with MVCC support - these should prevent the situation in the article if the SQL is as simple as you write.
There's a strong hint that it isn't, though; there appears to be a two-phase state machine involved, with two requests. No sane developer will write a transaction that starts in one request and commits in another.
So, you transfer and hope for the best, typically everything will be fine.
Then you add an asynchronous job to go over the logs and reconcile the results - flagging fraud.
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).
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.
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.
If you need the fame, use a pseudonym that consists of the same letters as your actual name and uncover the story once it cooled off or something...
For Starbucks, it's GOOD. It means they're out $2 and some embarrassment instead of out millions when someone sees something is way off in the books.
All that said, I would have tested this more than once to ensure it wasn't some minor built in allowance.
Why would you help a for-profit company for free? Would they do the same for you? What is the best-possible scenario, a reward / job offer / gift certificate? What is the worst-possible scenario? Years in prison? Legal cases which drain all your savings? It hardly seems worth it to do this. Software vulnerabilities are EVERYWHERE, but trying to be a Good Samaritan in a hostile capitalistic environment doesn't tend to work out in your favor very often.
Imagine going door to door checking your neighbors' houses to see if their doors are locked. Sure, you're "helping them out" by testing for a common vulnerability, but it's very difficult to distinguish between a good samaritan and a someone with malicious intents who had second thoughts or was concerned about being caught.
They could actually be lucky to just be out a million if this had been properly exploited.
The writer has admitted to a felony (several felonies, actually) in his post.
That may be a stupid law for events such as have been described, but it is the law in the United States.
He certainly didn't spoil his integrity. He had largely un-traceable riches in his hands, didn't exploit it, and gave it up. Nothing was "messed with".
print «Cookie: session=session1»
«Cookie: session=session1»It's more like Jimmy phones up the owner, and tells the maid that there is an issue with the door, after not liking the maids response he tells a group of people about the issue, and the next day the house gets robbed...
Even in your dry analogy, what's the problem? Would you not want people to tell you they found a very easy way to take money out of the register?
Not that it matters; this is text-book, industry standard security bug reporting. He waited with the public disclosure until it was fixed.
(If he didn't; different story. Maybe I misunderstood that part? Was that it?)
Sounds like it did get fixed, but it was a little confusing because he goes on to talk about how he could make millions counterfeiting gift cards.
He spent his own time helping Starbucks improve their security. Starbucks insinuates or suggests he committed fraud and malicious actions for finding AND trying to alert them of the problem so that it could be fixed. Starbucks was out of line here, not him.
While not eloquently expressed, it should still be obvious to most readers of this site that he is not implying that next time he will go and steal millions when he finds a bug. He is articulating that corporations that respond this way create a culture where they will only find out about vulnerabilities when it's too late, because no one will want anything to do with them.
If anything, the more serious bug is the attitude of Starbucks as an institution here, and people not holding Starbucks accountable.
If you must have an analogy, I think it's more like walking up to an unattended cash register during business hours and fiddling with it, figuring out how to take $0.10 out of it, and then putting the $0.10 back.
Not clearly harmless (or it wouldn't make so many people object), but the counting of the damages stops at a quite low number.
That last paragraph in particular sounds more like a vindictive troublemaker than a concerned hypothetical and writing like that doesn't help your case.
You don't piss off a hacker. And these people have miles more persistence than other people. That's what makes these people good. I'm not saying they should flagrantly abuse laws but the morality and mentality of these people is usually break first and then think about the consequences. And that's exactly why lots of holes never get reported.
It was written as the result of the pathetic replies that he got from them. So of course, it's going to sound _malicious_ because he's probably quite annoyed by their actions.
If you wanted to put a spin on things, you could claim that OP didn't actually contact Starbucks, and has just written this article to wind us all up ;-)