Debit Card Override Hack

Parrish allegedly visited Apple Stores and tried to buy products with four different debit cards, which were all closed by his respective financial institutions. When his debit card was inevitably declined by the Apple Store, he would protest and offer to call his bank—except, he wasn’t really calling his bank.

So, the complaint says, he would offer the Apple Store employees a fake authorization code with a certain number of digits, which is normally provided by credit card issuers to create a record of the credit or debit override.

Now that this trick is public, how long before stores stop accepting these authorization codes altogether? I’ll be that fixing the infrastructure will be expensive.

Tags: Apple, authorization, banking, credit cards, debit cards, hacking, scams

Posted on July 31, 2014 at 6:55 AM • 26 Comments

Comments

Tim Hall • July 31, 2014 7:28 AM

Pretty dumb of the store to rely on a phone call that the perpetrator has allegedly placed – they should have called the bank themselves.

Lincoln • July 31, 2014 7:31 AM

BBL, gtg shopping
l8r sk8r!

Tom • July 31, 2014 7:39 AM

What’s the point of there being a code if you don’t check it? It’s a login box where the password is optional.

Why even have an override? Declined is declined. If it should be approved, then the CC company should update their database and inform the sales clerk to attempt the transaction again.

Alan • July 31, 2014 7:39 AM

She is now charged with a felony. Yeah, real clever.

JimFive • July 31, 2014 8:06 AM

As I understand it the “loophole” is in place to allow transactions when the network is unavailable for some reason, so fixing the infrastructure isn’t in the cards. However, the store isn’t supposed to rely on a number given to them by the customer. The store has to call the processor themselves so that they know to whom they are talking.

Matt • July 31, 2014 8:28 AM

This is a social engineering trick. The authorization is not intended for use when a card is declined, it’s intended for use when the network is unavailable. The employee should NEVER allow the customer to call the bank himself, and should NEVER trust the number printed on the card. They’re supposed to call from a store phone, and they have special numbers to call. Not to mention, if the terminal says “declined” the card is declined. Basically, with proper training, this should never have happened.

Calum • July 31, 2014 8:31 AM

I think folk here are being a little bit blind to the reality of how salespeople are trained. When it comes to the card machine, the training consists of “stick the card in and enter the amount. Press confirm”.

That’s it. Yeah, people should do this and that but the fact is, they don’t and won’t, end of story.

uh, Mike • July 31, 2014 8:53 AM

Welcome to high credit card fees.

boog • July 31, 2014 10:04 AM

It was a clever trick too bad the guy wasn’t clever enough to know when to change his tactics. I mean, 42 times? All at Apple stores? Did he want to get caught?

parabarbarian • July 31, 2014 10:31 AM

Good trick but dumb criminal. Part of being a successful crook is to know when to walk away from an operation. Guess real world crooks don’t read the Stainless Steel Rat.

wiredog • July 31, 2014 11:18 AM

In general, criminals aren’t particularly bright people.

Brandioch Conner • July 31, 2014 11:50 AM

Not much of a “hack”. More like social engineering. It worked because he was able to convince the clerk that the code was legitimate.

The story also mentions his “attempted” frauds at a car rental company and a hotel. So the social engineering part does not always work.

wombat94 • July 31, 2014 11:55 AM

Totally a social engineering/retail associate training issue.

The loophole known here has been a part of the credit authorization system forever and to anyone who works in Retail IT concerning credit auth systems it is a known issue.

The manual auth code is deliberately not checked – because it can vary so much from bank to bank. If the systems are offline, then the voice authorization code is generated either at the processor or at the issuing bank.

In thinking about this, there are a couple of possible nuances to what this perpetrator was doing.

In most systems I have seen and have been involved in implementing, a hard decline will NOT allow a manual override with an auth code… declined is just that. An approval, obviously, is fine and the transaction will go through. But for many cards and banks, there is a middle ground response known as a “referral” or a “call center” response. This is implemented by the banks as a customer service option. Nobody – not the retailer, not the bank, not the customer – wants a potential sale to walk out the door if at all possible – then no one makes any money and the customer leaves frustrated.

The referral response allows both for the system offline use case to be handled when network connectivity is down, and for the exception handling of high-value customers. (for example, if I have a card with a daily spending limit, and the transaction is over that limit, I might need to provide answers to some questions about my account in order for the bank to approve the transaction)

What this story has me wondering is whether this thief knew that his invalid, canceled, expired cards would generate “call center” responses instead of hard “decline” responses.

