First contact. Attacks on chip-based cards

Chip-based Legacy

One of the data types stored on chip-based cards is the so-called Track2 Equivalent. It almost identically replicates the content of the magnetic stripe and, most likely, serves as a card identification parameter in HSM systems and other card processing subsystems. One of the attack types performed by crooks from time to time works as follows: Track2 Equivalent data are recorded onto a magnetic stripe, and fraudulent transactions are made either as normal magnetic stripe transactions or in the technical fallback mode. To steal such data from ATMs, special devices called shimmers are used.

One of the articles about shimming states that back in 2006, in the early days of chip-based cards, the Track2 Equivalent field of cards issued in the UK contained the original CVV2/CVC2. This error enabled scammers to clone magnetic stripes of such cards. In response, payment systems started using different seeds to generate the CVV2/CVC2 fields on the magnetic stripe and in the Track2 Equivalent field. The problem seemed to be solved: the value of the secret field CVV2/CVC2 on the magnetic strip doesn’t match the one recorded in the chip anymore. But shimming is still alive and thriving. Why?

The point is that many banks still authorize transactions with CVV2/CVC2 values read from the chip! Visa often mentions this; by contrast, MasterCard mostly ignores the problem. In my humble opinion, this is because in almost all MasterCard cards, CVC2 in Track2 Equivalent is equal to 000. Also, some regions are more prone to these attacks than others. For example, this type of scam is widespread in the USA.

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

Brazilian hack

This term refers to several types of attacks, including those targeting offline terminals as described by Kaspersky Lab. In addition, Brian Krebs published an article about the biggest such attack in the world. So, what is it all about?

In the early 2010s, chip cards finally became widespread in the USA. Several banks started issuing such cards.

We can only speculate about the origin of the attack. Probably, some insider information leaked, and hackers became aware that chip transactions were made in some kind of the debug mode, in which the issuing bank didn’t verify the cryptogram. The bank simply used the Track2 Equivalent field to perform identification as if it were an oldie-goodie magnetic stripe transaction. An important nuance: under the new EMV Liability Shift regulations, the issuing bank bears responsibility for this kind of fraud. Too bad, the vulnerable issuing banks neither fully understood how such cards work nor imposed strict antifraud rules for chip-based transactions.

Carders quickly realized what benefits could be derived from this situation. They started opening merchant accounts and making hundreds of ‘chip-based’ transactions using data of Track2 magnetic stripes purchased on the black market. The investigation took years, and by the time of its completion, the scammers had already disappeared. These days, a lot of criminals in certain countries of Latin America have been searching all parts of the world for ‘white whales’ and actively testing banks, hoping to find another target for the Brazilian hack. A few years ago hackers have found a bank that forgot to disable the debugging mode.

Cryptogram Replay and Cryptogram Preplay

‘In the wild’, such an attack was performed only once. It has been documented and described (PDF) by well-known experts from the University of Cambridge.

The attack makes it possible to bypass mechanisms that ensure the uniqueness of each transaction and cryptogram. Criminals could just ‘clone transactions’ for future use (when you won’t have access to the original card). As was explained in the first article, the card receives a certain set of data at the input: transaction amount, transaction date, and two fields that ensure entropy even if the transaction amount and date are the same. On the terminal side, the 2³² entropy is ensured by 4 bytes of the UN field (a random number). On the card side, it is the ATC transaction counter that increases by one each time. The pseudofunction looks something like this:

If one of the fields changes, the output value of the cryptogram changes as well. However, what happens if all fields remain the same? In that case, the previous cryptogram remains valid! That creates possibilities for two types of attacks targeting chip-based transactions.

Cryptogram Replay. If a compromised terminal returns the same UN field, a cryptogram with a previously transmitted predictable UN field that was once read from the card can be used multiple times. Even on the next day, the attacker can submit an authorization request with information about the old cryptogram and with the old date – and this won’t lead to rejection. In my last year’s tests, I used the same cryptogram seven times over seven days without raising any suspicions from the bank.

Cryptogram Preplay. This scheme is used if the vulnerable terminal returns not the same UN value but some predictable values. It is how the vulnerable ATMs operated in the Maltese attack described above. In this case, the attacker gains physical access to the card and clones several transactions ‘for future use’. Unlike the previous attack, each such transaction can only be used once.

This attack is of interest in terms of the EMV protocol development history. When the protocol was in development, the ATC field was introduced specifically to protect cards against such attacks.

The issuing bank had to check the value of the ATC field; if its values were received out of order and/or with noticeable ‘jumps’, suspicious transactions were rejected.

For instance, if ATC values of transactions were received for processing in the following order: 0001, 0002, *0008*, *0008*, *0008*, 0009, 0010, *0003*, *0004*, then the operations in this sequence whose numbers are enclosed in asterisks were considered suspicious and had to be rejected by the processing. But then customers started complaining, and adjustments were made to the technology.

