Google Pay-Replay attack
Google Pay, “Won’t Fix (Intended Behavior)”: Replay attack.
July 24, 2018
Salvador Mendoza.
Interested in Reverse Engineering, Embedded Prototypes and #Payment Systems | Co-founder of @womenintechfund.
@Netxing
Intro
Google Pay is the new version of Android Pay. This application implements cloud-validated cryptograms to make NFC transactions. On March, I found an important issue in the application which could be exploitable for malicious users to intercept and make fraudulent transactions. The applied solution of the vendor, in this case, Google Pay, was that “my report has been closed without providing a fix.”
Vulnerability
NFC(Near Field Communication) protocol is the technology that Google Pay integrated to make digital payments. By default, the protocol has different layers of security to avoid or protect its customers against replay or downgrade attacks. However, the actual implementation of Google Pay does not apply this countermeasure.
When a person wants to make a NFC transaction with Google Pay, an attacker could intercept the NFC transaction. The malicious user can manipulate the intercepted transaction in different location and with different hardware as well. So, that intercepted transaction could be saved and replay it later with another device to make a payment, spending the money from the original Google Pay customer.
Google Pay Tokens
Each Google Pay transaction is unique. Meaning that every token id is unique as well. If a transaction is not completed in a real PoS or terminal, the token id will keep increasing anyway.
Example of a token incremental:
Token 1: 12 34 56 78 12 34 56 78 D2 40 32 01 48 54 00 00 03 71 6F
Token 2: 12 34 56 78 12 34 56 78 D2 40 32 01 48 54 00 00 04 14 1F
Important: If a token is not used in a real transaction, that token could be used later because it is not expired or disposed which means a malicious user could implement it with another device such as NFCopy.
The AIP
The Application Interchange Profile(82) is in charge to state which level of security the NFC transaction will be implemented to validate a transaction. Basically, the AIP is a tag in the APDU communication which tells the PoS what kind of security the mobile device supports in NFC transaction. This type of information is generated in the communication process between Google Pay and the PoS using APDUs.
The Issue
If an attacker intercepts a Google Pay transaction, he/she could be able to use a third-party application such as SwipeYours from Google Play store to generate a mag-stripe mode transaction. This Android app will generate a mag-stripe transaction(Visa MSD) by changing the AIP values in the NFC connection with the minimum level of security.
Because the intercepted Google Pay token implements a cloud-validated cryptogram and the EMV system accepts this type of data, the transaction can go through using this mechanism.
Hardware
How difficult is to design and make a tool that intercepted a Google Pay transaction and replay it? A malicious user can program an Arduino and a PN532 board to read the transaction and then emulate it in the terminal. The cost of this device is less than 10 dollars.
Damage Range
This issue in the payment network might affect different NFC wallets from different banks if they are applying the “Intended Behavior” methodology, and even worse, this could affect different countries as well.
Proof of Concept
In this PoC, I am running a Raspberry Pi Zero W with an Acr122u NFC reader which also works as emulator to behave as smart card after a Google Pay token is intercepted.
Timeline:
2018–03–17: Discovered
2018–04–10: Retest in different PoS
2018–04–21: Google Pay team notified
2018–04–21: Google received my bug report
2018–04–23: Bug accepted – Assigned Priority: 1 Severity: 2
2018–04–26: Google feedback, bug not qualified for reward
2018–07–06: Google feedback, “Won’t Fix (Intended Behavior)”
2018–07–24: Public report in tpx
