Close Encounters: How Attacks on Chip Cards Work

Almost all modern bank cards are equipped with a special chip that stores the information needed for payments. In this article, I’ll explain the main types of fraud involving chip cards, as well as the methods banks use to counter carders.

Chip Legacy

One type of information stored on a chip card is the so-called Track2 Equivalent. This data almost exactly replicates the contents of the magnetic stripe and is likely used as a card identification parameter in HSM systems and other card processing subsystems. One common attack involves writing Track2 Equivalent data onto a magnetic stripe, after which fraudulent transactions are carried out either as regular magnetic stripe transactions or in technical fallback mode. To steal this data from ATMs, criminals use devices called “shimmers.”

Shimmer – a device for discreetly capturing data when using chip cards at ATMs.

In one article about shimming, it’s mentioned that in 2006, at the very beginning of chip card issuance in the UK, the Track2 Equivalent field contained the original CVV2/CVC2. Because of this mistake, it was easy to create clones of magnetic stripes for cards that could be used for chip-based payments. Payment systems then decided to use different seeds when generating CVV2/CVC2 fields for the magnetic stripe and the Track2 Equivalent. This seemed to solve the problem-now the secret CVV2/CVC2 value on the magnetic stripe didn’t match what was stored on the chip. But shimming is still alive and well. Why?

Many banks still approve transactions using CVV2/CVC2 values read from the chip! Visa often mentions this, while MasterCard rarely does. One reason, in my opinion, is that in almost all MasterCard cards, the CVC2 in the Track2 Equivalent is set to 000. For Russian cards, this attack is also irrelevant: among dozens of banks I tested over two years, I didn’t find a single card where this attack was possible. However, such attacks are popular in America.

Info: One of the few MasterCard cards where I managed to reproduce this attack belonged to a bank that didn’t check the CVC2 field at all. I could enter anything-000, 999, or any other value. Most likely, the bank had not disabled debug mode, which approves any transaction.

What’s the risk? A hacker could change the Service Code field to indicate the card doesn’t have a chip, and the integrity check for this field would be impossible because any CVC2 would be accepted by processing. This vulnerability, very similar to the next one on the list, was quickly fixed after I notified the bank.

According to my statistics, 4 out of 11 cards were vulnerable to such attacks.

The Brazilian Hack

This term refers to several types of attacks, including one on offline terminals described by Kaspersky Lab. The most widespread attack with this name was covered by Brian Krebs. What was the essence of this notorious attack?

In the early 2010s, chip cards finally became widespread in the US. Several banks began issuing such cards. It’s worth noting that the most common chip scheme in the US is not Chip & PIN, but Chip & Signature. Cardholders don’t need to enter a PIN code; they just insert the card into the reader and confirm the transaction with a signature on the receipt. Why did this scheme catch on? I’ll explain below.

It seems that somewhere in this process, there was an insider leak, and hackers learned that chip transactions were being processed, but not verified on the issuer bank’s side. The bank simply took the Track2 Equivalent field and performed identification as if it were a regular magnetic stripe transaction. There were a few nuances: under the new EMV Liability Shift rules, responsibility for this type of fraud now lay with the issuer bank. And issuer banks, not fully understanding how these cards worked, didn’t impose strong restrictions on “chip” transactions and didn’t use anti-fraud systems.

Carders quickly realized they could profit from this. They opened merchant accounts and, using Track2 magnetic stripe data bought on the black market, performed hundreds of “chip” transactions. The investigation took years, and by the time it was over, the fraudsters had disappeared. The loss amounts are undisclosed, but they were clearly significant. The saddest part is that since then, people from Latin America have been searching worldwide for “white whales” and actively testing banks, trying to find another such unprotected debug interface.

Cryptogram Replay and Cryptogram Preplay

In the “wild,” this type of attack has only been observed once. It was documented and described (PDF) by well-known specialists from Cambridge University.

The essence of the attack is to bypass mechanisms that ensure the uniqueness of each transaction and cryptogram. The attack allows “cloning transactions” for later use without access to the original card. In the first part, it was already explained that the card receives a certain set of data: amount, transaction date, and two fields that provide entropy, even if the amount and date are the same. From the terminal side, entropy (2³²) is provided by 4 bytes of the UN (Unpredictable Number) field. From the card side, it’s the ATC (Application Transaction Counter), which increases by one each time. The pseudo-function looks like this:

Cryptogram = Signature(ATC, UN, Amount, Misc, SecretKey)

If any of the fields change, the cryptogram output changes. But what happens if all the fields remain the same? The previous cryptogram remains valid. This leads to two possible attacks on chip transactions:

• Cryptogram Replay. If a compromised terminal issues the same UN field, a cryptogram read from the card with a predictable UN can be used as many times as desired. Even the next day, attackers can send information about the old cryptogram with the old date in the authorization request, and it won’t be rejected. In my tests last year, I repeated the same cryptogram seven times over seven days, and the bank didn’t notice anything suspicious.

• Cryptogram Preplay. This scheme is used if a vulnerable terminal returns not the same UN, but predictable ones. This is how a vulnerable ATM worked in the Maltese attack described above. In this case, the attacker, with physical access to the card, clones several transactions “for the future.” Unlike the first attack, each transaction can only be used once.

This attack is interesting from the perspective of EMV protocol development. When the protocol was created, the ATC field was specifically designed to protect against such attacks. The issuer bank was supposed to check the ATC value, and if these values arrived out of order or with noticeable jumps, suspicious transactions would be declined.

