Hack Google Pay, Samsung Pay and Apple Pay

[Tomcat]

The content of the article​

• Background
• Tokenization
• Attacking Samsung Pay
• Attacking Apple Pay
• Attacking Google Pay
• Results

Electronic wallets Google Pay, Samsung Pay and Apple Pay are considered the most modern payment tools. However, they are also susceptible to vulnerabilities because they still depend on technologies created thirty years ago. In today's article, I will talk about methods for hacking popular electronic wallets, and also reveal the details of a new attack on EMV/NFC wallets and cards - Cryptogram Confusion.

Read also​

You can learn about the principles on which the security of banking payment systems is based from my previous articles:

• We attack contactless cards
• How attacks on chip cards work
• How carders steal money from bank cards
• Understanding how credit card security systems work

BACKGROUND​

If you trace the evolution of the EMV standard, in the beginning there were chip smart cards. These cards were then equipped with an antenna and turned into contactless cards, inheriting almost all the functions from EMV. But this was not enough for card brands, and in 2011, the then existing Google Wallet was equipped with a contactless payment function using NFC.

Google used the Host-Card Emulator (HCE) approach, where the end device does not contain all the private and symmetric encryption keys, similar to a smart card, but from time to time downloads a one-time key (Single-Use Key, SUK) for each subsequent operation . Following this approach so far, phones with Google Pay do not allow you to make more than twenty transactions without an Internet connection. In 2012, Samsung and Apple introduced their wallets using Secure Element technology. They work in a similar way to smart cards, where a physically and logically protected chip guarantees protection against interception, reading, and rewriting of secret keys, on the basis of which 3DES EMV cryptograms are created and data is signed using asymmetric RSA.

In the past, Slawomir Jasek showed an example of successfully transferring Google Pay from one device to another. At the same time, it was possible to receive SUK keys from Google servers other than the original device. Peter Fillmor also took a closer look at the Apple Pay device. In 2017, at the Black Hat USA conference, I demonstrated a replay of an attack on Apple Pay online cryptograms .

Two years ago, I started researching the security of mobile wallets when paying with NFC. At that time, Google Pay was the only wallet that allowed you to pay with a device with a locked screen. I was very quickly able to use the attack I used for Visa contactless cards to bypass the NoCVM or Tap & Go limits (in Russia they are 3,000 rubles). To do this, it was only necessary to activate the screen on the locked phone. If the owner still has the phone in his pocket, this can be done by sending a command via Bluetooth or Android Beam. Despite the statements of experts that “the formats and operating protocols of contactless cards of different international systems are not fundamentally different,” I categorically disagree with this, because I was not able to use the same attack against MasterCard.

At the end of 2019, Samsung and Apple introduced support for “transport schemes” in large cities: New York, Tokyo, London. In many transport systems, payment depends on the distance of the trip, and the final payment amount is calculated based on the point of entry into the metro and the exit point. Therefore, withdrawing a standard amount at the first “tap” of a card or wallet is incorrect. Further, despite the turnstiles’ stable connection to the Internet, they do not request authorization for online transactions because the connection takes a long time. Instead, asynchronous authorization is used. And to counteract fraud, offline authentication is used according to the modern CDA standard, described in the EMV specifications. I have already talked about the operating principle of CDA in the article “ Close Encounters. We understand how credit card security systems work.”

Finally, the last problem with e-wallets is the need to unlock your Apple or Samsung phone every time you approach a subway turnstile. Extremely inconvenient, isn't it? This is why both Samsung and Apple made it possible to pay in transport without unlocking the phone.

TOKENIZATION​

Mobile wallets exist thanks to tokenization technology: the card is added to the mobile wallet, the data is sent to the international payment system, which, after confirming all the details, creates a “virtual card”. It can only work via NFC, and only on the device on which the card was added. But this is in theory.

Tokenization technology

The advantage of a mobile wallet is that the use of tokens is limited. If the token is compromised, attackers cannot use the stolen virtual card data to create a clone of the magnetic stripe or pay with such a card on the Internet. That is why banks, card brands and large manufacturers of mobile wallets (Apple, Google, Samsung, Huawei and others) unanimously claim that the security of mobile wallets is at its best.

