Does the online card payment landscape unwittingly facilitate fraud? Ali et al., IEEE Security & Privacy 2017

The headlines from this report caused a stir on the internet when the story broke in December of last year: there’s an easy way to obtain all of the details from your Visa card needed to make online purchases in seconds (4 seconds to be precise). Using the discovered card details to make an international money transfer took just 27 minutes from creating the transfer account to cash in hand (in this case in India, from funds initiating in the UK). That’s fast enough that there’s very little time for a bank to detect fraud and reverse the payment.

Digging a little deeper though, there are also some interesting lessons to be learned about unintended emergent behaviours in complex systems, misaligned incentives, and the state of card payment security in general.

How the attack works

There are two principles at play here: leaking one piece of information can often quickly be escalated into leaking everything, and if you allow enough guesses (or queries), most systems will fall.

An online credit card payment uses up to four fields for validation: the credit card number (the PAN, Primary Account Number), the expiry date, the CVV2 verification number of the back of the card, and the card holder’s address (strictly, just the digits from postcode and house number). At a bare minimum, the PAN and expiry date are required. Note that expiry dates and CVV2 numbers come from relatively small domains: if we assume cards are issued with a lifetime no more than 5 years, that’s 60 different month/year expiry dates; a three-digit CVV2 number has 1000 different possible values.

Assume you have a credit card number (many ways to get hold of one!). We can use the fact that some merchants only require PAN + expiry date to first learn the expiry date in at most 60 attempts. Then we can use merchants that require PAN + expiry data + CVV2 to learn the CVV2 number in at most 1000 attempts. With both of those in hand, and a little investigation surrounding location where the card number was obtained / used, we can crack the address digits (if indeed we need to). Ignoring address for the moment, note that expiry date + CVV2 gives us 60,000 combinations to guess, but by cracking them in stages we reduce it to only 1,060.

All we need now is a way to make lots of guesses. The good news is, there are lots of merchant sites! Start with a list of websites that only require PAN + expiry date (60 such websites would be a handy number). Submit a trial transaction to each of them (you might as well fire all these off in parallel to save time). The one that succeeds tells you the expiry date. Now go to your list of websites that require PAN + expiry date + CVV2. Submit a bunch of requests in parallel again to find out the verification code.

We implemented a set of software tools to carry out the distributed guessing attack, using the research team’s own cards to verify that it is indeed possible and practical to obtain all the information of the card. Included are seven Visa cards with a spread of PAN, expiry date, and CVV2 values. We selected 400 Alexa top rated commercial websites for our investigation.

You only need to obtain PAN + expiry date to use the card on some websites, but more detail is better. On the dark web, you can purchase lists of credit card details. Credit cards numbers on their own are one price, those with accompanying expiry dates a little more, those with CVV2 values more again, and so on.

The experiments run by the authors showed that it is possible to run multiple bots at the same time on hundreds of payment sites without triggering any alarms in the payment system. With a bot configured to use just 30 sites, it took just 4 seconds to obtain all the information for a card.

There is clearly huge potential for abuse here – at scale botnets could be used to e.g. purchase plain credit card numbers on the darknet, enrich them with additional information, and sell them back pocketing the profit. Alternatively, by using them for international money transfers, cash can be in hand in less than half-an-hour. Or using NFC-skimming in busy transport and retail locations your card can be skimmed, details recovered, and cash extracted just by the attacker standing close by.

Each individual merchant could lock-down the number of guesses allowed (it turns out many don’t!), but that doesn’t help as it’s the ability to spread the guesses across multiple sites that does the damage.

State of the practice

From 389 of the top 400 Alexa websites, 26 sites use only two fields for card payment (can be used for cracking expiry date), 291 use three fields (for subsequent cracking of CVV2), and 25 sites use four fields. Most commonly these sites allow 6-10 guesses per transaction before locking the user out, but a significant number (33) allow up to 50 guesses, and 6 allow unlimited guesses. Among these, one of the top-ten most visited websites using only PAN + expiry date, and another of the top-ten sites allowed unlimited attempts to guess the CVV2!

47 of the 389 sites had implemented the 3D Secure payment system. Under the 3D Secure scheme the issuing bank has visibility of all transactions for a card, even when distributed across many websites. This enables the distributed guessing attack to be detected and prevented.

The authors disclosed their results to the top 36 affected (in terms of website traffic) websites. The story of their responses also makes sad reading – 28 of them made no change at all. 6 added delay or velocity filters to make automated repeated guessing harder, and 2 added a requirement for address information.

Perhaps surprisingly, none of the sites reacted by simply putting a hard limit on the number of allowed attempts.

Why don’t merchants tighten security?

There are two problems here: one is that it is not obviously in their interest to tighten security, and the other is that the actions of a single merchant can’t solve the issue.

Here’s one thing a merchant could do: refuse to take Visa cards and only accept MasterCard payments (the MasterCard network has centralised processing that defeats the attack). I pick that as an extreme example to bring out the trade-offs: clearly a merchant that refuses to accept Visa cards is going to lose a lot of business!

Implementing tighter security such as 3D Secure has similar consequences though not as severe: in one study in the USA up to 43% of consumers abandon transactions when the 3D Secure screen is presented, and in China up to 55%. If your systems are being used to help crack card details, but no fraudulent purchases are made on your own site, implementing 3D Secure and taking such a high abandon rate looks like a tough business decision that has high costs to you without any obvious benefit. Even if you are falling victim to fraudsters some percentage of the time, is the loss through fraud greater than the loss through increased cart abandon rates?

Suppose a responsible merchant does add 3D Secure (or other mechanisms that similarly must have the effect of making checkout more cumbersome, and hence increasing abandon rate), this still doesn’t prevent the guessing attacks unless every other merchant does it too. So again the business decision is to hurt your own bottom line, presumably drive traffic to more lax competitors, and still be vulnerable to fraud using the stolen the card once the full details have been obtained elsewhere anyway.

We can drop down a level and try to address the problem in payment gateways. Payment gateways for example can use IP address velocity filters to detect repeated invalid attempts made within a certain time span from the same IP address. (Such a filter would not protect against a distributed botnet trying to crack cards). The problem still remains that although there are less payment gateways than merchants, there are still enough of them to make circumventing velocity filters relatively easy.

How could the problem be fixed?

To prevent the attack, either standardisation or centralisation can be pursued (some card payment networks already provide this). Standardisation would imply that all merchants need to offer the same payment interface, that is, the same number of fields. Then the attack does not scale anymore. Centralisation can be achieved by payment gateways or card payment networks possessing a full view over all payment attempts associated with its network. Neither standardisation nor centralisation naturally fit the flexibility and freedom of choice one associates with the Internet or successful commercial activity, but they will provide the required protection. It is up to the various stakeholders to determine the case for and timing of such solutions