For example, if processing received transactions with ATC values 0001, 0002, 0008, 0008, 0008, 0009, 0010, 0003, 0004, the operations with highlighted numbers should be considered suspicious and declined. But then complaints from customers started coming in, and the technology was adjusted.

Consider this example: a bank client boards a plane and pays with their card using an offline terminal. Then, after landing, the client pays with the card at a hotel. Only after this does the terminal used on the plane connect to the network and transmit the transaction data. In this case, an ATC jump is recorded, and according to payment system rules, the bank could decline a completely legitimate transaction. After several such episodes, payment systems adjusted their requirements for “ATC jumps”:

• Jumps should only be considered if the delta between counter values is “above X,” where each bank must determine the value of X individually.
• Jumps are not necessarily a sign of fraud, but constant jumps above X are a reason to contact the client for clarification.

However, the first scenario-cryptogram replay-was left out of these changes. If card processing is designed correctly, there’s no reasonable explanation for a situation where the same set of data (Cryptogram; UN; ATC) is received multiple times and successfully approved by the bank. Over the past year, I reported this attack to more than 30 different banks and received a wide range of responses.

In some cases, poor processing service design means the bank can’t simply block operations with identical values. Also, in the “wild,” I haven’t encountered terminals that return the same UN value. So attackers have to use their own terminals, making money laundering more difficult.

Moreover, even offline authentication doesn’t always help: it can be bypassed if the UN source is compromised. In this case, it’s possible to pre-calculate the resulting DDA/CDA authentication values for a predictable UN field.

Statistics show that 18 out of 31 bank cards are vulnerable to replay/preplay attacks for contact or contactless chips. At the same time, in Russia, I couldn’t find a single bank vulnerable to this type of attack, which is quite interesting.

PIN OK

This is probably the most well-known chip attack. The first theoretical prerequisites for this attack were described by a Cambridge team in 2005 in the Chip and Spin study, a year before the EMV standard became widespread in the UK. But increased attention to this attack came much later.

In 2010, a full-fledged study by the Cambridge group was published, dedicated to the PIN OK attack. For this attack, they used a device implementing a “man-in-the-middle” technique between the card chip and the terminal reader.

In 2011, at the Black Hat and DEFCON conferences, a group of researchers from Inverse Path and Aperture Labs presented more information about this attack. That same year, an organized crime group used 40 stolen bank cards to make 7,000 fraudulent transactions, resulting in the theft of 680,000 euros. Instead of the bulky device used by researchers, the criminals used a small, inconspicuous “second chip” installed on top of the original, allowing them to emulate the attack in real-world conditions.

In December 2014, researchers from Inverse Path revisited the topic of EMV transaction attacks and presented some statistics collected over three years (PDF). In 2015, a detailed technical study of the attack was published (PDF), describing a real attack by unknown criminals in 2011.

Let’s look at the technical details of this attack. To carry it out, you need to use a man-in-the-middle technique. The card transmits the CVM List (Card Verification Method)-a prioritized list of cardholder verification methods supported by the card. If the first rule on the card is “offline PIN encrypted/unencrypted,” nothing happens at this stage. If the first rule is different, during the attack, the first rule is replaced with “offline PIN.”

The terminal then asks the cardholder for a PIN code. The “offline PIN” rule means the PIN will be sent to the card for verification in plain or encrypted form. The card will respond with either 63C2 (“Incorrect PIN, two attempts left”) or 9000 (“PIN OK”). At this stage, the attacker, having inserted themselves into the authorization process, replaces the first response with the second.

At this point, the terminal believes the PIN was entered correctly and requests a cryptogram from the card (Generate AC request), passing all required fields. The card knows the PIN was either not entered at all or entered incorrectly. But the card doesn’t know what decision the terminal made. For example, some terminals, when an incorrect PIN is entered, ask the cardholder to sign on the touchscreen-for their convenience. So when the terminal requests a cryptogram, the card provides it. The response contains the CVR (Card Verification Results) field, which indicates whether the PIN was verified by the card. Moreover, this field is part of the payment cryptogram, and attackers can’t change its value: any attempt will result in a cryptogram verification error on the HSM.

The terminal sends all the data in an ISO 8583 Authorization Request packet to the acquiring bank, which then forwards it to the issuing bank. The bank sees two fields: CVMResults, which indicates that offline PIN was chosen as the verification method and that the terminal supports this method. But the bank also sees that the card did NOT accept the PIN or that it was entered incorrectly. And yet, the transaction is approved.

If the card uses CDA authentication and attackers need to replace the first CVM list rule, offline authentication will fail. However, this is always bypassed by replacing the Issuer Action Code fields. Details of this case are described in the latest 2014 presentation by Inverse Path experts.

Also, in the first 2011 study, specialists showed that the EMV standard allows transactions to proceed on the payment device even if secure authentication and verification methods fail, always choosing less secure methods (so-called fallback). This opens up other opportunities for attackers, including PIN theft attacks during operations on compromised POS terminals.

Conclusion

Some interesting statistics from the past year: despite the fact that back in 2010, “real security experts” from banks laughed at how some people ignored obvious card processing problems, in 2020 things are still just as bad. Last year’s checks showed that 31 out of 33 bank cards from around the world, including Russian ones, are vulnerable to this attack.

In the next article, I’ll look at attack schemes for contactless cards and related applications-mobile wallets.