Cloning Retail Gift Cards

Clever attack.

After researching how gift cards work, Zepeda purchased a magnetic card reader online, began stealing blank gift cards, on display for purchase, from Fred Meyer and scanning them with his reader. He would then return some of the scanned cards to the store and wait for a computer program to alert him when the cards were activated and loaded with money.

Using a magnetic card writer, Zepeda then rewrote one of the leftover stolen gift card's magnetic strip with the activated card's information, thus creating a cloned card.

Tags: , , , , ,

Posted on August 13, 2010 at 7:36 AM • 37 Comments

Comments

Pete • August 13, 2010 8:06 AM

I recall seeing something similar a few years ago - I believe that the guy determined that the online use required only the card ID, which was printed on the card. He wrote down the card IDs from the ones on the rack, and them just tested the balances until the cards were bought and had value, then spent it online.

Anon • August 13, 2010 8:07 AM

This is clever indeed. Somehow, however, it isn't really new technology. I'm surprised that this sort of attack is just now beginning to rear its head. At any rate, it's interesting, especially when one considers all the possible attack types/security flaws that could be derived from this method...

anon y. mous • August 13, 2010 8:11 AM

"He would then...wait for a computer program to alert him when the cards were activated..."

What? They gloss over this like it's the simplest part of the scam but it's the hardest. Cloning mag stripe cards is easy. Knowing which ones have been activated...without simply guessing randomly...how did he do that?

Grant Gould • August 13, 2010 8:14 AM

anon.y.mous -- many of these store cards let you check the balance online. That would solve the problem nicely.

karrde • August 13, 2010 8:18 AM

Strange...

after one store notified the Police, and they investigated, they discovered that he'd hit more than a dozen stores.

And most of the others didn't want to cooperate with the investigation.

That's pretty disturbing, and makes me wonder how many other con-men have pulled this off on a store that didn't want to admit it to local Law Enforcement.

bart • August 13, 2010 8:25 AM

There is an easy fix to this, use the scratch-off type of cards with a bar code under the foil.

The whole scam is pretty easy (even though it includes stealing something) but the designer of the system could have thought an extra step.

parkrrrr • August 13, 2010 8:47 AM

The quote I found most interesting from the article: "The culprit was a computer program that Zepeda downloaded to electronically check the card's balance many times a day."

The interesting word there is "downloaded." He didn't write this thing, which means that there are almost certainly other people out there doing the same thing.

I wonder if they'd have taken longer to catch him if the program were a little smarter about frequency. It's not as if he needed to know within minutes that a given gift card had been activated; the time between activation and first use is likely to be at least a day or two on average. He could probably have checked each card once a week and still gotten a lot of them.

Rich • August 13, 2010 8:53 AM

@Bart:
Agreed. Simple solution and it works. I work for a major Canadian electronics retailer (YAY DISCOUNT) part time, and this is what we do. You can't do anything online without scratching that crap off to get the "secret number".

That being said, I don't need to type it into the till when you use it in store. HHMMM.

Mike Curran • August 13, 2010 9:09 AM

This attack has been around for years. Copy the numbers and wait for the card to be activated. The standard defense has been to make the mag strip and numbers difficult to access without damaging the packaging, but it seems that some folks haven't gotten the memo.

MailDeadDrop • August 13, 2010 10:01 AM

Mark Curran is right: the best method presently is to make access to the card's magstripe difficult without damaging the packaging.
Once that barrier is overcome, it seems the next secure method would be for the gift card's magstripes to be *blank* while on the rack, and *written* at the time of sale. This will obviously require that the POS terminals have card writers attached, so it isn't a *cheap* solution.

RockDoggy • August 13, 2010 10:15 AM

Since I am a POS developer at a large retailer, I'm getting a kick out of these replies...

But seriously, we've handled this in two different ways. First, a program that checks the activation status of stored value accounts would fail for us because we automatically invalidate any account that receives two balance inquiries before activation. Second, we require the last 4 digits of the card number to be entered at activation and redemption. If either entry fails to match the MSR data of the card presented, it's invalidated.

Simple but effective for us. Granted, there may be ways to get around this, but it makes us a sufficiently difficult/expensive target to hack that it's not a problem.

In other words, we don't have to outrun the bear, we just have to outrun the other retailers that are also running from the same bear.

Bryan Feir • August 13, 2010 10:29 AM

@karrde:
Well, yes, the history of companies treating security issues as primarily Public Relations problems rather than potential Security problems has been discussed in this blog often enough...

mpg • August 13, 2010 10:42 AM

But for the cards with scratch-off numbers, how do we know they're not in the mag-stripe data? I'd assume they are.

parkrrrr • August 13, 2010 10:54 AM

@anarchy-x: The software in the quote is the software that automatically checks the activation status of multiple gift cards from multiple retailers, not software to read/write magstripes.

That software is also not hard to write, but specialized enough that it's only useful for this sort of attack. The fact that that software can just be downloaded from somewhere (the article explicitly says that he downloaded it, not that he wrote it) means that the attack is probably a lot more common than anyone is letting on.