Starting from the moment the card is replaced with a token, issuing banks cease to play a significant role in authorizing transactions and risk management. Yes, they receive information about the location and type of merchant, amount, transaction date. However, all cryptographic functions and EMV field analysis are transferred to the tokenizer (Visa VTS or MasterCard MDES). The code that runs in the mobile wallet is also written, audited and certified by one of the MPS. Apple or Samsung seem to have nothing to do with it - they act as a façade, but the Ministry of Railways does all the work for them. And it becomes more difficult for the issuing bank to judge fraudulent transactions due to lack of data.

Therefore, transactions using mobile wallets, unlike bank cards, are almost never accidentally blocked by anti-fraud systems. This is precisely where one of the main problems lies: those responsible for the payment process are hidden inside this process itself, and entities outside (issuing bank, merchant, mobile wallet) have limited decision-making capabilities.

Payment scheme using electronic wallet

ATTACKING SAMSUNG PAY​

Samsung has taken the simple route: when a transport card is activated, NFC is always running on the phone, and all checks designed to distinguish a payment terminal in a supermarket from a terminal in the subway are performed during the EMV/NFC payment phase.

After quickly adding a Visa card and setting it as a transit card on my phone, I armed myself with the Proxmark3 and went to the subway to record transaction data and compare requests from the subway terminal with requests from a regular payment terminal.

The main command in this case is the terminal request to generate a cryptogram (Generate AC) and the wallet response:

->
80a80000438341 - Generate AC header
23004000 - Terminal Transaction Qualifier field (offline CDA authentication required)
54664c20426f6e6420537472656574 (TfL Bond Street) – Merchant Name and Location
9f4bxxxxxxx - data for offline authentication
000000000000000000000000 0826 0000000000 0826 200331 00 4bee1439000 - amount 0.00, currency, transaction date and other fields
<-
9f2701 80 - cryptogram type (online cryptogram, ARQC)
9f3602 000e - operation counter, ATC
9f1020 1f4363 00200000000000000000002172000 - CVR field - Card Verification Results (among other things, indicates the perfect verification method, the type of cryptogram presented, ARQC)
9f2608 a83f66d03cc20d45 - online cryptogram

For payment terminals that authorize payments online, Visa contactless cards do not require offline authentication. But in this case it is mandatory. The phone also checks the amount: if it is not equal to 0.00, then the transaction will not go through. But the phone does not look at the merchant name or merchant category (MCC - Merchant Category Code).

If the payment is made in a regular terminal, offline authentication will not be required and the amount will be different from 0.00. In this case, the phone will return the following response:

<- 6985 (Conditions of use not satisfied)

I decided not to despair and added a MasterCard card, returned to the subway again and performed the same operations:

->
80ae900041 - Generate AC header (offline CDA authentication required)
000000000000000000000000 - the amount is 0.00
4111 - MCC code from the "Transport" category
082600200000000826210307006359313725000000000000000000003f0002 - other fields
<-
9f2701 80 - cryptogram type (online cryptogram, ARQC)
9f3602 000f – operation counter, ATC
9f4bxxxxxxx - data for offline authentication containing
 9f101a 021580000022000000000000000000000000A - CVR field (cryptogram type - ARQC)
 9f2608 02d8b8f76b5c29fc - online cryptogram

For MasterCard cards, offline authentication using contactless cards is mandatory in almost every country and is supported by every contactless card. If it is not successful, the terminal must abort such a transaction. Therefore, the phone checks two fields: the amount and the MCC code.

If the payment is made in a regular terminal, the amount will differ from 0.00 and the terminal code will not be from the “Transport” category. In this case, the phone will return the following response:

<-
9f2701 00 - cryptogram type (AAC, refusal cryptogram)
9f3602 000e - ATC counter, next value from the previous one
9f101a 021580000022000000000000000000000000A - CVR (cryptogram type - AAC)
9f2608 02d8b8f76b5c29fc – AAC Cryptogram

