On the 15th of October, the UK will be increasing Tap & Go limits from £45 to £100 but what does that mean?
It means that UK cardholders can pay for goods up to £100 in stores using contactless cards without providing any cardholder verification such as PIN or signature. In addition, you’d be able to do it five times in a row before most banks ask you to insert a card using the chip.
Ok, but what does that REALLY mean?
This means that the government and banking industry are sure that lost and stolen fraud has decreased enough so that limits can be increased without significant fraud losses. The most popular type of contactless fraud is when someone finds or steals a contactless card and uses it in store. Now each contactless operation is limited to £45 and it will increase to £100, does that mean that overall losses associated with evil-minded “entrepreneurs” will increase twice as well?
We will try not to speculate on this topic quite yet. Especially when a lot of people are polarising the “cash or card” question: when one group is avoiding cash and coins by any means, another group is more concerned about privacy issues related to a “cashless only” future.
Instead of taking anybody’s side in this controversial topic, we will remind you how easy it is to pay using blocked cards and how easy it would be to bypass these “imaginary” £100 “Tap & Go” limits for fraudsters. Let us show you how many misconfigurations still present are in modern Visa and MasterCard cards.
We will walk through two attacks. First, we show how hackers could pay with Visa cards even after exceeding the PIN tries on the card, typically set to three. In the second attack, we show how it’s possible to bypass the limit of three attempts to guess a correct 4-digit PIN code number and conduct an attack that tries all possible PIN code digits.
Why do we discuss these attacks together? Both attacks utilise flaws in EMV specification and EMV implementations in different banks. Both attacks also require the Man-in-The-Middle technique to manipulate different fields during the communication between the card and the terminal. For the NFC MiTM attack, you can use two PN532 NFC readers or two Android-based phones equipped with NFC readers. Intercepting and changing the EMV data is a bit more tricky. The main problem here is latency and delays that can cause the termination of communications. For our demonstration, we will use the project of a pioneer of EMV attacks – Omar Choudary from the University of Cambridge.
Attack 1. The Cryptogram Confusion Attack or how to pay with locked cards.
Almost every Visa and MasterCard card can verify PIN codes themselves, this is called “Offline PIN Verification”. For most cards, if the cardholder enters the PIN incorrectly three times, it will restrict the card functionality. After that, the card informs the bank and POS terminals about the incorrectly entered PINs. Sometimes that limits the NFC interface, as the card should verify the next transaction only using an online PIN that the issuing bank will check online, and the NFC interface does not have this feature.
We have had this experience ourselves. Having exceeded the number of PIN tries, we were unable to pay using NFC or chip, and couldn’t reset the PIN tries counter at an ATM. With that background, how could someone bypass this deadlock?
Look at the NFC communication between the card and the reader:
The last card’s response indicates that the card is invalid for NFC operations, as 6283 APDU response stands for “Selected file invalidated”. But if we will change the 6283 to 9000 ,response that everything is ok, that is what will happen next:
T->C (Terminal sends a Generate AC request, asking the card to provide a cryptogram)
C->T (Card responds not with an online cryptogram, but with a decline cryptogram 9f270100)
After that fix we see that the card responds not with an online ARQC cryptogram, but with a decline AAC cryptogram. You can read more about different EMV cryptograms here: https://www.emvco.com/wp-content/uploads/2017/05/A_Guide_to_EMV_Chip_Technology_v2.0_20141120122132753.pdf.
This is also indicated in the 9f10 field that should be processed by the issuer:
[9F10 (issuer application data)] 06011203800000
[Card verification results] 03800000
[Byte 2 Bit 6 = 0, Byte 2 Bit 5 = 0] AAC Returned in GPO/first GENERATE AC
However, the card still responds with the consecutive ATC. What if the algorithm for generating the AAC cryptogram is exactly the same as for the ARQC cryptogram? The only way to distinguish these two cryptograms for the issuing bank would be to check a CVR field and ensure that the cryptogram type is correct. Not a big fan of theories, we got straight into tests. We changed the cryptogram type from 9f270100 to 9f270180, the online ARQC cryptogram, and voila!