parkrrrr • August 13, 2010 10:56 AM

@RockDoggy: "we automatically invalidate any account that receives two balance inquiries before activation"

Doesn't that just change the attack to a really annoying DOS on your customers and cashiers?

kangaroo • August 13, 2010 11:20 AM

parkrr: But what is the interest in the DOS? Once the crooks find that it's merely a DOS without any apparent mechanism to be monetized -- why would they do it?

So the "just" in your comment is invalid, given the real parameters of the problem. Reducing the problem to a DOS is a real-world solution --- at least until someone finds a way to profit from the DOS.

Remember, that this requires physical stealing and replacement. You can't just do it with a distributed network for kicks with a script you downloaded -- you have to actually get your ass to the store and steal them one by one, go home and read the cards, and then go back to the store and replace them. Network DOS is different because of this --- even with no pecuniary advantage, the costs are so low that it's a reasonable "hobby".

R Cox • August 13, 2010 11:36 AM

As others have mentioned this is an old problems that some firms have fixed. That not everyone has not minimized this problem, for example by restricting acess the card data online, indicates it is not a problem for the vendor. For example, Amex gift card purchases cannot be disputes, so if someone clones a card, the consumer is simply out of luck. It is interesting that these cards are advertised as more secure cash equivalents. If someone steals your cash, you know it. If someone clones a card you are about to buy, you don't. It seems that we as consumers can protect ourselves only by demanding gift cards from sealed unopened cases.

parkrrrr • August 13, 2010 12:02 PM

@kangaroo: We don't actually know whether it requires physical stealing and replacement in the case of this unnamed system. It might be possible to just enter random digit strings of appropriate length into the verification system, three times each just to be sure, to reduce the DOS to an attack you can do from the comfort of your own botnet.

parkrrrr • August 13, 2010 12:08 PM

Also, even if the network attack isn't feasible, given that we don't know which retailers' gift cards get invalidated in this way, eventually someone trying to perform the profitable attack will instead perform the DOS. By the time they find out it's not profitable, they've already invalidated at least a handful of the cards on the rack at their local store, and those cards will likely be grouped together on the rack, making the resulting scene even more hilarious.

RockDoggy • August 13, 2010 12:27 PM

@parkrrrr see @kangaroo's answer. Once the scammers realize their scheme yields nothing from our cards, they move on. Or adapt, but so far we haven't seen that.

I'd argue that the type of people looking to run this scam aren't interested in DOSing anyone. They want profit, not revenge or script-kiddie level thrills.

bob (the original bob) • August 13, 2010 1:04 PM

I wrote ATM software for banks in the '80s. One of the tools one of my customers requested was a 'velocity file' whereby it would keep track of how many times a single ATM card was used in a given machine (this was back in the days when many ATMs were 'offline only' or 'online with fallback to offline mode').