There is already something interesting here. Let me remind you that the cryptogram is a 3DES HMAC from some fields presented by the terminal in the request and values in the card itself, for example ATC. My first guess: what if the keys and calculation algorithm for the AAC cryptogram are exactly the same as for ARQC? After all, the transaction counter increases by 1 each time, even when the AAC cryptogram is returned. If we change the field to, the cryptogram will be accepted by the terminal and sent to the MasterCard tokenization host for authorization. And if this host does not check the values of the flags in the CVR field, where it is still visible that the cryptogram type is different, the transaction will be approved.Generate AC9f270x80

Sounds like a plan, but I had a problem: modification of any fields during communication between the terminal and wallet will be noticed during offline CDA authentication. Here a technique came to my aid, recently discovered by “Swiss scientists” (c) . They discovered that mandatory offline authentication could be bypassed by pretending to be a Visa card, and used this technique to bypass the PIN code.

The first plan of attack has matured:

1. We take the man in the middle device to modify the data between the phone and the terminal.
2. We carry out a Card Brand Mixup attack - a MasterCard pretends to be a Visa card (read how to do this in the Card Brand Mixup Attack study, PDF).
3. In the last step, we apply the Cryptogram Confusion attack: when the wallet returns a cryptogram of type 0x00(AAC), we change the field value 9f27to 0x80(ARQC). I was pleasantly surprised that in the end the Cryptogram Confusion attack went through and the transaction was approved. Here is a video of this attack.

Is it possible to somehow make payments using Visa and other cards, such as American Express, if the phone is locked? Having found no other way to obtain the cryptogram other than requesting authorization for the amount of 0.00, I decided to use the Transaction Stream Manipulation attack. During this attack, data is replaced not between the terminal and the card or wallet, but between the terminal and the acquiring bank, in the ISO8583 Authorization Request. In this case, the attacker has more opportunities to manipulate the fields. For example, the “amount” field appears twice in this request: the first time in the field where all EMV fields are collected, and the second time in the field where the actual amount debited is indicated.[55][04]

In this case, the attack on other cards, including Visa, looks like this:

1. We request a cryptogram for 0.00 in the same way as the terminal in the subway requests it.
2. We create an ISO8583 request, where we indicate the correct fields (amount - 0.00, cryptogram, and so on), but in field [04] we indicate the amount that we want to write off from the card.

Although the Visa wallet reported that the phone was not unlocked, the transaction was approved by the Visa Tokenization Service.

ATTACKING APPLE PAY​

Apple once announced that its phones had learned to support payments with a locked screen, several months earlier than its competitors. However, for a long time I was unable to verify their safety. The main snag was that the phone did not activate the NFC field using regular terminals and contactless readers. I persistently googled how Apple VAS (Value Additional Services) works and tried to use the help of colleagues to reverse Apple Pay binaries (I borrowed their names from Peter Fillmore’s presentation). When I performed transactions on the subway, Proxmark3 did not record any additional data, which left me confused.

When I finished testing with Samsung Pay, I still didn't know what to do with Apple Pay and was desperate. The only terminal I could use at that time was the terminal at the metro turnstile. I decided: if I can record the cryptogram of a transaction in the metro, but the transaction itself does not go through, then I will come home and try to insert the cryptogram into Transaction Stream, as was done with the Samsung + Visa option. After several attempts, I was able to repeat the second type of attack against the Apple + Visa combination.

At the same time, one smart engineer gave me advice not to use Proxmark3, but to take something more reliable, for example HydraNFC. Following this advice, I quickly saw “something” in the traffic - 15 bytes that were sent before the first commands. Back then, it was hard for me to believe that only 15 bytes would unlock NFC on an iPhone, since I had read a lot in patents about the PKI used by Apple in VAS. But this really turned out to be exactly the case: only 15 bytes, and the phone made it possible to read data via NFC even from discharged devices.

Let's see what the generation of a cryptogram looks like with a MasterCard card specified as a transport card in Apple Pay:

->
80ae900041 - Generate AC header (offline CDA authentication required)
000000000000000000000000 - the amount is 0.00
4111 - MCC code from the "Transport" category
082600200000000826210307006359313725000000000000000000003f0002 - other fields

Unlike Samsung, Apple will return the online cryptogram even if the amount does not equal 0.00 (Apple employees said they use or plan to use this feature, so “it’s not a bug”).

However, if the MCC code is substituted, the transaction will be rejected due to CDA. After June 2021, MasterCard closed the Card Brand Mixup Attack option, so it will not be possible to pay at any terminal with this card. But I was still able to carry out attacks using Transaction Stream Manipulation.

What about Visa cards? You can use them to pay in any supermarket in the world using a locked iPhone; to do this, you just need to replace a few bytes when exchanging between the terminal and the phone. Yes, you yourself have most likely already read about this: researchers from the universities of Birmingham and Surrey discovered this vulnerability independently of me around the same time. This vulnerability still exists, even though Visa only needs to add one small condition to its tokenization service to fix it.

ATTACKING GOOGLE PAY​

We already showed in 2019 how you can make payments on a blocked Google Pay wallet using Visa cards above NoCVM limits: to do this, you just need to change the bit in the TTQ field indicating that payer verification is required. I failed to bypass the restrictions on MasterCard cards last time, so I decided to try again. Instead of modifying Transaction Stream, I used an old attack described by Michael Roland in 2013 - Pre-play and Downgrade (in a previous article I mistakenly wrote that the attack was developed by Peter Fillmore in 2014, but this is not true).

It remained a mystery to me why M-STRIPE mode still works in Google Pay wallets for all MasterCard cards. I decided to explore it a little deeper - look at maximum entropy, protection against ATC surges and other protection mechanisms.

It turned out the following.

1. The maximum entropy for cards is 1000 or 10,000. I have not come across any other settings. Let me remind you that a card or wallet with an entropy of 1000 is cloned completely in 1000 requests, this takes about a minute. Next, the attacker does not need the original phone - he can make purchases using the information that was cloned. The number of transactions depends on other security measures implemented.
2. NoCVM restrictions on a locked phone are also accomplished by replacing 1 bit in the request from the terminal, which allows you to make payments above 3,000 rubles. Some terminals, however, have a separate configuration indicating the maximum payment amount in legacy M-STRIPE mode.
3. If in a regular card the ATC counter goes sequentially: 0001, 0002 and so on, then for the mobile wallet the MasterCard system has introduced the so-called CryptoATC. When intercepting commands, they appear as random values of 2 bytes A56D, F1A1and so on. In the process of detokenization, the MPS turns these meanings into sequential ones. However, even with jumps of 30–50–100 counter values, my transactions were not blocked.

Due to the new PSD2 requirements in Europe, Android limited the number of transactions on a locked phone to five (now this value is three or zero, depending on the country). This got me thinking: If MasterCard and Google don't check for ATC spikes by only recording five transactions, what is the probability of reproducing one of them successfully?

Let's use Bernoulli's formula, excellently drawn by Arkady Litvinenko specifically for such cases.

Bernoulli's formula performed by Arkady Litvinenko

With an entropy of 1000, if you make 50 attempts to pay in a supermarket, the probability of getting a random number out of five recorded is 14%. For 100 attempts - 26%. And if you have access to the Transaction Stream, each of these recorded transactions can be monetized, because an attacker is able to create an authorization request, where he himself will set both a random number and CVC3/ATC values.

Moreover, in the case of access to Transaction Stream and in the absence of protection against brute force of ATC/CVC3 pairs, if the attacker only has a token (16 digits of the virtual card and expiry date), he will need a maximum of 65,535 attempts to create and successfully authorize a fraudulent transaction .

If all the scammers need to do in this case is to be persistent, tapping the supermarket 50-100 times, each time expecting success, or sending authorization requests to the MasterCard MDES tokenization servers, then, alas, they are guaranteed success.

RESULTS​

