At the beginning of this year, we have discovered many different vulnerabilities that allow making payments on locked Apple and Samsung phones with the activated Transport mode. You can read more about that in our whitepaper: https://www.paymentvillage.org/resources
Unfortunately, due to complexity, a lot of content, and significant differences in attacking scenarios, I didn't show anything about Google Pay during the presentation and various interviews. Instead of that, I always referred to the whitepaper, and today my dear friend Quentyn Taylor and I are planning to cover this part.
The fundamental difference between Apple/Samsung and Google wallets is that Google Pay allowed payments on locked phones everywhere, way before Transport modes were introduced. In 2019 we had shown how vulnerabilities in Visa PayWave could be used to make payments on locked Android phones above "Tap and Go" limits (£100 now in the UK). That is why when I discovered new findings in Apple and Samsung, I decided to cover the MasterCard/Google Pay case as the last piece in this research.
With a bit of effort, I made a functional clone of the Google Pay wallet for the limited amount of transactions. That means if the hacker has temporary access to the locked phone, he can collect enough information to pay later on in the supermarkets, using the previously collected data. It is the "transactions' cloning" attack instead of the "card cloning" – when hackers are limited with the number of possible payments they can make.
For this attack, I used the old technique that Michael Roland found in 2013 - https://www.usenix.org/sites/default/files/conference/protected-files/roland_sec13_slides.pdf. He utilised the weak PayPass M/STRIPE legacy mode of the MasterCard cards. Let me briefly enumerate the issues of this mode that he discovered:
1. No AIP, price, date and other essential fields are in the cryptogram input. Some of these fields are presented in the Generate AC request, but they do not affect the CVC3 authentication code.
2. Low UN entropy. Because the M/STRIPE mode generates a unique Track2 Equivalent for each transaction, it has a limited alphabet (digits only) and limited space for the CVC3 and the UN. The most popular length of the UN – 3 or 4 digits. That is equal to 999 or 9,999 possible values that need to be recorded for successful cloning of all potential outputs for the following transactions.
3. To protect against low entropy, banks should check the ATC values and prevent transactions with this counter out of order. Instead of consecutive ATCs for every subsequent transaction, ATC suddenly jumps up or down, indicating the potentially compromised card/wallet.
Since the time of the original presentation, banks and MasterCard have tried to balance potential fraud risks and false positives that inevitably lead to angry customers who can't pay for their goods. That is why not many banks at the moment use the ATC out of order as a fraud indicator. Other banks raise the threshold for the ATC gap, e.g. the difference of more than 50 or 100 between each following ATC value is considered a sign of potential fraud, but banks don't care if the jumps are lower.
Findings affecting Google Pay
Surprisingly MasterCard tokenisation service (MDES) does not implement their recommendations themselves. Also, Google mandates to enable weak M/STRIPE mode for every enrolled MasterCard mobile wallet. What are my findings related to M/STRIPE Google Pay:
1. Low entropy as well as for physical cards. 50% of the tested cards had the maximum UN value of 999, another half of the cards – 9,999.
2. CVM requirement flag bypass. In regular M/CHIP transactions, the CVMResults field affects the locked phone decision to finish the transaction or to decline. And even though the CVMResults field is not part of the cryptograms for most cards and wallets, none of the data could be tampered. Thanks to mandatory CDA for this again! But the M/STRIPE mode CDA does not work, as M/STRIPE specifically was created for terminals that do not support modern cryptography.
3. ATC out of order. ATC from the wallet looks like random two bytes, not consecutive at all. Later from one wallet brand, I found out that this is called CryptoATC, and it was created explicitly for tokenisation by MasterCard. MDES decodes the CryptoATC values during de-tokenisation to the traditional consecutive ATC values.
To check the lack of "ATC out of order" controls, I presumed each transaction still had its original iterative ATC. After that, I replayed pre-recorded transactions where presumable values have had a significant gap (more than 50) between each transaction other.
The attack scenario
Now, how the attack works: if the phone is locked, you are limited with the number of transactions you can make, and each transaction has a limited amount. That is very similar to what is going on with the contactless cards in Europe now due to PSD2 and Strong Customer Authentication. Let's say we have only five tries, as it was in the UK by the time of my submissions to the Android Security Team.