I don't know whether they were simply planning ahead or whether they actually had people cloning ATM cards 20 years ago, but it was a neat idea, otherwise an offline ATM would read the 'daily accessible' amount off the card (which could be as high as 9999 and if you can clone cards you can set the amount as well) and take the card's word for it; so if you had the patience and looked innocent enough you could stand in front of an ATM for 2 hours while it went 'kachunkkachunkkachunk' and you could conceivably steal several thousand dollars. (presumably you would clone someone else's card, not your own)

wombat94 • August 13, 2010 2:37 PM

I'm also a POS software developer by trade and ran into this exact attack about 8 or 9 years ago (if I remember correctly).

The solution that we came up with was the simple "last 4 digit" verification when redeeming the card in our stores... since the attack required rewriting the mag stripe of a card, the last 4 digits printed or embossed on the card did not match the last 4 digits of the account number in the magstripe.

On the balance inquiry side, we eventually required the online PIN (which was required to use the card to purchase on our ecommerce website) in order to do an online balance inquiry. That PIN was also printed on the card, but was hidden under a scratch off segment - it was a long (12 character if I remember) alphanumeric so it wasn't something easily scripted to try to break.

Gift Card fraud really is a public relations problem for retailers - it is not a financial problem per se, because the retailer has already been paid for the gift card and it is the customer that is losing out to the fraudster. It is a customer relations problem as well... and the retailers that treat it as such are the ones that in the long run come out well.

In our case, we made the customers who came to us to complain about being shortchanged on their gift cards whole with very little requirement for proof on their part. It cost us some money, but the benefits in customer loyalty were very good... but we were able to take that approach because we didn't publicize it - if we had, we would have had a whole other class of opportunistic fraud to deal with that would have been a problem.

Interestingly, the "last 4 digit" validation has become very common (not universal by any means, but widespread).

I've used it as a barometer to see if a company really understands the benefits of the last 4 validation... I've seen at least two different national chains in recent years that have implemented last 4 validation slavishly - to the point of requiring the customer to key in the last 4 digits themselves on self-checkout lanes. This obviously defeats the purpose of the check, as someone who is trying to defraud you can just key in the last 4 digits of the account that they re-encoded into the magstripe instead of using the last 4 of the account number printed on the card.

Andrew • August 13, 2010 3:23 PM

Why do the magnetic strips on the cards contain any data at all before they have had a balance credited to them?

Surely the cards are all programmed with a unique I.D., expiry date and signature (MAC) at the till when the balance is first set?

RockDoggy • August 13, 2010 4:38 PM

@Andrew Because mag stripe *writers* are relatively expensive as compared to mag stripe *readers* and I doubt too many retailers would go to the expense when there are cheaper ways to go about it.

Chris S • August 14, 2010 12:04 AM

Re: why not just give cash.

Scenario...

My nephew has a new XBox. I'd like him to get a game or two. If I give him an actual game, it may be something he either has or isn't interested in. If I give him cash, he's subject to the parental guilt attack. So I give him $50 on a gift card to a major games retail chain. He can get 3 or 4 used games, 2 minor games, or a big chunk of a recent big release.

Dom De Vitto • August 14, 2010 5:09 AM

ok folks, and Bruce, something core still missing from the discussion - risk management.

Basically these cards are electronic versions of printed paper cards. Are they still in use....yes. Are those cards copied...yes. So introduction of electronic cards, that can be copied isn't *increasing* the risk.

I think a lot of us here are forgetting that these companies don't operate at 0% fraud (anything but!).

Suggestions for improvement (last 4 digits...) have simple bypass - get some card copies made, say 10,000 giving you one of each of the last 4 digits. If you ask, you can probably get the same cheapest-in-the-world company to produce the cards as the shop use.

The only way to significantly reduce copy fraud is to introduce 2-factors, e.g. a pin you select at activation. However the added complexity of that will almost certainly be more costly to produce/operate than the current fraud losses, and

The security of these cards, like everything, isn't perfect, but I'd suggest that the risk is well managed at the moment, and you'd hope the 'next barrier' to counter this fraud is known, and ready to deploy for when it makes financial sense.

Tim • August 16, 2010 9:36 AM

We were developing the client side of a gift card system (I'm a POS developer) a few years ago. I pointed out this type of fraud to the client (they had existing system, we were just adding client functionality to CC machine). I was surprised that the response was very negative. They were actually pissed off at me for figuring out this fraud and appeared not to trust me any more. Go figure...

PS: my solution was to have either completely blank cards on display(no actual numbers encded, actual cards stored in cash register). This of course doesnt stop clerk fraud. Minimal solution was to remove customer balace checker (prevent fraudster from easily checking cloned card balance) and alerts when non-activated cards were presented for balance check. Customer never actually implemented any of these relatively simple procedures which while not foolproof would have made fraud harder and more detectable.

Guy • August 16, 2010 8:20 PM

One problem I see with the scratch off section is that gift cards are a very infrequent purchase for most people, so they are not likely to know that there should be a scratch off. So the criminal can just steal the cards, scratch it off cleanly and record the number, and then replace them as usual. The bonus there is that they can make purchases online, so they need not be in physical peril.

Typing the last four digits is good, though a determined attacker could steal 126 cards (the article said this guy had about 1000 cards), and have a better than even odds of having a pair in the batch (birthday attack). If the last number is a check digit, I bet there would be far fewer than 10,000 last-4 combinations as well.

JimFive • August 17, 2010 1:49 PM

@kangaroo: "But what is the interest in the DOS? Once the crooks find that it's merely a DOS without any apparent mechanism to be monetized -- why would they do it?"

Well, one obvious reason to do it would be to stop you from implementing that solution [disabling cards on balance check]. If I wanted to ensure that balance checking remained a valid attack then I could disable all cards that prevented the attack. The stores would demand that you stop disabling unpurchased cards.
--
JimFive

Sherwood Botsford • August 18, 2010 11:39 PM

Cards have a serial number. Someone has to enter this serial number to use the card.

Magstripe has this serial number encoded with company private key.

When card is bought, magstripe is encoded with the gift value, using the 'public' key of that till. Company knows the private key of that till.

Together this info is sent to the company. Company can verify that magstripe serial matches encrypted version of card serial. Company knows which stores have which tills. Company can decode amount of gift card.

Copy the card before purchase.

All you've got is an encrypted version of the serial number. You don't know the number itself (Assuming that the physical number on the card is scratch n sniff.)

Cloning is useless because you don't have a way to check the balance of the card without the number itself.

Copy a purchased card, and it's not much better. You know the serial number, but you had to purchase the card. How do you win?

Clive Robinson • August 19, 2010 3:27 AM

@ Sherwood Botsford,

"Magstripe has this serial number encoded with company private key"

Err what sort of asymmetric crypto system are you thinking of using?

Have a look at the American Bankers Association or ISO standard for the number of usable bits on each of the three data stripes on a mag stripe card.

Then ask yourself how long it would take to factor a public key thats 75bits or less?

Nick N • August 27, 2010 12:37 AM

And exactly how did he get access to the retailer's systems to run his activation checking software??

It doesn't appear that he worked at any of them.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

← Security Analysis of Smudges on Smart Phone Touch Screens Friday Squid Blogging: Squid Computer Virus →

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.