A simple example: a cardholder boards a plane and pays with a card using an offline terminal during the flight. Then the plane lands, and the client pays with the same card at the hotel. And only then the terminal used in the aircraft connects to the network and transmits the transaction data. This results in an ‘ATC jump’ and, pursuant to the rules adopted by payment systems, the bank can reject a 100% legitimate transaction. After several such episodes, payment systems made the following adjustments to their policies for ‘ATC jumps’:

• ‘jumps’ should be counted only if the delta between the values of the counter “exceeds X” (the X value is determined individually by each bank); and 
• ‘jumps’ don’t necessarily indicate fraud; however, constant jumps above the X value are a reason to contact the client and clarify the circumstances.

However, the first scenario (i.e. cryptogram replay) wasn’t affected by these changes in any way. If the card processing is designed correctly, there is no reasonable explanation for the situation when the same data set (Cryptogram, UN, and ATC) is sent many times and successfully approved by the bank. Over the past year, I have submitted information about this attack to more than 30 different banks and received a fairly wide range of responses.

In some cases, the bank cannot simply block transactions with the same values due to the incorrect design of their processing services.

I also must note that I had never encountered terminals returning the same UN field value ‘in the wild’. Therefore, attackers have to use their own terminals, which makes money laundering more difficult.

In addition to that, a predictable UN could lead to falsely passed offline card authentication. If UNs are not random, criminals could precompute the resultant DDA/CDA authentication scheme values for a predictable UN field.

Statistics indicate that 18 out of 31 bank cards are susceptible to replay/preplay attacks targeting contact or contactless chips.

PIN OK

Perhaps this is the most well-known attack type targeting chips. The Cambridge team outlined the theoretical prerequisites for this attack in a study entitled Chip and Spin back in 2005 – a year before the massive introduction of the EMV standard in the UK. But a closer public attention was attracted to this attack much later.

In 2010, the Cambridge team published a study dedicated to the PIN OK attack. To deliver such an attack, the researchers used a device implementing the man-in-the-middle (MITM) technique between the card chip and the terminal reader.

In 2011, at the Black Hat and DEFCON conferences, Adam Laurie, with a group of researchers from Inverse Path and Aperture Labs, presented more practical information about this attack. Also, in 2011, an organized crime group used 40 stolen EMV cards from one French bank to make 7,000 fraudulent transactions totalling €680,000. Instead of the bulky device used by the researchers, the criminals used a small inconspicuous ‘second chip’ installed on top of the original one, which made it possible to emulate an attack in real-life conditions.

In December 2014, researchers from Inverse Path have brought up this topic (i.e. attacks on EMV transactions) again and presented some statistics collected over three years (PDF). In 2015, a detailed technical review of the attack performed in France in 2011 was published (PDF).

Let’s examine the technical aspects of this attack. As you remember, it involves the man-in-the-middle technique. The card sends the CVM (Card Verification Method) List field to the terminal – a priority 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, criminals should replace it with the “offline-PIN”.

Then the terminal requests a PIN code from the cardholder. The “offline PIN” rule means that the PIN code will be transmitted to the card for verification in plain or encrypted form. The card will respond with either 63C2 “Invalid PIN, two attempts left” or 9000 “PIN OK”. At this stage, the attacker that could affect the cardholder verification process replaces the first response with the second one.

So far, the terminal believes that the PIN was entered correctly; so, it requests a cryptogram from the card (Generate AC request), and passes all the requested fields to it. The card knows that the PIN was either not entered at all or entered incorrectly. But the card cannot see the decision made by the terminal after that. For instance, if the entered PIN code is incorrect, some terminals request the cardholder to affix the signature on the touchscreen: this feature has been introduced for the client’s comfort. Therefore, when the terminal requests a cryptogram, the card transmits it. The response contains the CVR (Card Verification Results) field, which indicates whether the card verified the PIN or not. Furthermore, this field is part of the payment cryptogram, and attackers cannot change its value: any such attempt would cause a transaction authorization error during the cryptogram checking on the HSM.

The terminal sends all data in the ISO 8583 Authorization Request packet to the acquiring bank. Then the data is sent to the issuing bank. The authorization host at the bank sees two fields: CVMResults, which indicates that “offline PIN” verification method was selected. The bank also sees that the card did NOT receive the PIN code or that it was wrong. And, no matter what, the bank approves the transaction.

If the card uses the CDA authentication scheme and attackers have to change the first rule on the CVM list, the offline authentication will fail. However, this can always be bypassed by changing the Issuer Action Code fields. The details of this case are described in the latest version of the presentation made by the Inverse Path experts in 2014.

In addition, in their first study dated 2011, these specialists have demonstrated that the EMV standard permits the payment device not to reject transactions even if the card authentication and the cardholder verification both failed. Instead, the terminal continues choosing less secure methods every time (so-called fallback). This opens up new opportunities for scammers, including attacks that steal PIN codes during transactions on compromised POS terminals.

Conclusions

Interesting statistics for the last year: some obvious card processing problems identified back in 2010 still remained unsolved as of 2020. Last year’s statistics indicate that 31 out of 33 bank cards from all parts of the world are vulnerable to the PIN OK attack.

The next article will address attacks on contactless cards and related applications (i.e. mobile wallets).