324,000 payment cards breached, CVVs included

About two months ago, a Twitterer going by 0x2Taylor announced a sizeable data dump.

More than 300,000 credit card records were uploaded to the file sharing service Mega; the data has since been removed from Mega, but not before it was widely downloaded by many interested parties.

By some standards, 300,000 stolen records doesn’t sound very many these days.

That’s a sad state of affairs, of course, caused by the daunting size of some high-profile attacks that have hit the news recently.

This year alone, we’ve reported on breaches covering about three orders of magnitude, where each breach is in the exponential vicinity of ten times bigger than the one before it in the list:

• Opera announces data breach: stored passwords stolen for 1.7M users.
• Data breach in China: 100 million records used to hack 20 million Taobao users.
• 117 million LinkedIn records up for sale on the dark web.
• MySpace breach could be the biggest ever – half a BILLION passwords!

Nevertheless, this newly-announced breach, dumped in a file by the name Bluesnap_324K_Payments.txt, is intriguing because even though the breach doesn’t include full credit card numbers (the so-called “long number” on the front of your card, usually 16 digits), it does include CVVs.

Understanding the CVV

CVV is short for Card Verification Value, confusingly also known as a CVC, where the second C means Code, and as a CVV2, where the 2 means it’s a “version two” CVV code, not that it’s the second such number on your card.

On most cards, the CVV is a three-digit number printed, rather than embossed, on the back of the card.

The CVV is often printed on top of the fragile signature strip, and is never encoded into the data stored on the magnetic stripe.

The idea is that the CVV is a basic anti-fraud mechanism for so-called Card Not Present transactions, which is why you are often asked for it when paying over the phone or online.

A skim of your card’s magstripe, or an imprint from an old-fashioned zip-zap machine (they still exist!), doesn’t capture the CVV.

If crooks get hold of a traditional credit card dump, consisting only of data that can automatically be acquired from the card, they can’t easily use your card online.

The crooks can, however, create cloned cards, using counterfeit blanks bought online, at least in countries that still widely accept unchipped cards, and go on a spending spree.

In this case, they often recruit money mules who are already in trouble with the law, for example because they’re illegal visa overstayers who can’t get jobs and are desperate for undocumented income.

If the dishonest purchasers are caught, they’re in double trouble, and they can simply be hung out to dry by the crooks, left to face prosecution, prison and deportation in no particular order. (Basic vigilance during the sales process and at the checkout can often rumble this sort of fraud.)

But with a skimmed card and the CVV, the crooks can use stolen cards online, without ever entering a real shop, standing in front of a checkout person, being asked to show photo ID, or facing up to a suspicious security guard.

Securing the CVV

Of course, the ongoing usefulness of your CVV depends very heavily on it never, ever being stored permanently anywhere except the printed digits on your card.

Once a transaction goes through, the CVV should be discarded and not left behind in memory, saved on disk, written into a logfile, or otherwise helpfully remembered until next time.

In fact, in this so-called “Bluesnap” breach, it looks as though the payment processor didn’t intend to save the CVVs, but nevertheless managed to dump them into the stolen database as part of a debug log.

According to well-known breach-tracker Troy Hunt, the dumped database has fields such as first_name, last_name, expire_year and other bad-enough-on-their-own data items.

But it also has a giant field at the end of every record called xml_debug, in which all sorts of additional data, including the CVV, is included as a blob of XML.

The XML includes a subfield called card-number that is rendered as TAKEN OFF FOR SECURITY REASONS, even though it’s technically lawful to store card numbers (though they must be protected when saved).

Ironically, however, the redacted card number is almost immediately followed by another subfield called security-code, where the never-to-be-stored-at-all CVV code can be found in clear text.

Bluesnap, which gives its name to the file that was dumped, is indeed a payment processing provider, but the company is quoted on Troy Hunt’s site as saying:

We were not breached. Immediately following the original discovery, we hired a top Security Consulting firm to run an audit of our environment. They concluded that BlueSnap was not the source of the data loss.

Troy Hunt suggested that a payment processor called Regpack, a customer of BlueSnap, might be the source of the leaked data, and was originally told:

As a preventive measure, we ran a full forensic investigation and it has concluded that there was no data breach on Regpack servers. In spite of that, we have run the full security protocol implemented in these cases and conclusively determined that our servers were not involved.

But that denial was later replaced with this updated statement:

Regpack has confirmed that all payments information passed to the payment processor is encrypted on its databases. Nonetheless, periodically, this information is decrypted and kept internally for analysis purposes. We identified that a human error caused those decrypted files to be exposed to a public facing server and this was the source of the data loss.

Curiously, Regpack went on to say that “[n]either Regpack nor BlueSnap had our systems breached,” which seems a peculiar assertion under the circumtances.

Regapck also neglected to mention that the data it “kept internally for analysis purposes” included CVVs, which may not be kept for any purpose, whether encrypted or not.

What to do?

• If you request and use CVVs at any time, you MUST NOT store them, so don’t. Don’t write them down on paper, don’t save them to disk, don’t include them in logs, and never keep them “for analysis purposes.”
• If you keep debugging logs, review them regularly to make sure you aren’t storing prohibited data by mistake. Don’t allow programmers to add data collection features to production code without a strict approval process, even if their motivation is to do the right thing and fix a known problem.
• If you record phone calls “for security purposes,” don’t record the parts during which you expect purchasers to read out credit card details aloud. The irony of weakening security under the guise of improving it, by carefully recording prohibited data, should be obvious.