I have discovered several ways to attack stolen mobile wallets if the device allows payment without unlocking the phone. I also found a new interesting attack on the EMV protocol - Cryptogram Confusion. It can be used to attack not only mobile wallets, but also chip/contactless cards.

I managed to make a payment using cloned Google Pay wallet transactions with a linked MasterCard, even with a limit of five attempts.

When it came to communicating with mobile vendors and MPS, the results were disappointing:

1. Google was notified of all the shortcomings in February. They reported that they are aware of the problems and plan to close the ability to make payments on the locked screen. This is implemented by creating a separate option in NFC settings after February 2021. Also in all regions, developers have reduced the number of transactions on a locked phone. The remaining vulnerabilities were ignored.
2. Apple, Samsung, MasterCard were notified in the spring of 2021, and it started... Apple stated that 15 bytes to activate NFC is sufficient protection for users. All mobile vendors raised their paws and, saying that they do not have the right to change the wallet code, asked permission to share their findings with the Ministry of Railways. After permissions were granted, my LinkedIn page was visited many times by respected people from all IPUs, but no one ever contacted me.

This summer, MasterCard not only closed the Card Brand Mixup Attack loophole from Swiss researchers, but also closed the Cryptogram Confusion loophole. I discovered this by accident only in October, while preparing for a performance. In addition, in many regions the MCC field has been added to the cryptogram, making MCC substitution impossible even during Transaction Stream Manipulation. The method of presenting ATC/AAC on locked Samsung phones has changed, which made me think about the patch. I was able to get the patch version from Samsung (MPBP 1.2.2 update, May 27, 2021).

Visa isn't too worried about still being able to make payments on stolen and dead Apple phones, and even less worried about transaction flow manipulation. They believe in machine learning, a risk-based model, and are most likely focused on business development or other exciting opportunities rather than the security of their clients.

Attacks that are still possible:

1. Visa + Apple Pay transport card - unlimited payments on a locked, dead or stolen device. Payments using Visa + Google Pay wallets are also still possible; nothing has changed since 2019.
2. MasterCard + Google Pay - cloning of transactions is possible when the stolen information is enough to make a certain number of payments.
3. Other variations of card + wallet - attacks are only possible when manipulating the Transaction Stream.

In order to truly protect against payment abuse on a locked phone, the best solution is to check the merchant category and amount with the CVR values:

• the user made a payment for $100, the phone was unlocked, the merchant was a supermarket, no problem;
• authorization for 0.00 or debit for a large amount, the phone is not unlocked, the merchant is transport, no problem either;
• authorization for 0.00, debit for a large amount, the phone is not unlocked, the merchant is a supermarket, this is already suspicious, and such transactions should be rejected.

What should issuing banks do? I have heard several times that during tokenized transactions, the bank may request additional information from the MPS to make decisions, in particular the EMV fields, which normally do not leave the tokenizer. How difficult it is to do this and how much it costs (all MPS services are provided by subscription), I cannot comment on.

What should clients do? Let's imagine this picture: you are the owner of a mobile wallet, you have lost your phone and have not blocked the default card or transport card (I know that transport cards are not used in Russia, but we are imagining). After some time, the attackers used one of the above techniques and withdrew $1,000 from your account. What happens next?

1. You call the bank, ask to block the card and begin proceedings.
2. After some time, the issuing bank reports that it has no information about the fraudulent nature of the transactions. From their side, everything looks harmless. Perhaps you disclosed your PIN code?
3. Attempts to communicate with mobile vendors (Apple, Samsung, Google) lead nowhere - they will claim that payments are only possible for limited categories of merchants and in limited amounts. Perhaps you disclosed your PIN code?

What can clients do in this case? Stop using the most unreliable products.

Over the past year, I have been able to confirm my suspicions - mobile wallet developers have made themselves comfortable by creating “the most secure forms of payment”, taking away the decision-making power of issuing banks during wallet issuance and transaction authorization. At the same time, they shrug their shoulders in the event of fraud or even the possibility of fraud, shifting responsibility to the Ministry of Railways.

(c) https://xakep.ru/2021/12/14/pay-systems-attacks/