Hi, carders!
In today's article, we analyze popular myths and scenarios of fraud with contactless payment systems using the example of a real POS terminal, PayPass / payWave cards and phones with the Google Pay / Apple Pay function.
Topics covered:
Attention!
The article describes in detail a hypothetical fraud scheme, from beginning to end, through the eyes of a fraudster, in order to cover all aspects in which myths and misconceptions are cultivated. Despite the provocative title, the main conclusion of the article is that contactless payments are quite safe, and attacks on them are time consuming and unprofitable.
The materials in the article are presented for informational purposes only. All scenes of the demonstration of fraud are staged and performed with the consent of the persons participating in them. All the money written off from the cards was returned to their owners. Stealing money from cards is a criminal offense and is punishable by law.
How it works?
To begin with, consider the basic concepts: any movement of money using payment cards is possible only through intermediaries connected to the payment system, for example VISA or MasterCard. Unlike transfers between individuals, the withdrawal of money from the card is available only to a legal entity (merchant) that has an acquiring agreement with the bank.
Transaction stages when paying through a POS terminal
The illustration above shows the classic POS payment scheme. It is this sequence of actions that occurs when, after paying at the checkout, you are waiting for confirmation at the terminal.
Merchant - a person or organization that provides goods or services
Acquiring bank - a bank that provides the merchant with services for accepting payments through bank cards. This bank usually contains the merchant's current account, where the money debited from the card is credited.
Issuing bank - the bank that issued the card. It contains the account of the cardholder from whom the money is debited.
The International Payment System (MPS) is an international intermediary system between banks around the world, which allows banks to make settlements among themselves without concluding an agreement with each bank separately. All banks connected to the IPS agree to work according to the same rules, which greatly simplifies interaction. For example, Visa, MasterCard, UnionPay, American Express,MIR (no, MIR does not work abroad).
Cardholder - a person who has entered into a card service agreement with the issuing bank.
What is the difference between a regular card and Apple Pay or Google Pay?
The procedure for linking a bank card to Apple Pay or Google Pay, due to the incomprehensibility of the process, often gives rise to confusion even among IT professionals. I have heard many different myths about this technology.
Popular myths about Apple Pay
Linking a physical card to a "token" in the phone
Systems like Apple Pay are based on the EMV Payment Tokenization Specification. The procedure for linking a physical card and a phone with Apple Pay is not described publicly, so we will analyze the process based on known data:
When paying by phone, the POS-terminal sees a regular VISA or MasterCard card, and communicates with it in the same way as with a physical card. A virtual token card contains all the attributes of a regular card: PAN number, expiration date, and so on. In this case, the virtual card number and validity period differ from the attached original card.
Scenario 1 - regular POS terminal
Cheater armed with a POS terminal
The most popular plot of fraud is in the minds of ordinary people: a swindler with a terminal turned on cuddles up to them in the crowd and writes off money. We will try to reproduce this scenario in reality.
The conditions are as follows:
Entity
To begin with, we need a legal entity with a current account and connected acquiring. We, as real scammers, will not issue anything in our name, but will try to buy a ready-made legal entity. face on the site for the same scammers. To do this, let's look at the ads from the first page of Google on the request "buy ip" and "buy ooo".
Offers for the sale of shelf companies from fraudsters
The price of a company on the black market with a current account ranges from 20,000 to 300,000 rubles. I managed to find several offers of LLC with a POS terminal from 200 thousand rubles. Such companies are registered as dummies, and the buyer receives the entire package of documents, together with a "cash card" - this is a bank card tied to the settlement account of the dummy company. With such a card, a fraudster can cash out at an ATM.
Let's go steal money
So, the fraudster got a POS terminal and is ready to go to a crowded place to lean against the victims and steal money from their pockets. In our experiment, all victims were instructed in advance about our intentions, and all attempts to write off money were carried out with their consent. In cases where the subjects did not have their own contactless bank cards, they were asked to put our card in their wallet. Previously, the subjects found out exactly where and how they store their cards, so the fraudster knew in advance where the contactless card was in the bag / pocket.
Video: a scammer raged in a shopping center
In case of a successful write-off, the transaction was canceled through the terminal menu, and the money was returned to the account of the subjects. During the entire experiment, we tried to "steal" money from 20 subjects in the shopping center building and on the street. The test result is described below.
Problem: Limit on transactions without a PIN
The limit on the maximum transaction amount without PIN confirmation can be set both on the POS terminal itself (CVM Required Limit) and on the bank's side. In Russia, this limit is 1000 rubles.
UPD In the card settings, the authorization type Cardholder verification methods (CVMs) can be set in the form of a list. In this case, the contactless transaction will be processed for any amount without a PIN code.
Our fraudster decides to write off 999.99 rubles at a time. If a repeated attempt is requested to write off an amount below the limit in a short time period, you will also be asked to enter a PIN code and, in most cases, you will not be able to write off 999.99 rubles several times in a row. Therefore, the most optimal strategy will be no more than one write-off from one card.
POS terminal with the amount of 999.99
In Russia, the maximum withdrawal amount without a PIN code is 1000 rubles.
In fact, many write-offs with the amount of 999.99 rubles in a short period of time can trigger the anti-fraud system on the side of the acquiring bank, so this strategy is not optimal for a fraudster. So, in real life, he would have to choose more varied amounts, thereby reducing potential income.
By the way, many articles on this topic in Russian say that you can manually set your own limit on contactless transactions without a PIN code. I was unable to find such an option in the main Russian banks. Maybe you know about such a possibility? It's about contactless payments, not any chip & pin transactions.
Problem: Multiple cards in the wallet
This is an important point in this attack scenario, because in reality almost no one carries one single card in their pocket. In most cases, the card is stored in the wallet along with other contactless cards such as travel cards or other bank cards.
Card-swollen wallet
Specifically, my Igenico iWL250 terminal, when more than one card with a SAK indicating support for the 14443-4 protocol is found in the field of action, returns an error: "present one card".
But not all terminals do this. For example, VeriFone bank POS terminals choose a random card from several. Some terminals simply ignore all cards, if there is more than one, without displaying error messages.
An attempt was made to count multiple cards in a wallet. The POS terminal returns an error.
Anti-collision ISO 14443-3
Reading one particular card out of several is not an easy task at the physical level. To solve this problem, there is an anti-collision mechanism. It allows you to select one card if a response was received from several cards at once. This is the very first step in establishing communication with a contactless card in the ISO-14443A protocol. At this stage, the reader is not able to find out which of the presented cards is a bank card. The only option is to choose more or less similar to a bank card, based on the SAK (Select Acknowledge) response.
The meaning of the bits in the SAK response
For example, the Troika card (Mifare standard) used in Moscow public transport has the value SAK = 0x08 (b00001000), in which the sixth bit is zero. While all bank cards in SAK responses have the sixth bit equal to 1, which means support for the ISO 14443-4 protocol.
Therefore, all that the terminal can do when it detects several cards at the same time is to exclude cards that do not support ISO 14443-4, and select one of those similar to a bank card. By the way, support for the ISO 14443-4 protocol does not guarantee that this card will be a bank card, however, most likely, in the wallet of an ordinary person there will not be any other type of cards that support ISO 14443-4.
Block diagram of the anti-collision protocol
From personal experience: despite the presence of an anti-collision protocol, if there are at least three contactless cards in the wallet, it is EXTREMELY difficult to successfully read the required card. Most attempts end up with read errors. It is all the more difficult to do this on the run, clinging to other people's pockets and bags.
However, we will assume that our fraudster is very lucky and does not worry about this limitation.
Offline vs Online transactions
Scary news stories tell about scammers with POS terminals in subway cars, who cheat money out of your pockets right on the way. These stories do not mention where the fraudster got the mobile Internet from in the subway car. Perhaps his terminal supports offline transactions?
EMV specifications allow offline transactions. In this mode, debiting occurs without online confirmation from the issuing bank. This works, for example, on public transport in Moscow and St. Petersburg. In order not to queue at the entrance to the bus, while the terminal completes the online confirmation, they let you through immediately, without checking whether you have enough money in your account to pay for the fare. At the end of the day, when the Internet appears on the terminal, the signed transactions are sent to the issuing bank. If it turns out that at this moment you do not have money to pay for travel, the card will be added to the stop list at all terminals in the city. The debt can be repaid through your personal account using the card number. Read more about paying the bus fare in St. Petersburg.
Personally, I was not able to get a POS terminal that supports this function, therefore, in the scenario with a regular "civil" POS terminal, we will not consider the possibility of offline charges. This does not change anything, except that the attacker will need the Internet at the terminal, so an attack, for example, in the subway, becomes much more complicated.
There are terminal models that support Wi-Fi, and in theory, our fraudster could use Wi-Fi in the metro, having previously taken care of buying ad-free access for the MAC address of his POS terminal, so that there is no need to authenticate through the captive portal, since POS- the terminal cannot do this.
Calculating the profit
In our scenario, the cost of the attack was 100,000 rubles. This means that in order to at least return the investment, our hero needs to perform at least 100 transactions of 1 thousand rubles each. Imagine that he was agile enough and ran around the city all day, clinging to everyone in a row, so that by the end he made 120 successful write-offs. We will not take into account the commission for acquiring (on average 2%), commission for cashing out (4-10%) and other commissions.
Can he successfully cash out using a card linked to his current account?
In reality, not everything is so simple. The money will be credited to the fraudster's account only in a few days! During this time, our fraudster should hope that none of the one hundred and twenty victims will dispute the transaction, which is extremely unlikely. Therefore, in reality, the fraudster's account will be blocked even before the money is credited to it.
Output
The cost of an attack in our scenario is 100,000 rubles. In reality, it will be several times higher, so the fraudster will need much more effort in order to make a profit.
In our scenario, the fraudster always charges 999.99 rubles, which, most likely, will trigger the anti-fraud system on the acquiring bank's side. In reality, the fraudster will need to write off smaller amounts.
To at least recoup the investment, the fraudster will need to process several hundred victims. If even a dozen of them contact the issuing bank and dispute the transaction, the fraudster's account will most likely be blocked. A scenario in which the acquiring bank is colluding with a fraudster is unlikely, because the license to work with the IPS costs much more than any potential profits from this type of fraud.
Of the 20 subjects, only three managed to write off money from the card, which is 15% of the success of all attempts. These were those artificial cases when there was one single card in the pocket. In cases with a wallet and several cards, the terminal returned an error. In a scenario with a terminal that uses a modified firmware and implements an anti-collision mechanism, the percentage of successful write-offs may be higher. However, even in the case of using ant collisions, in real conditions on the run, it is so difficult to count one card out of several that a successful write-off in such conditions can be considered luck. In reality, the share of successful write-offs will hardly exceed 10% of the number of attempts.
Scenario 2 - angry POS terminal
Let's say our fraudster works at the checkout in a store or as a courier with a mobile POS terminal. In this case, he has the opportunity to fetch the card data, which, in some case, may be enough to pay on the Internet.
First, let's figure out exactly how a contactless transaction looks like, and what data the card exchanges with a POS terminal. Since we are too lazy to read thousands of pages of EMV Contactless Specifications documentation, we will simply intercept the exchange at the physical level using the HydraNFC sniffer.
There is some difference between the EMV specification for MasterCard PayPass and Visa payWave. This is the difference in the format of the signature and some data. But for us, this is irrelevant.
NFC Sniffer
HydraNFC is a fully open source stand-alone ISO-14443A sniffer that saves intercepted APDU commands to an SD card. The sniffer antenna is placed between the terminal and the card, and passively captures all transmitted information.
→ Website about HydraBus and the HydraNFC shield
→ Firmware sources
Demonstration of interception of exchange between a POS terminal and a phone with Apple Pay
Looking ahead, it is necessary to say that at this level, payment by phone and a regular plastic card does not differ. For a POS terminal, this is a regular VISA card. However, paying by phone is much safer than using a physical card, and we'll discuss why later.
Parsing the EMV protocol
Here's what the recorded dump looks like when paying for a chocolate bar and a bottle of water with a total cost of 142.98 rubles using Apple Pay:
Raw data obtained from the sniffer (reveal spoiler)
Let's analyze each line separately from the intercepted dump.
R>>> — data transmitted by the POS terminal
T>>> — data transmitted by the card (in our case, a phone with Apple Pay)
14443-A Select
At the beginning of the exchange, the terminal establishes a link-level connection with the card. For those who are familiar with networks and the OSI model, it will be convenient to represent this as the L2 layer, and the UID (Unique Identifier) of the map as the MAC address of the node.
An important difference between a regular payment card and Apple Pay is that the card is always available for reading and does not allow you to control the reading process in any way. It can be read out of control through clothing, while the phone, once in the reader's field of action, prompts the user to activate the virtual card. The phone doesn't transmit any data until the user confirms it, and the reader doesn't even know that a virtual card is nearby.
The terminal constantly sends the 0x52 Wake-up (WUPA) command, and as soon as the map appears in the field of action, it responds with the Answer To Request type A (ATQA) command, in our case it is 0x04 0x00. ATQA's response may vary depending on the chip manufacturer.
After receiving the ATQA response, the terminal starts the collision detection procedure to determine if there is more than one card in the action field. The 0x93 0x20 Select cascade level 1 (SEL CL1) command asks all maps in the action field to provide the first part of their UIDS.
The card responds with 0x08 0xFE 0xE4 0xEC 0xFE, the first four bytes are the UID of the Apple Pay virtual card and the 0xFE Bit Count Check (BCC) checksum at the end.
After receiving the card IDs, the reader accesses a specific card with the command 0x93 0x70 (SELECT). The command is followed by the card UID 0x08 0xfe 0xe4 0xec + 0xfe BCC + 0xdd 0x6e CRC16.
The card responds with 0x20 Select Recognition (SAK) + 0xfc 0x70 CRC16.
If multiple SAK responses are received at this step, the reader can reduce the length of the UID in the SELECT command until a single card responds. However, as shown above, some POS terminals refuse to continue if collisions are detected at this stage, i.e. the presence of several cards at the same time.
The reader sends the command 0x50 0x00 HALT + 0x57 0xcd CRC16. This is the communication termination command.
Then the procedure is repeated again, the reader wakes up the map again (WUPA), but without checking for collisions, SELECT is immediately performed. I don't know why this is done, but it may be a more reliable way to detect collisions.
The second time, the reader already sends the command 0xE0 0x80 Request Answer to Select (RATS) + 0x31 0x73 CRC16.
The card responds 0x05 0x78 0x80 0x70 0x02 Answer to select response (ATS) + 0xA5 0x46 CRC16.
Answer to select - the answer is similar to the Answer To Reset (ATR) for contact cards. It contains information about the maximum frame size and link layer parameters.
At this stage, the "channel" layer is completed, then the exchange begins on a higher-level protocol, depending on the application contained on the card. The SELECT operation is the same for all contactless cards of the ISO 14443A standard, including NFC tags, public transport tickets, etc.
Request for available apps - SELECT PPSE
Official Description: EMV Contactless Specifications-PPSE and Application Management for Secure Element
Communication with an EMV card always starts with reading the PPSE (Payment System Environment). The terminal asks the card what payment applications it has.
Most often, this is a single application, as in our example - VISA. However, there are cards with multiple payment applications. For example, there are special domestic MIR cards with two payment applications inside. Since the MIR payment system does not work abroad, a second payment application is integrated into the card, which is essentially a second card. This can be an application of the JCB or UnionPay payment system. These cards are called co-paging cards.
APDU-SELECT PPSE command
Response to SELECT PPSE
For convenience, we will analyze the response using an online TVL parser. iso8583.info/lib/EMV/TLVs. Same response processed by the parser:
Of all this, we are only interested in the payment application ID (AID). In this case, it is the value A0000000031010, meaning Visa International.
AID is marked with a 4F marker. The second bit after the token is the length of the data it contains. Although the AID length can vary from 5 to 16 bytes, in most cases it is equal to 7 bytes.
Large AID List: eftlab.co.uk/knowledge-base/211-emv-aid-rid-pix
Some popular AIDS:
Application Priority Indicator-indicates the priority of payment applications. For example, in co-branded MIR cards that have multiple payment apps inside, this field indicates which of the two apps takes priority. Since we only have one Visa International app, it points to it, and there is no priority.
Launching the payment app-SELECT AID
After selecting the appropriate payment application, the terminal launches it.
PDOL (Processing Options Data Object List)
Parsing the response using the parser
In response to launching the payment application, the card reports a set of parameters that it expects to receive from the terminal - PDOL (Processing Options Data Object List). The terminal must respond in strict accordance with this sequence.
The PDOL may differ for different cards. The total number of PDOL parameters is several dozen. The full list of PDOL parameters can be found here.
Let's analyze PDOL more closely. The length specified after the token is strictly the expected length of the response from the terminal to this request. An empty response is filled with zeros up to the required length.
Parsing a PDOL request:
Up to this point, all transmitted data is identical for any transactions on this card.
Debit request - GET PROCESSING OPTIONS
This response clearly shows how the terminal located in Russia requests a debit from the card in the amount of 142.98 rubles. Pay attention to the random number at the end (E0110103). This is the parameter 9F37 Unpredictable Number. This is the first mention of cryptography. In the future, the card will have to sign this number together with the transaction data with a cryptographic signature. This gives the terminal control over the validity of the card signature and protects it from replay attacks.
The card response to GET PROCESSING OPTIONS
This response contains VISA-specific data fields, so I used a parser with VISA Contactless Payment Specification (VCSP) support.
Application Interchange Profile (AIP) - contains information about the payment application parameters. In our case, the AIP is 00 40. Consider the values of this parameter from EMV 4.3 Book 3.
In our case, one bit is set in the second byte, which, according to this table, is Reserved For Future Use (RFU). I do not know what this means, and what meaning Apple Pay puts in it.
The AIP contains important information about supported payment authentication methods (SDA, CDA,DDA). I don't understand why all these flags are zero in my case.
Application File Locator (AFL) - contains information about the location of records (SFI range of records) in a specific AID. Based on this response, the terminal will generate a READ RECORD request.
Let's analyze the AFL response in more detail:
Short File Identifier (SFI) is 0x18. This parameter is encoded with five bits instead of eight. Accordingly, the value 0x18 (b00011000) is converted to b00000011, and we get 0x3.
First record = 1
Last record = 1
That is, in "folder" # 3 there are records from 1 to 1, that is, one record.
Application Transaction Counter (ATC) - an incremental transaction counter that is incremented by one each time you request GET PROCESSING OPTIONS. If the value is set to 0xFFFF or 0x7FFF, the payment application will be permanently blocked. I believe that this is done to protect the card's private key from brute-forcing. In our case, it can be seen that this iPhone with Apple Pay has already been used for payment 518 (0x206) times.
Application Cryptogram (AC) - a cryptographic signature that is calculated by the card using its private key. This signature is transmitted along with other data to the issuing bank, and on its basis the authenticity of the transaction is verified. Since the private key of the card cannot be extracted from the card (by any available means), this eliminates the possibility of copying the card.
Issuer Application Data (IAD) - Contains proprietary data specific to VISA. I haven't mastered the analysis of this structure, please help me.
Card Transaction Qualifiers (CTQ) - a VISA-specific list of card-supported specifications. For example, whether this contactless card can be used for ATM operations or not, and what confirmations will be required.
Track 2 Equivalent Data - this field contains the card number and expiration date. This information will be discussed in more detail later.
Form Facto Indicator (FFI) - VISA-specific field. Describes the form factor and characteristics of the payment device. In our case, you can see that this is a mobile phone.
Cryptogram Information Data (CID) - I haven't mastered the analysis of this structure, please help me.
READ DATA RECORD request
The terminal sends a request to read records received from AFL:
In this case, starting from byte 0x1C should be read as two values, where the first five bits are 0x18 (b000011), and make up SFI, and the next three bits are 0x04 (d100), and make up the record number.
Response to READ RECORD
Application Usage Control (AUC) - determines whether it is allowed to pay with a card abroad, and the types of operations allowed.
9F19 - something incomprehensible, apparently-outdated Dynamic Data Authentication Data Object List (DDOL)
EMV Tokenization, Payment Account Reference (PAR) - a parameter specific to tokenized (virtual) cards. I haven't mastered the analysis of this structure, please help me.
What can be extracted from an intercepted transaction?
We analyzed one specific example of intercepted traffic of an Apple Pay contactless transaction with a linked VISA card. The MasterCard protocol is slightly different, but generally similar. The analysis shows that the transaction is protected by a cryptographic signature, and the protocol is protected from replay attacks. There is an outdated contactless payment protocol in Magnetic Stripe (MSD) mode, which is much worse protected from replay attacks, but I will not analyze it in this article, because, as far as I know, it is almost not supported in the CIS, I may be mistaken.
From the intercepted data, you can extract the card number (PAN) and expiration date (expiration date).)
As you can see, you can extract the full card number and expiration date from the intercepted traffic. Although CVV is not included in this dump, this data is already sufficient for payment in some online stores. In the case of a regular physical plastic card, the intercepted data will contain the same PAN and expiration date that is stamped on the card itself!
Online payment without CVV (CNP, MO/TO)
The dump above shows not only my full card number, but also the expiration date. This data is quite enough to pay in some stores on the Internet. Well, let's try it.
The form for adding a card to Amazon does not require a CVV
If it were a physical card number, the money could indeed be stolen, but the Apple Pay token data can ONLY be used for Client Present (CP) operations, when the card signs the transaction with a cryptographic signature. This data cannot be used for online payments and other Card not present (CNP) transactions, i.e. by phone or email. That's it!
Anyone who wants to make sure of this, I inform you that the details from the Apple Pay dump intercepted above are currently up-to-date and linked to a valid card that has money on it. At the time of writing, this is $ 100. I suggest you try to steal them
Why Apple Pay is safer than a regular card
Apple Pay vs regular contactless card
Conclusion
Contactless payment systems are fairly well protected. Despite the theoretical possibility of fraud, in practice it is unprofitable and extremely difficult to implement. There is no reason to be afraid of contactless cards or try to break the antenna in the card.
All other things being equal, Apple Pay will be safer than a regular plastic card. For greater security, you can block CNP transactions (online payment) using the main contactless card, and get a second card only for online payment.
I'm not saying goodbye!
(c) https://habr.com/ru/articles/422551/
In today's article, we analyze popular myths and scenarios of fraud with contactless payment systems using the example of a real POS terminal, PayPass / payWave cards and phones with the Google Pay / Apple Pay function.
Topics covered:
- Is it REALLY possible to steal money by leaning the POS terminal against your pocket? - we will try to completely reproduce this fraud scenario from start to finish, using a real POS terminal and payment cards in real conditions.
- What's the difference between physical and virtual Apple Pay cards? - how the physical card and Apple Pay token are linked, and why Apple Pay is many times safer than a regular card.
- We use a hardware NFC sniffer (ISO 14443A) - we use the HydraNFC device to intercept data between the POS terminal and the card. Let's consider what confidential data can be extracted from the intercepted traffic.
- We analyze the EMV protocol - what data is exchanged between the card and the POS terminal, the request format used, the mechanisms of protection against fraud and replay attacks.
- We will investigate operations without a card (CNP, MO / TO) - in which cases it is actually (!) It is possible to steal money from a card, having only the details read out contactless, and in which cases it is impossible.
Attention!
The article describes in detail a hypothetical fraud scheme, from beginning to end, through the eyes of a fraudster, in order to cover all aspects in which myths and misconceptions are cultivated. Despite the provocative title, the main conclusion of the article is that contactless payments are quite safe, and attacks on them are time consuming and unprofitable.
The materials in the article are presented for informational purposes only. All scenes of the demonstration of fraud are staged and performed with the consent of the persons participating in them. All the money written off from the cards was returned to their owners. Stealing money from cards is a criminal offense and is punishable by law.
How it works?
To begin with, consider the basic concepts: any movement of money using payment cards is possible only through intermediaries connected to the payment system, for example VISA or MasterCard. Unlike transfers between individuals, the withdrawal of money from the card is available only to a legal entity (merchant) that has an acquiring agreement with the bank.
Transaction stages when paying through a POS terminal
The illustration above shows the classic POS payment scheme. It is this sequence of actions that occurs when, after paying at the checkout, you are waiting for confirmation at the terminal.
- The buyer applies / swipes / inserts the card into the POS terminal;
- The POS terminal transmits data to the acquiring bank via the Internet;
- The acquiring bank, through the international payment system (MPS), contacts the issuing bank and asks whether a particular cardholder can pay for the purchase;
- The issuing bank confirms or declines the purchase, after which a slip (second check) is printed.
Merchant - a person or organization that provides goods or services
Acquiring bank - a bank that provides the merchant with services for accepting payments through bank cards. This bank usually contains the merchant's current account, where the money debited from the card is credited.
Issuing bank - the bank that issued the card. It contains the account of the cardholder from whom the money is debited.
The International Payment System (MPS) is an international intermediary system between banks around the world, which allows banks to make settlements among themselves without concluding an agreement with each bank separately. All banks connected to the IPS agree to work according to the same rules, which greatly simplifies interaction. For example, Visa, MasterCard, UnionPay, American Express,
Cardholder - a person who has entered into a card service agreement with the issuing bank.
What is the difference between a regular card and Apple Pay or Google Pay?
The procedure for linking a bank card to Apple Pay or Google Pay, due to the incomprehensibility of the process, often gives rise to confusion even among IT professionals. I have heard many different myths about this technology.
Popular myths about Apple Pay
- The card is copied to the phone
- This is not the case, the microprocessor card contains a protected memory area with cryptographic information that cannot be removed after the card is issued. Because of this, the chip card cannot be copied, in any way, at all. In fairness, it must be said that such attacks are possible, but their cost exceeds the total amount of money that most of the readers of this article will spend in their entire lives.
- The phone connects to the Internet every time you pay
- Google Pay / Apple Pay does not connect to the Internet when paying through a POS terminal. All the information you need is stored locally on your phone.
- A new card number (PAN) is generated for each payment
- It may seem so if you read Apple's press releases about Apple Pay technology. But this is an erroneous interpretation of the concept of a token. In fact, the details of the virtual card remain unchanged for a long time, you can check this by the last digits of the card number in the slip (bank check) when paying for purchases.
- Additional fees apply when paying with Apple Pay / Google Pay
- This is not the case, you will pay exactly what is indicated on the price tag, and according to the terms of your agreement with the issuing bank, whose card you linked.
- Money can be charged twice
- This myth applies not only to Google Pay / Apple Pay, but also to regular bank cards. I believe that it appeared due to the payment systems for public transport, in which the terminal deducts money from the ticket every time it is presented, so you can write off funds two or more times if the card is carelessly presented. In the case of POS terminals, this risk does not exist, since the terminal stops exchanging with the card as soon as it receives the required data.
Linking a physical card to a "token" in the phone
Systems like Apple Pay are based on the EMV Payment Tokenization Specification. The procedure for linking a physical card and a phone with Apple Pay is not described publicly, so we will analyze the process based on known data:
- Provider (Google, Apple, Samsung) receives card information;
- Through the IPS, the supplier requests whether this card (this issuing bank) supports EMV Tokenization;
- On the MPS side, a virtual card (token) is generated, which is uploaded to the secure storage in the phone. I do not know where exactly the private key from the virtual card is generated, whether it is transmitted over the Internet or generated locally on the phone, in this case it does not matter.
- A generated virtual token card appears on the phone, the transactions on which the issuing bank interprets as transactions on the first physical card. If a physical card is blocked, the token is also blocked.
When paying by phone, the POS-terminal sees a regular VISA or MasterCard card, and communicates with it in the same way as with a physical card. A virtual token card contains all the attributes of a regular card: PAN number, expiration date, and so on. In this case, the virtual card number and validity period differ from the attached original card.
Scenario 1 - regular POS terminal
Cheater armed with a POS terminal
The most popular plot of fraud is in the minds of ordinary people: a swindler with a terminal turned on cuddles up to them in the crowd and writes off money. We will try to reproduce this scenario in reality.
The conditions are as follows:
- The fraudster has a completely working ordinary POS terminal connected to the acquiring bank, the same as in stores and couriers. Terminal firmware has not been modified. In our case - Ingenico iWL250. It is a portable POS terminal with a GPRS modem that supports contactless payment, is battery operated and fully mobile.
- The fraudster does not use additional technical means, only a POS terminal
- The debited funds are credited to the fraudster's current account, according to all the rules of banking systems
Entity
To begin with, we need a legal entity with a current account and connected acquiring. We, as real scammers, will not issue anything in our name, but will try to buy a ready-made legal entity. face on the site for the same scammers. To do this, let's look at the ads from the first page of Google on the request "buy ip" and "buy ooo".
Offers for the sale of shelf companies from fraudsters
The price of a company on the black market with a current account ranges from 20,000 to 300,000 rubles. I managed to find several offers of LLC with a POS terminal from 200 thousand rubles. Such companies are registered as dummies, and the buyer receives the entire package of documents, together with a "cash card" - this is a bank card tied to the settlement account of the dummy company. With such a card, a fraudster can cash out at an ATM.
Let's go steal money
So, the fraudster got a POS terminal and is ready to go to a crowded place to lean against the victims and steal money from their pockets. In our experiment, all victims were instructed in advance about our intentions, and all attempts to write off money were carried out with their consent. In cases where the subjects did not have their own contactless bank cards, they were asked to put our card in their wallet. Previously, the subjects found out exactly where and how they store their cards, so the fraudster knew in advance where the contactless card was in the bag / pocket.
Video: a scammer raged in a shopping center
In case of a successful write-off, the transaction was canceled through the terminal menu, and the money was returned to the account of the subjects. During the entire experiment, we tried to "steal" money from 20 subjects in the shopping center building and on the street. The test result is described below.
Problem: Limit on transactions without a PIN
The limit on the maximum transaction amount without PIN confirmation can be set both on the POS terminal itself (CVM Required Limit) and on the bank's side. In Russia, this limit is 1000 rubles.
UPD In the card settings, the authorization type Cardholder verification methods (CVMs) can be set in the form of a list. In this case, the contactless transaction will be processed for any amount without a PIN code.
Our fraudster decides to write off 999.99 rubles at a time. If a repeated attempt is requested to write off an amount below the limit in a short time period, you will also be asked to enter a PIN code and, in most cases, you will not be able to write off 999.99 rubles several times in a row. Therefore, the most optimal strategy will be no more than one write-off from one card.
POS terminal with the amount of 999.99
In Russia, the maximum withdrawal amount without a PIN code is 1000 rubles.
In fact, many write-offs with the amount of 999.99 rubles in a short period of time can trigger the anti-fraud system on the side of the acquiring bank, so this strategy is not optimal for a fraudster. So, in real life, he would have to choose more varied amounts, thereby reducing potential income.
By the way, many articles on this topic in Russian say that you can manually set your own limit on contactless transactions without a PIN code. I was unable to find such an option in the main Russian banks. Maybe you know about such a possibility? It's about contactless payments, not any chip & pin transactions.
Problem: Multiple cards in the wallet
This is an important point in this attack scenario, because in reality almost no one carries one single card in their pocket. In most cases, the card is stored in the wallet along with other contactless cards such as travel cards or other bank cards.
Card-swollen wallet
Specifically, my Igenico iWL250 terminal, when more than one card with a SAK indicating support for the 14443-4 protocol is found in the field of action, returns an error: "present one card".
But not all terminals do this. For example, VeriFone bank POS terminals choose a random card from several. Some terminals simply ignore all cards, if there is more than one, without displaying error messages.
An attempt was made to count multiple cards in a wallet. The POS terminal returns an error.
Anti-collision ISO 14443-3
Reading one particular card out of several is not an easy task at the physical level. To solve this problem, there is an anti-collision mechanism. It allows you to select one card if a response was received from several cards at once. This is the very first step in establishing communication with a contactless card in the ISO-14443A protocol. At this stage, the reader is not able to find out which of the presented cards is a bank card. The only option is to choose more or less similar to a bank card, based on the SAK (Select Acknowledge) response.
The meaning of the bits in the SAK response
For example, the Troika card (Mifare standard) used in Moscow public transport has the value SAK = 0x08 (b00001000), in which the sixth bit is zero. While all bank cards in SAK responses have the sixth bit equal to 1, which means support for the ISO 14443-4 protocol.
Therefore, all that the terminal can do when it detects several cards at the same time is to exclude cards that do not support ISO 14443-4, and select one of those similar to a bank card. By the way, support for the ISO 14443-4 protocol does not guarantee that this card will be a bank card, however, most likely, in the wallet of an ordinary person there will not be any other type of cards that support ISO 14443-4.
Block diagram of the anti-collision protocol
From personal experience: despite the presence of an anti-collision protocol, if there are at least three contactless cards in the wallet, it is EXTREMELY difficult to successfully read the required card. Most attempts end up with read errors. It is all the more difficult to do this on the run, clinging to other people's pockets and bags.
However, we will assume that our fraudster is very lucky and does not worry about this limitation.
Offline vs Online transactions
Scary news stories tell about scammers with POS terminals in subway cars, who cheat money out of your pockets right on the way. These stories do not mention where the fraudster got the mobile Internet from in the subway car. Perhaps his terminal supports offline transactions?
EMV specifications allow offline transactions. In this mode, debiting occurs without online confirmation from the issuing bank. This works, for example, on public transport in Moscow and St. Petersburg. In order not to queue at the entrance to the bus, while the terminal completes the online confirmation, they let you through immediately, without checking whether you have enough money in your account to pay for the fare. At the end of the day, when the Internet appears on the terminal, the signed transactions are sent to the issuing bank. If it turns out that at this moment you do not have money to pay for travel, the card will be added to the stop list at all terminals in the city. The debt can be repaid through your personal account using the card number. Read more about paying the bus fare in St. Petersburg.
Personally, I was not able to get a POS terminal that supports this function, therefore, in the scenario with a regular "civil" POS terminal, we will not consider the possibility of offline charges. This does not change anything, except that the attacker will need the Internet at the terminal, so an attack, for example, in the subway, becomes much more complicated.
There are terminal models that support Wi-Fi, and in theory, our fraudster could use Wi-Fi in the metro, having previously taken care of buying ad-free access for the MAC address of his POS terminal, so that there is no need to authenticate through the captive portal, since POS- the terminal cannot do this.
Calculating the profit
In our scenario, the cost of the attack was 100,000 rubles. This means that in order to at least return the investment, our hero needs to perform at least 100 transactions of 1 thousand rubles each. Imagine that he was agile enough and ran around the city all day, clinging to everyone in a row, so that by the end he made 120 successful write-offs. We will not take into account the commission for acquiring (on average 2%), commission for cashing out (4-10%) and other commissions.
Can he successfully cash out using a card linked to his current account?
In reality, not everything is so simple. The money will be credited to the fraudster's account only in a few days! During this time, our fraudster should hope that none of the one hundred and twenty victims will dispute the transaction, which is extremely unlikely. Therefore, in reality, the fraudster's account will be blocked even before the money is credited to it.
Output
The cost of an attack in our scenario is 100,000 rubles. In reality, it will be several times higher, so the fraudster will need much more effort in order to make a profit.
In our scenario, the fraudster always charges 999.99 rubles, which, most likely, will trigger the anti-fraud system on the acquiring bank's side. In reality, the fraudster will need to write off smaller amounts.
To at least recoup the investment, the fraudster will need to process several hundred victims. If even a dozen of them contact the issuing bank and dispute the transaction, the fraudster's account will most likely be blocked. A scenario in which the acquiring bank is colluding with a fraudster is unlikely, because the license to work with the IPS costs much more than any potential profits from this type of fraud.
Of the 20 subjects, only three managed to write off money from the card, which is 15% of the success of all attempts. These were those artificial cases when there was one single card in the pocket. In cases with a wallet and several cards, the terminal returned an error. In a scenario with a terminal that uses a modified firmware and implements an anti-collision mechanism, the percentage of successful write-offs may be higher. However, even in the case of using ant collisions, in real conditions on the run, it is so difficult to count one card out of several that a successful write-off in such conditions can be considered luck. In reality, the share of successful write-offs will hardly exceed 10% of the number of attempts.
Scenario 2 - angry POS terminal
Let's say our fraudster works at the checkout in a store or as a courier with a mobile POS terminal. In this case, he has the opportunity to fetch the card data, which, in some case, may be enough to pay on the Internet.
First, let's figure out exactly how a contactless transaction looks like, and what data the card exchanges with a POS terminal. Since we are too lazy to read thousands of pages of EMV Contactless Specifications documentation, we will simply intercept the exchange at the physical level using the HydraNFC sniffer.
There is some difference between the EMV specification for MasterCard PayPass and Visa payWave. This is the difference in the format of the signature and some data. But for us, this is irrelevant.
NFC Sniffer
HydraNFC is a fully open source stand-alone ISO-14443A sniffer that saves intercepted APDU commands to an SD card. The sniffer antenna is placed between the terminal and the card, and passively captures all transmitted information.
→ Website about HydraBus and the HydraNFC shield
→ Firmware sources
Demonstration of interception of exchange between a POS terminal and a phone with Apple Pay
Looking ahead, it is necessary to say that at this level, payment by phone and a regular plastic card does not differ. For a POS terminal, this is a regular VISA card. However, paying by phone is much safer than using a physical card, and we'll discuss why later.
Parsing the EMV protocol
Here's what the recorded dump looks like when paying for a chocolate bar and a bottle of water with a total cost of 142.98 rubles using Apple Pay:
Raw data obtained from the sniffer (reveal spoiler)
Let's analyze each line separately from the intercepted dump.
R>>> — data transmitted by the POS terminal
T>>> — data transmitted by the card (in our case, a phone with Apple Pay)
14443-A Select
At the beginning of the exchange, the terminal establishes a link-level connection with the card. For those who are familiar with networks and the OSI model, it will be convenient to represent this as the L2 layer, and the UID (Unique Identifier) of the map as the MAC address of the node.
An important difference between a regular payment card and Apple Pay is that the card is always available for reading and does not allow you to control the reading process in any way. It can be read out of control through clothing, while the phone, once in the reader's field of action, prompts the user to activate the virtual card. The phone doesn't transmit any data until the user confirms it, and the reader doesn't even know that a virtual card is nearby.
Code:
R>> 52 // WUPA (wake up)
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
T<< 04 00 // ATQA (Answer To Request type A)
R>> 93 20 // Select cascade 1 (Anti Collision CL1 SEL)
T<< 08 fe e4 ec fe // UID (4 bytes) + BCC (Bit Count Check)
R>> 93 70 08 fe e4 ec fe dd 6e // SEL (select tag 0x9370) + UID + CRC16
T<< 20 fc 70 // SAK (Select Acknowledge 0x20) + CRC16
R>> 50 00 57 cd // HALT (Disable communication 0x5000) + CRC16
R>> 26 // REQA
R>> 52 // WUPA
T<< 04 00 // ATQA
R>> 93 70 08 fe e4 ec fe dd 6e // SELECT
T<< 20 fc 70 // SAKThe terminal constantly sends the 0x52 Wake-up (WUPA) command, and as soon as the map appears in the field of action, it responds with the Answer To Request type A (ATQA) command, in our case it is 0x04 0x00. ATQA's response may vary depending on the chip manufacturer.
After receiving the ATQA response, the terminal starts the collision detection procedure to determine if there is more than one card in the action field. The 0x93 0x20 Select cascade level 1 (SEL CL1) command asks all maps in the action field to provide the first part of their UIDS.
The card responds with 0x08 0xFE 0xE4 0xEC 0xFE, the first four bytes are the UID of the Apple Pay virtual card and the 0xFE Bit Count Check (BCC) checksum at the end.
After receiving the card IDs, the reader accesses a specific card with the command 0x93 0x70 (SELECT). The command is followed by the card UID 0x08 0xfe 0xe4 0xec + 0xfe BCC + 0xdd 0x6e CRC16.
The card responds with 0x20 Select Recognition (SAK) + 0xfc 0x70 CRC16.
If multiple SAK responses are received at this step, the reader can reduce the length of the UID in the SELECT command until a single card responds. However, as shown above, some POS terminals refuse to continue if collisions are detected at this stage, i.e. the presence of several cards at the same time.
The reader sends the command 0x50 0x00 HALT + 0x57 0xcd CRC16. This is the communication termination command.
Then the procedure is repeated again, the reader wakes up the map again (WUPA), but without checking for collisions, SELECT is immediately performed. I don't know why this is done, but it may be a more reliable way to detect collisions.
The second time, the reader already sends the command 0xE0 0x80 Request Answer to Select (RATS) + 0x31 0x73 CRC16.
The card responds 0x05 0x78 0x80 0x70 0x02 Answer to select response (ATS) + 0xA5 0x46 CRC16.
Answer to select - the answer is similar to the Answer To Reset (ATR) for contact cards. It contains information about the maximum frame size and link layer parameters.
At this stage, the "channel" layer is completed, then the exchange begins on a higher-level protocol, depending on the application contained on the card. The SELECT operation is the same for all contactless cards of the ISO 14443A standard, including NFC tags, public transport tickets, etc.
Request for available apps - SELECT PPSE
Official Description: EMV Contactless Specifications-PPSE and Application Management for Secure Element
Communication with an EMV card always starts with reading the PPSE (Payment System Environment). The terminal asks the card what payment applications it has.
Most often, this is a single application, as in our example - VISA. However, there are cards with multiple payment applications. For example, there are special domestic MIR cards with two payment applications inside. Since the MIR payment system does not work abroad, a second payment application is integrated into the card, which is essentially a second card. This can be an application of the JCB or UnionPay payment system. These cards are called co-paging cards.
APDU-SELECT PPSE command
Code:
'00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00'
00 A4 04 00 / / select command
0E / / length of command data (14 bytes)
32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 // command data 2PAY.SYS. DDF01
00 // terminating tokenResponse to SELECT PPSE
Code:
'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 03 10 10 87 01 01 90 00'For convenience, we will analyze the response using an online TVL parser. iso8583.info/lib/EMV/TLVs. Same response processed by the parser:
Of all this, we are only interested in the payment application ID (AID). In this case, it is the value A0000000031010, meaning Visa International.
AID is marked with a 4F marker. The second bit after the token is the length of the data it contains. Although the AID length can vary from 5 to 16 bytes, in most cases it is equal to 7 bytes.
Large AID List: eftlab.co.uk/knowledge-base/211-emv-aid-rid-pix
Some popular AIDS:
Code:
A0000000031010 Visa International
A0000000032020 Visa International
A0000000041010 Mastercard International
A0000000043060 Mastercard International United States Maestro (Debit)Application Priority Indicator-indicates the priority of payment applications. For example, in co-branded MIR cards that have multiple payment apps inside, this field indicates which of the two apps takes priority. Since we only have one Visa International app, it points to it, and there is no priority.
Launching the payment app-SELECT AID
Code:
'00 A4 04 00 07 A0 00 00 00 03 10 10'
00 A4 04 00 // select command
07 / / length of command data (7 bytes)
A0 00 00 00 03 10 10 // AID Visa InternationalAfter selecting the appropriate payment application, the terminal launches it.
PDOL (Processing Options Data Object List)
Code:
'6f 31 84 07 a0 00 00 00 03 10 10 a5 26 9f 38 18 9f 66 04 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04 bf 0c 08 9f 5a 05 60 08 40 06 43 90 00'Parsing the response using the parser
In response to launching the payment application, the card reports a set of parameters that it expects to receive from the terminal - PDOL (Processing Options Data Object List). The terminal must respond in strict accordance with this sequence.
The PDOL may differ for different cards. The total number of PDOL parameters is several dozen. The full list of PDOL parameters can be found here.
Let's analyze PDOL more closely. The length specified after the token is strictly the expected length of the response from the terminal to this request. An empty response is filled with zeros up to the required length.
Parsing a PDOL request:
Code:
9F 38 18 / / PDOL start marker. Length 18 (24 bytes)
9F 66 (length 04) / / Terminal Transaction Qualifiers (TTQ). A set of protocols supported by the terminal.
9F 02 (length 06) // Debited amount
9F 03 (length 06) / / second amount
9F 1A (length 02) / / ISO3166-1 Country code
95 (length 05) / / Terminal Verification Results
5F 2A (length 02) // Code of the currency in which the terminal operates, in ISO4217
9A format (length 03) // Date in YYMMDD
9C format (length 01) // Transaction type
9F 37 (length 04) / / Random numberUp to this point, all transmitted data is identical for any transactions on this card.
Debit request - GET PROCESSING OPTIONS
Code:
'80A8000023832136A0400000000001429800000000000006430000000000064318091800E011010300'
80 A8 00 00 // a GET PROCESSING OPTIONS (GPO)
23 // the length of the request (35 bytes)
83 // token PDOL-response
21 // length PDOL-response (33 bytes)
36 A0 40 00 // Terminal Transaction Qualifiers (TTQ)
00 00 00 01 42 98 // the amount of the withdrawal (142,98 rubles)
00 00 00 00 00 00 // Second amount
06 43 / / Equator country code (643 - Russia)
00 00 00 00 00 // Terminal Verification Results (TVR)
06 43 / / Currency (643 - Russian ruble)This response clearly shows how the terminal located in Russia requests a debit from the card in the amount of 142.98 rubles. Pay attention to the random number at the end (E0110103). This is the parameter 9F37 Unpredictable Number. This is the first mention of cryptography. In the future, the card will have to sign this number together with the transaction data with a cryptographic signature. This gives the terminal control over the validity of the card signature and protects it from replay attacks.
The card response to GET PROCESSING OPTIONS
Code:
'7762820200409404180101009F360202069F2608D6F56B8ABED78F239F10201F4AFF32A00000000010030273000000004000000000000000000000000000009F6C02008057134800997250511756D23122010000052099995F9F6E04238800009F2701809000'This response contains VISA-specific data fields, so I used a parser with VISA Contactless Payment Specification (VCSP) support.
Application Interchange Profile (AIP) - contains information about the payment application parameters. In our case, the AIP is 00 40. Consider the values of this parameter from EMV 4.3 Book 3.
In our case, one bit is set in the second byte, which, according to this table, is Reserved For Future Use (RFU). I do not know what this means, and what meaning Apple Pay puts in it.
The AIP contains important information about supported payment authentication methods (SDA, CDA,DDA). I don't understand why all these flags are zero in my case.
Application File Locator (AFL) - contains information about the location of records (SFI range of records) in a specific AID. Based on this response, the terminal will generate a READ RECORD request.
Let's analyze the AFL response in more detail:
Short File Identifier (SFI) is 0x18. This parameter is encoded with five bits instead of eight. Accordingly, the value 0x18 (b00011000) is converted to b00000011, and we get 0x3.
First record = 1
Last record = 1
That is, in "folder" # 3 there are records from 1 to 1, that is, one record.
Application Transaction Counter (ATC) - an incremental transaction counter that is incremented by one each time you request GET PROCESSING OPTIONS. If the value is set to 0xFFFF or 0x7FFF, the payment application will be permanently blocked. I believe that this is done to protect the card's private key from brute-forcing. In our case, it can be seen that this iPhone with Apple Pay has already been used for payment 518 (0x206) times.
Application Cryptogram (AC) - a cryptographic signature that is calculated by the card using its private key. This signature is transmitted along with other data to the issuing bank, and on its basis the authenticity of the transaction is verified. Since the private key of the card cannot be extracted from the card (by any available means), this eliminates the possibility of copying the card.
Issuer Application Data (IAD) - Contains proprietary data specific to VISA. I haven't mastered the analysis of this structure, please help me.
Card Transaction Qualifiers (CTQ) - a VISA-specific list of card-supported specifications. For example, whether this contactless card can be used for ATM operations or not, and what confirmations will be required.
Track 2 Equivalent Data - this field contains the card number and expiration date. This information will be discussed in more detail later.
Form Facto Indicator (FFI) - VISA-specific field. Describes the form factor and characteristics of the payment device. In our case, you can see that this is a mobile phone.
Cryptogram Information Data (CID) - I haven't mastered the analysis of this structure, please help me.
READ DATA RECORD request
Code:
'00 b2 01 1c 00'The terminal sends a request to read records received from AFL:
In this case, starting from byte 0x1C should be read as two values, where the first five bits are 0x18 (b000011), and make up SFI, and the next three bits are 0x04 (d100), and make up the record number.
Response to READ RECORD
Code:
'70375F280206439F0702C0009F19060400100302735F3401009F241D5630303130303134363138303430313737313031333936313637363235'Application Usage Control (AUC) - determines whether it is allowed to pay with a card abroad, and the types of operations allowed.
9F19 - something incomprehensible, apparently-outdated Dynamic Data Authentication Data Object List (DDOL)
EMV Tokenization, Payment Account Reference (PAR) - a parameter specific to tokenized (virtual) cards. I haven't mastered the analysis of this structure, please help me.
What can be extracted from an intercepted transaction?
We analyzed one specific example of intercepted traffic of an Apple Pay contactless transaction with a linked VISA card. The MasterCard protocol is slightly different, but generally similar. The analysis shows that the transaction is protected by a cryptographic signature, and the protocol is protected from replay attacks. There is an outdated contactless payment protocol in Magnetic Stripe (MSD) mode, which is much worse protected from replay attacks, but I will not analyze it in this article, because, as far as I know, it is almost not supported in the CIS, I may be mistaken.
From the intercepted data, you can extract the card number (PAN) and expiration date (expiration date).)
As you can see, you can extract the full card number and expiration date from the intercepted traffic. Although CVV is not included in this dump, this data is already sufficient for payment in some online stores. In the case of a regular physical plastic card, the intercepted data will contain the same PAN and expiration date that is stamped on the card itself!
Online payment without CVV (CNP, MO/TO)
The dump above shows not only my full card number, but also the expiration date. This data is quite enough to pay in some stores on the Internet. Well, let's try it.
The form for adding a card to Amazon does not require a CVV
If it were a physical card number, the money could indeed be stolen, but the Apple Pay token data can ONLY be used for Client Present (CP) operations, when the card signs the transaction with a cryptographic signature. This data cannot be used for online payments and other Card not present (CNP) transactions, i.e. by phone or email. That's it!
Anyone who wants to make sure of this, I inform you that the details from the Apple Pay dump intercepted above are currently up-to-date and linked to a valid card that has money on it. At the time of writing, this is $ 100. I suggest you try to steal them
Why Apple Pay is safer than a regular card
Apple Pay vs regular contactless card
- Apple Pay requires authorization (fingerprint or password) for each transaction made. A regular card does not allow you to manage the number of signed transactions when presented to a POS terminal. In theory, an "evil" terminal with a modified firmware can conduct a single transaction, and while the client is holding the card near the reader, request several signatures, but not conduct them immediately, but conduct them later when the client leaves.
- It does not allow you to read data before authorization when a phone with Apple Pay falls within the reader's range (13.56 MHz), the user is prompted to log in, and only after successful authorization, the phone starts being detected as a contactless card. Up to this point, the reader sees nothing. That is why data from Apple Pay can not be read unnoticed from your pocket, unlike a regular card.
- You can't use intercepted data for online payments - a regular card can be used for Card not present (CNP) operations, i.e. for online payments, phone calls, etc. Data from an Apple Pay virtual card cannot be used in this way.
- It does not disclose the owner's data - ordinary contactless cards can transmit the owner's name (Cardholder name) and the history of recent purchases. In some cases, you can use the card number to set the owner's full name. You can't do anything like that with Apple Pay.
Conclusion
Contactless payment systems are fairly well protected. Despite the theoretical possibility of fraud, in practice it is unprofitable and extremely difficult to implement. There is no reason to be afraid of contactless cards or try to break the antenna in the card.
All other things being equal, Apple Pay will be safer than a regular plastic card. For greater security, you can block CNP transactions (online payment) using the main contactless card, and get a second card only for online payment.
I'm not saying goodbye!
(c) https://habr.com/ru/articles/422551/
Last edited by a moderator:
