How to clone Google Pay/MasterCard transactions?
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.
Background
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.
(First five transactions were looking like that)
(But after five transactions phone will stop payments unless it will be unlocked)
If the maximum entropy is 999, the terminal will present one of 999 random numbers, and we should have had a wallet's response for this random number being recorded.
For replaying the pre-played transactions, I have taken the famous SwipeYours APK from Dmitry Holodov and added my pre-recorded CVC3 values along with the other static fields:
Suppose we utilise the Bernoulli trial formula for a hacker who will make 20 attempts paying in the shop. In that case, the probability of getting one of the five pre-recorded values for the presented random number will be 10%. For 50 attempts - 22%. It's more than enough if the tokenisation service does not check the gaps between each ATC or the phone owner does not often use the wallet.
Responsible disclosure
Google was informed in January 2021. Shortly after that, they added the additional toggle to disable payments on the locked phone. As the Android security team had never gotten back to us, the only way of tracking their remediation was to keep an eye on the changes of this page: https://web.archive.org/web/20211010141017/https://support.google.com/pay/answer/7644132
However, all other findings were ignored. However, before my eyes, the restrictions were toughing up, and this mode was slowly phasing out. Google gradually reduced the number of allowed transactions on the locked phone across the globe (at least in the M/STRIPE mode). Now, the maximum I was able to find is three. In the UK, it is set to 0. In other regions, like the US, limitations could be less strict.
Outcome
Tokenisation is not as ideal as it could: an issuing bank that comes to Google and says, "we want a GPay wallet for our cards" simply can't tweak their security configuration, set up various limits, maximum entropy, disable legacy modes. And during the wallet authorisation, they do not receive any additional EMV data for the decision-making process by default.
And again, CDA had proved its usability and effectiveness against any data tampering. It's an effective instrument not only for offline terminals.
Latest updates
In light of the latest statements regarding "removing Mag-Stripe modes support" both for Visa and MasterCard:
https://www.emvco.com/specifications/book-c-3-kernel-3-specification/
https://support.nmi.com/hc/en-gb/articles/360032918892-US-Canada-Mandate-Magstripe-MSD-Contactless
https://news.phillips66solutions.com/visa-contactless-msd-transactions-at-the-dispenser-to-be-disabled/
I've been asked multiple times if this mode is dead and if the Pre-Play attack, invented by Roland et al. is infeasible anymore. Well, I have bad news, it is still working. Although none of the four MasterCard cards I checked were vulnerable, GPay/MasterCard supports and approves Mag Stripe transactions. These transactions are authorised not by an issuer but by MasterCard itself at MDES (tokenisation host). So it's a "do what I say, not what I do" situation.
Hence ETH Zurich researchers' last statement is also not accurate https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/information-security-group-dam/research/publications/pub2023/mastercard-usenix23.pdf (page 12)
For anyone who wants more details - issue a GPay MasterCard wallet and check the attack yourself. Some logs of a recent transaction:
>> 00 a4 04 00 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 00
<< 6f 23 84 0e 32 50 41 59 2e 53 59 53 2e 44 44 46 30 31 a5 11 bf 0c 0e 61 0c 4f 07 a0 00 00 00 04 10 10 87 01 01 90 00
>> 00 a4 04 00 07 a0 00 00 00 04 10 10 00
<< 6f 44 84 07 a0 00 00 00 04 10 10 a5 39 50 10 44 45 42 49 54 20 4d 41 53 54 45 52 43 41 52 44 87 01 01 5f 2d 02 65 6e 9f 38 0f 9f 1d 08 9f 1a 02 9f 35 01 9f 7e 01 9f 4e 20 bf 0c 0a 9f 6e 07 08 26 00 00 32 31 00 90 00
>> 80 a8 00 00 2e 83 2c 2c b8 00 00 00 00 00 00 08 26 22 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<< 77 0e 82 02 1b 80 94 08 08 01 01 00 10 01 05 01 90 00 // replaced to 770A820200009404080101009000
>> 00 b2 01 0c 00
<<70 81 89 9f 6c 02 00 01 9f 62 06 00 00 00 00 00 f0 9f 63 06 00 00 00 00 0f 0e 56 29 42 35 31 36 37 36 34 39 37 36 33 32 36 33 31 35 31 5e 20 2f 5e 32 36 30 37 32 30 31 30 30 30 30 30 30 30 30 30 30 30 30 30 9f 64 01 04 9f 65 02 00 f0 9f 66 02 0f 0e 9f 6b 13 51 67 64 97 63 26 31 51 d2 60 72 01 00 00 00 00 00 00 0f 9f 67 01 04 9f 69 1c 9f 6a 04 9f 7e 01 9f 02 06 5f 2a 02 9f 1a 02 9c 01 9a 03 9f 15 02 9f 35 01 9f 33 03 90 00
>> 80 2a 8e 80 19 00 00 06 78 01 00 00 00 00 01 00 08 26 08 26 00 23 06 02 00 01 22 00 00 08 00
<< 77 15 9f 61 02 09 1b 9f 60 02 09 1b 9f 36 02 00 63 df 4b 03 00 10 00 90 00