If that’s the case, then you fall back to the associate to know the correct procedures for dealing with the call center – as others have said, you don’t directly call the customer’s bank – you call your own credit card processor’s phone number and they handle generating the authorization.

An interesting case, to be sure, but the only real thing of note in the story is the size of the fraud before he was caught and the fact that it was SO targeted to Apple. He probably identified a deficiency in the store operations (mobile devices out on the floor for checkout – no easily accessible phone for the associate to use to call a voice auth phone number… helpful customer uses his own phone to call “the bank”) and/or store training processes at Apple.

Anura • July 31, 2014 12:37 PM

Not very clever to use your own cards with your name on it. It might work better for stolen cards, although considering how easy credit card theft is there is probably an easy way to go about it.

David • July 31, 2014 1:08 PM

This is not just a social engineering matter; there’s a technical partial solution: If the authorization code is just for when the network is unavailable, only check the code when the network connection failed.

Of course there are still ways around this for the criminal – take out the network, &c, but they’re a bit more involved.

nonnee • July 31, 2014 1:38 PM

Any business that rely on this kind of security deserves to suffer some losses.

Annoyed • July 31, 2014 1:55 PM

Not to derail the topic but will you be discussing the latest TOR exploit?

https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack

It began in January and was only recently discovered and shutdown. Several nodes were added to the system that were doing packet modifications and were possibly able to identify users and hidden server operators.

This seems like a serious enough topic for a blog post, no?

Jeff • July 31, 2014 2:12 PM

@uh, Mike: the loss is Apple’s because they didn’t follow bank instructions. The bank is off the hook.

Wallace C Olson Jr • July 31, 2014 7:34 PM

@ parabarbarian
Stainless Steel Rat – boy, does that bring back pleasant memories

Beelzeboob • August 1, 2014 1:24 AM

Genius.

Karen • August 1, 2014 7:37 AM

Clerks these days can’t count change without a cash register telling them what to do. Agree that it’s dumb to take the customer’s word for whom he called, but what can you expect??

Simon Farnsworth • August 1, 2014 12:51 PM

I’ve worked retail and was trained in accepting cards. The underlying problem here is one of training; the cashier should never accept an authorization code that doesn’t come from your card processing company.

The correct workflow is for the cashier to call the company who provides your card processing services (at my place of work, we had their number on the card terminals). You talk to them about the decline, and they call the card issuer in a conference call. If your card processing firm agrees to authorize the transaction, they give you an arbitrary string that will match up to their systems later, so that in the event of fraud, they know that they authorised the transaction.

The technical fix is to change the way things work so that if the card processing firm’s network is up, you cannot enter an authorization string that doesn’t exist in their systems. When you phone the card processing firm, they add the code to the list of auth codes you can enter, and your terminal verifies this. That way, the window of opportunity for this fraud is reduced to times when the network is down.

Roman • August 3, 2014 4:45 AM

This is actually an old trick bartenders and waiters have use to force auth cards for deadbeats for years. It usually comes with a healthy tip added to the closed total…

Josh • August 3, 2014 8:37 AM

Having worked with a couple retailers I can say the reason he targeted Apple stores is manyfold. First, often times card processors have different override codes for different retailers, and even at times different locations of each vendor, depending on their processing agreement. Another issue is that the POS system seems deficient. If running the debit card as a credit transaction, it should have been a hard decline. If running as a debit transaction, it likely will always be a soft decline thanks to daily limits. The third, of course, is cashier training. The Apple store employees are well known for being very customer-service oriented. This likely means they don’t often have to deal with edge cases like this, so their training on declines like this is minimal. As others have said, there likely wasn’t a good way for the cashier to call, and he or she was thankful for the customer calling. That said, if it happened when I was in retail, I would likely have been fired as soon as it came out. I got proper training and would never have accepted the customer calling the bank.

Gabe • August 3, 2014 11:24 PM

What a clever scam. This guy totally doesn’t look like a criminal. I would help him load up his ’89 Cutlass with $7,700 worth of iPads any day.

Wouldn’t you?

SchneieronSecurityFan • August 7, 2014 2:27 AM

@ wombat94 – “(mobile devices out on the floor for checkout – no easily accessible phone for the associate to use to call a voice auth phone number… helpful customer uses his own phone to call “the bank”)”

That’s a key point. There are many Apple stores without any cash registers. The Apple Store employee will have his hands full with this customer. I think the card scanners are converted iPhones and iPads that probably make it difficult to make calls from.

Debit Card Override Hack

Comments

Leave a comment Cancel reply