For money: search and exploit vulnerabilities in mobile payment terminals
Card payments are becoming increasingly popular. Mobile payment terminals (mPOS-terminals) contribute to the development of this trend, reducing barriers to entry into the market of card payments for small firms and private entrepreneurs. Moreover, under certain conditions, operations can still be carried out in many countries (including Russia) with the help of a magnetic strip. Each new round of technological progress endangers the payment ecosystem. What security problems can easier access to the card payments market lead to? And how do we risk continuing to rely on old card technologies, in particular, on the magnetic strip?
In recent years, the number of operations carried out with the help of mPOS terminals has increased significantly. Intense competition among mPOS providers has made it extremely easy to get such a payment terminal. Signing a contract takes less than five minutes, and the mPOS terminals themselves are often provided free of charge. Now they can be seen everywhere. Like ordinary POS-terminals, they are the final link in the payment infrastructure. This makes them interesting and easily accessible to intruders.
Field of study
We evaluated the products of the leading suppliers of mPOS terminals: PayPal, Square, iZettle and SumUp. Some of them provide services in several regions of the world. We tried to access services in different regions, where it was possible, since the payment process, applications and devices, as well as security settings differ depending on location.
|Square||Square||Terminal for contactless |
cards and cards with Square (S8) chip
|Square||Square||Terminal for magnetic cards |
|Square||Square||Terminal for contactless cards and cards with Square (S8) chip||Europe|
|Square||Square||Terminal for magnetic cards Square (S4)||Europe|
|Square||Miura Systems||Miura M010||USA|
|SumUp||(not public)||AIR1 E001||Europe|
|Paypal||Miura Systems||Miura M010||Europe|
Manufacturers and suppliers of mPOS terminals
We have analyzed the security of devices in five categories:
- communication between the telephone and the payment system server;
- communication between the phone and the mPOS terminal;
- physical protection mechanisms of the mPOS terminal;
- mobile app;
- additional factors affecting security, in particular, check-in during registration.
Main areas of research
We studied in detail the attack vectors and card payment security issues. The vulnerabilities that we discovered threaten the basic functionality of the mPOS terminal.
The main difference between mPOS and ordinary POS terminals is that the seller is not directly connected with the acquiring bank. Instead, mPOS providers act as payment aggregators that charge a transaction fee. Such payment services cannot always guarantee the level of security provided by the acquiring bank. MPOS providers minimize security risks in their own way, often shifting responsibility for fraud to the acquirer. It is important to understand that such payment aggregators are actually sellers themselves who interact with the acquiring bank.
Payment process through mPOS-terminal
Risks when paying by card
There are various ways of card payments. They depend on the payment system, issuer and country of issue. During the transaction, the card sends a list of supported cardholder verification methods (CVM), which describes the supported methods and their priority. CVM also regulates what should happen if the selected method fails. The terminal stores the configuration file, which also describes the supported verification methods. The terminal compares these two files and tries to make a transaction using the first priority method. The priority method should provide a high degree of assurance that the card holder was present during the operation.
Some types of payments are obviously safer than others. Payment by a card with a chip and using a PIN code is considered the safest method, because it gives a high degree of guarantee that the operation has been approved by the cardholder. The magnetic stripe is considered to be a less secure technology, since an attacker can easily clone the magnetic stripe and Track2 data stored on it and forge the signature of the cardholder. The operations carried out with the use of a magnetic strip do not give confidence that the card holder was indeed present at the transaction. Unlike card operations that support the EMV standard, transactions using magnetic stripe pass without a cryptogram. This means that such operations do not ensure the integrity and authenticity of the transaction during its execution.
Adopt EMV standard
More and more payments in the world are made according to the EMV standard (Europay, Mastercard, Visa), that is, with the help of chip cards. However, the adoption of the standard in some regions is slower than in others. In the US, EMV operations account for less than half of all transactions . Most operations are still carried out using a magnetic strip. In Europe, about 90% of all operations are carried out according to the EMV standard .
Manipulation with the device: sending arbitrary commands
An attacker can connect to the device via Bluetooth and perform arbitrary operations. To do this, he needs information about the Bluetooth services running on the device, as well as relevant characteristics and functions. This information can be obtained using reverse engineering prior to the attack. An attacker will only need access to the mPOS terminal, a phone that supports the registration of events of the host controller interface (HCI), and a mobile application. With the help of HCI event logging, an attacker will try to get information about the main functions of the mPOS terminal. For this, he will conduct trial operations using different methods of payment and comparing the results. When the necessary information is received, the attacker using Wireshark will analyze the communication between the phone and the mPOS terminal. This information, as well as mobile application data, will allow to compare functions with their commands and identifiers. Figure 5 shows the sending of the message “Insert (swipe) the card” on the display of the mPOS terminal.
The message "Insert (swipe) the card" sent to the display
If the card is inserted incorrectly, the error message "Please take the card" appears on the display. In the HCI journal, we see which UUID is responsible for displaying text and an example of the data being sent.
The message “Please take the card” on the display of the mPOS terminal
The first Bluetooth packet is responsible for sending the message “Please take the card” The
second Bluetooth packet is responsible for sending the message “Please take the card” (the message is divided into two packets due to the small maximum size one package of Bluetooth Low Energy).
The figure below shows that the value sent to the mPOS terminal consists of five parts. It includes a prefix containing the command identifier, the value of the counter of the commands sent and the size of the payload, the main text in the form of ASCII characters, as well as the postfix, the checksum value and the terminating byte.
Elements of two packages responsible for sending the message “Please take the card”
In the following example, the terminal uses Bluetooth Classic to communicate with the phone. We see the message "Insert (swipe) the card", sent to the display terminal.
The message “Insert (swipe) the card” on the display of the mPOS terminal
The Bluetooth package (in the Wireshark window) responsible for sending the message “Insert (swipe) the card” to the display of the mPOS terminal
The figure below shows that this data consists of three parts: the prefix, the message and the checksum. The prefix also contains a counter, a command ID, and a payload size. The message contains the value "Insert (swipe) the card" in ASCII. Checksum - XOR all bytes of the message.
Package elements responsible for sending the message “Insert (draw) a card”
With this information you can create an arbitrary command and send it to the display of the mPOS terminal. Three of the devices we tested were vulnerable to this attack vector.
|SumUp||(not public)||AIR1 E001||Europe|
List of terminals vulnerable to sending arbitrary commands. Although the reader Square (S8) does not have a display, an attacker can send other arbitrary commands.
This attack vector can be used in conjunction with the exploitation of other vulnerabilities in order to offer the client less secure types of operations, for example, on a magnetic strip. This scenario is described in figures 14–16. In addition, an attacker may send a “Payment Declined” message to force the cardholder to conduct several transactions.
The cardholder is trying to insert a card. The
message “Please swipe the card” sent to the terminal display forces the cardholder to use a magnetic stripe.
The operation was carried out successfully - for the operation performed using a magnetic strip, you must leave a signature.
There are different ways to intercept traffic between the mPOS terminal and the server of the payment system. We have already described one of them - registration of HCI events on a mobile phone and analysis of the results obtained. To do this, you must enable the developer (Android Developer Mode). An attacker can go in other ways, for example, to intercept HTTPS traffic between the mobile application and the server of the payment system. This is possible because in most cases the server of the payment system generates commands and sends them to the mPOS terminal. To protect the mobile application from intercepting HTTPS, all suppliers of the terminals we tested use SSL pinning.
The figure below is an example of an initialized payment, intercepted by two different methods. We were able to intercept HTTPS traffic using a man-in-the-middle attack (man-in-the-middle), and so turned on the debug mode. The amount of the transaction is given in unencrypted form. A value of 0100 corresponds to £ 1.00.
Initialized payment made with the help of mPOS-terminal
Having intercepted HTTPS-traffic, we can change the transaction amount. Then you need to recalculate the checksum. After that we can send the changed amount to the payment system server to confirm the transaction. We found five terminals vulnerable to sum modification in magnetic stripe operations.
|Square||Square||Square||USA / Europe|
|Magstripe Reader (S4)|
mPOS terminals vulnerable to counterfeit amounts A
dishonest seller may fraudulently force the cardholder to confirm a transaction for a much larger amount. During the operation, the seller displays one amount to the reader’s display, but the service is sent to the provider of the mPOS terminal to confirm the larger amount. This attack is shown in the figure below.
Left: the amount sent to the payment system server (£ 1.23). Right: the amount that the cardholder sees (£ 1)
Terminals supporting operations using magnetic stripe are affected. During operations, the terminal sends only encrypted data to Track2; the operation itself is not assured. This attack vector will not work if the operation is performed according to the EMV standard, because in such operations the sum information is stored inside the cryptogram. Contactless PayPass and payWave payments that support Legacy modes (PayPass MAGSTRIPE and PayWave MSD) do not provide this level of protection, since the amount information is also not protected by a cryptogram.
To understand the scale of the problem, it suffices to recall that less than 50% of transactions in the United States are carried out according to the EMV standard. In addition, the service providers tested by us set the limits for a single operation using a magnetic strip in Europe and the USA is incredibly high, at € 50,000 and $ 50,000, respectively.
This attack can be prevented by using cryptographic control of the integrity of the amount and currency fields and comparing the amount and currency of the operation on the reader with the amount confirmed by the service provider. It is important to note that the PCI DSS standard (current version 3.2.1), which regulates the storage, processing and transmission of card data, does not require such checks in the case of operations using magnetic stripe. The operation requires only the transfer of data Track2.
Remote code execution
Two of the terminals we tested were vulnerable to remote code execution. Operation of this vulnerability provides an attacker with full access to the operating system of the terminal. After the attacker gets full access to the operating system, he will be able to intercept Track2 data before encryption or enable unencrypted mode (to send a command) on the terminal's keyboard to intercept the PIN code.
The list of terminals vulnerable to the remote execution of the Nyan Cat Movie code
on the display of the Miura M010 terminal. Remote code execution allows an attacker full access to the terminal’s operating system.
The physical protection mechanisms of most mPOS terminals are quite reliable. The Square (S4) magnetic card reader does not guarantee the level of security and technological complexity characteristic of contactless and chip card readers. However, this should be a standard device requirement that is provided to the seller free of charge. The remaining terminals provide an adequate level of physical protection, support mechanisms that prevent the opening, and other measures to prevent hacking of hardware.
Anti-tamping systems help prevent opening the terminal with a drill and other tools. When attempting to open it, an electrical circuit is broken and the device stops working. In addition, most readers operate on proprietary standards. Without access to developer documentation, it is impossible to obtain valuable information by physically opening the device.
Internal iZettle YRWCRONE
System for detecting attempts to open iZettle YRWCRONE
We found that more than half of the mPOS terminals are vulnerable to attack, while in general all the mPOS terminal suppliers we analyzed were vulnerable. We have documented numerous serious security issues, in particular a vulnerability for executing arbitrary commands, forging a sum, and executing remote code.
Terminal hardware security mechanisms are in most cases reliable and advanced. However, other aspects, such as those associated with the mobile application and the registration procedure, are much less secure.
The developers of mPOS-terminals emphasize the ease of registration and use of devices. These are key elements of a business model, but it does not take into account that a decrease in barriers to entry into the card payment market must be accompanied by a significant increase in security. There is no doubt that the fraudulent actions of sellers will remain a serious problem for the suppliers of mPOS-terminals. It is necessary to develop a serious approach to the problem of security, including verification during registration and strict monitoring of payments.
Authors : Lee-Ann Galloway, Timur Yunusov, Artem Ivachev, Mark Kerni, Alexey Stennikov | Positive Technologies