The method i used had to do with a race condition related to transferring between cards, just like the OP.
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.
wow considering how long this has gone on, there must have been a handful of people who made a lot of money doing this. A starbucks giftcard is almost like a currency . I wonder if walmart cards have a similar vulnerability
In my experience, Starbucks is one of the few places which allows transfer of gift card balances or purchases of gift cards with other gift cards.
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.
Apparently one of the common scams in Eastern Europe is to drop a wallet by a tourist. When the tourist picks up the wallet and hands it back, the scammer starts loudly yelling that the tourist stole their wallet, threatening to call the police if the tourist doesn't give them some cash. So I guess sometimes it does pay to punch they guy handing you your own wallet.
Not just in eastern Europe, there was a variation of this scam in Amsterdam(at least 10 years ago), where an alleged drug dealer would hold some white powder in his hands and bump into you on purpose, so that it makes him drop the powder, then the guy would say that you wasted his drugs and you should pay him money as reparation.
I ran into this scam in New York City last year, I was walking down 8th Avenue, up at 115st, a guy bumped into me and dropped a bag on the ground, the bag started to leak, he said he had just bought some expensive whiskey, now it was wasted, I should pay him so he could replace the whiskey, etc, etc. An obvious scam.
When i initially reported it, it felt like they quickly had me speaking directly with the person that was possibly at fault in order to fix the problem. But at the same time it did feel like they were internally sweeping it under the rug.
I think its more likely that they hid the fact that this happened/was happening and that resulted in this issue resurfacing.
I wonder if there would be anything you could say at that point to get them to follow through (without implying any intent to exploit obviously).
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.
Yeah, responding to a limited (experimental) exploitation of a vulnerability in a hostile way will usually make people think twice, and selling the vulnerability to 3rd parts will seem more interesting.
The thing about big companies is that the person responding to the inbound communcation is usually in a totally separate department from the person who wrote the policy, and often doesn't know the policy exists. It's really hard to get a group of 50,000 people to act consistently with each other.
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.
I have never used a gift card at starbucks before, but that bill [0] doesn't make any sense to me.
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.
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...
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))
I think Ebay stopped because buyers would get in touch directly with a seller to do re-orders (sometimes at a discount).
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.
Isn't it true that using an UPDATE statement referencing the existing column's value also works?
Pseudo-code:
UPDATE account WHERE ... SET balance = balance - 5
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?
---
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?
The issue (as I understand it) was transferring balance from one card to another. So two rows need updating, one with an increment, the other with a decrement.
I'm not a developer (I generally only write shell/Perl/Python scripts to make my own job easier) or a database expert but wouldn't this issue be pretty easy to avoid if the whole process were wrapped up in a transaction? E.g.:
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;
Obviously, this is somewhat simplified and you'd have various checks to make sure balance1 was actually >= 5, etc.
Transactions do not necessarily get processed serially. For example, if there were two concurrent requests and request #1 had just completed the first UPDATE when request #2 jumps in and performs the first two SELECTs, then request #2 will incorrectly update the balance for card #2. Different database systems offer different ways to serialize transactions, usually with a cost of performance and complexity.
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.
If you make 2 updates, check the balance to ensure > 0, and rollback if < 0, and you do all of this in a transaction, doesn't concurrency no longer matter? If another transaction beats you to the punch, won't the balance check query reflect that?
The semantics of the SQL you wrote depends on the transaction isolation level and flavour of transaction implementation. Read committed vs repeatable read (common terms for specific semantics) makes a difference as to what selects can see with respect to concurrent transactions. The way the SQL is written can also affect how reads and writes interleave.
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.
You're not missing anything. This is what transactions are for. If you need to make multiple changes to a database and you need all of them or none of them to happen, you need a transaction.
Don't know what they're teaching the kids nowadays that they would let money be moved around without using transactions.
You know what they say about assumptions, of course not, they use message queues for transactions and have a great queuing system built on acid databases
Exactly; each of these operations require only 1 query (you don't need to SELECT and then UPDATE), and then a third SELECT query afterwards to ensure the transferrer's balance wasn't reduced to below 0, in which case the save point is rolled back.
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.
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.
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.
While you're absolutely right, unless there's something in it for you beyond curiosity / because you can, the risks much outweigh the benefits IMO.
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.
If you want to look at it rationally, he has pretty good chances of getting a good job in security now. It's likely he's looking at proposals by Google, Facebook, etc. Good recruiters love these kinds of things (and should, as they are a great measure of who is a passionate hacker).
As reluctant as I am to agree with this on principle.. yeah, the logic checks out. It's not like helping an elderly person across the street, you're dealing with an (a|im)moral entity who can and will nail you to the wall with on a whim if they think it'll improve their balance sheet.
I think the generally accepted practice is to go bug hunting when the organization has requested it (e.g. bug bounty programs), or report a bug if you stumble upon it without really searching.
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.
Many people find security bugs because they think it is fun and exciting and get intrinsic pleasure from finding one. Same reason why lockpicking is a hobby. Of course these people should stick to the companies who ask you to find their bugs.
I don't actually see how Starbucks could have been out millions. They'd just notice a gift card had a large balance, investigate, and zero it out. Unless the guy had managed to drink/hawk one million coffees in a few weeks.
Because someone could have exploited this en masse, sold these cards, etc. Even if that didn't go far they'd have to rewrite their software/service, hire some people, refund money to people because they had to cancel their gift cards, etc. Plus damage to the brand and future profits.
They could actually be lucky to just be out a million if this had been properly exploited.
Are you a corporate lawyer for sides that normally lose and just throw muck and nonsense, or did you have trouble reading?
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".
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.
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.
How did he have little credibility? And how did he lose it?
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.
No, it's like seeing a door ajar, then calling the company to tell them that they forgot to close and lock their door. It takes a pretty dumb company to get mad about that.
Yes but this issue doesn't save customers from losing money or data so there isn't really a moral reason to disclose this. It directly impacts Starbucks, and their balance sheet.
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...
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.
To be fair to the relevant authorities, the author does a terrible job of not sounding malicious.
That last paragraph in particular sounds more like a vindictive troublemaker than a concerned hypothetical and writing like that doesn't help your case.
To be a good security researcher, no doubt it often takes a devious mind. Now whether or not this deviousness is used for good or evil depends on temperament, upbringing and acceptance or ignorance by other parties.
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.
This blog post was written for _us_. Not for Starbucks.
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 ;-)
http://chadscira.com/post/556999d91cb00914380006ee/Re-Starbu...