Card payments are increasingly accepted everywhere. Mobile Point of Sale (mPOS) terminals have propelled this growth by lowering the barriers for small and micro-sized businesses to accept credit and debit cards. All the same, older payment technologies—such as magnetic stripe—still account for most in-person transactions. Inevitably, each new layer of technological complexity is liable to introduce weaknesses into a fragmented payment ecosystem. What are the security and fraud implications of lowering the economic barriers to accepting card payments? And what are the risks associated with continued reliance on old card standards and magnetic stripe (aka magstripe) in particular?
mPOS payments have boomed in recent years. As providers eagerly compete for merchants' business, the entry barriers to accepting card payments have fallen to effectively zero. Signing up takes less than five minutes and mPOS terminals are available for free. mPOS terminals are seemingly everywhere, and like traditional Point of Sale terminals, they sit at the endpoint of payment infrastructure. This fact makes them attractive and accessible to criminals.
Research Scope
We focused on the most popular mPOS vendors on the market: PayPal, Square, iZettle, and SumUp. Some of these vendors operate in multiple regions. In such cases, we attempted to obtain accounts and readers for each region because there are important region-specific differences in processes, applications, and devices.
 |
| Figure 1. mPOS readers, manufacturers, and vendors tested |
 |
| Figure 2. mPOS readers tested |
We selected five areas for assessment:
- Communication between the phone and the payment server
- Communication between the mPOS terminal and phone
- Security mechanisms within the mPOS terminal
- Mobile application
- Secondary factors affecting security, such as checks made during enrollment
 |
| Figure 3. Scope of assessment in our project |
Payment Process
We focused on attack vectors and security issues affecting card payments because these would compromise the core functionality of an mPOS terminal. The transaction process for mPOS terminals works differently from that of a traditional Point of Sale terminal.
The key difference from the traditional engagement model is that the merchant no longer has a direct relationship with an acquiring bank. Instead, mPOS providers act as payment aggregators. These providers, in turn, add a fee to the processing value of the transaction as markup. They may or may not assess risk at the same level as an acquiring bank would. And these providers may choose to mitigate risk in other ways, for example contractually. It is important to understand that payment aggregators are themselves a merchant who has an acquiring bank.
 |
Figure 4. Payment process for an mPOS terminal
|
Card Risk
When a card transaction is made, there are standardized lists describing the methods of payment that can be made with a card. These differ depending on the card brand, issuer of the card, and country of issue. During a transaction, the method used to make the payment is negotiated between the card and the terminal. The card stores a list called Cardholder Verification Methods (CVM), which describes the types and order of cardholder verification methods that are supported. The CVM also describes what should happen in situations when one method fails. The terminal contains a configuration file that describes the types of operations supported by the terminal. It will compare the CVM on the card to its supported methods and attempt to carry out the transaction using the highest-priority method. The highest-priority method should both be supported by the card and provide a high level of assurance that the cardholder was present during the transaction.
Generally speaking, certain types of payments are more secure than others. Chip and PIN is considered most secure, because it provides a high level of assurance that the transaction has been authorized by the cardholder. Conversely, methods such as magnetic stripe are considered less secure because the Track2 data stored on the magnetic stripe can be easily cloned, and any cardholder signature can be forged. Magnetic stripe transactions do not provide a high level of assurance that the cardholder was actually present. Unlike EMV, magnetic stripe transactions do not have a cryptogram. This means that magnetic stripe transactions are potentially vulnerable to modification prior to being received by the payment provider.
EMV Adoption
Global uptake of EMV ("chip cards") is higher than ever, but the process of adoption has been slower in some geographic areas than others. EMV transactions account for
less than half of all card transactions in the U.S. The majority of transactions made in the U.S. are still made using magnetic stripe. By comparison, in Europe, around 90 percent of all transactions are
performed using EMV.
Findings
Device Manipulation: Sending Arbitrary Commands
Device manipulation is possible when an attacker connects directly to a Bluetooth device and forces the device to perform certain functions. To do so, an attacker must first be aware of the services running on the Bluetooth device, as well as relevant characteristics and functions. This knowledge can be obtained prior to an attack by means of reverse engineering. An attacker simply needs access to a target device, mPOS terminal, phone that supports Host Controller Interface (HCI) logging, and the mobile application. After HCI logging has been enabled, the attacker will try to capture the core functionality of the mPOS terminal. The way to do this is by performing sample transactions with different payment methods and comparing the results. Once this information has been captured, Wireshark can be used to analyze communication between the phone and mPOS terminal. This information, along with information obtained from the mobile application, makes it possible to correlate functions with their characteristics and handles. Figure 5 depicts the sending of the "Insert/swipe card" message to the display of an mPOS terminal.
 |
| Figure 5. "Insert/swipe card" sent to the reader display |
Inserting a card incorrectly into this terminal generates the error message "Please remove card". We can see the UUID responsible for this function of displaying text, as well as the value of the data sent, in the HCI log.
 |
| Figure 6. "Please remove card" as shown on mPOS terminal |
 |
| Figure 7. First Bluetooth frame responsible for sending "Please remove card" |
 |
| Figure 8. Second Bluetooth frame responsible for sending "Please remove card" (the message is split across two frames because Bluetooth Low Energy has a small packet size) |
As shown in Figure 9, the value sent to the mPOS terminal consists of five parts. In order, they are: a leading part containing a command value and counter, main text in ASCII, trailing value, checksum value (CRC), and end value.
 |
| Figure 9. Elements of two packets responsible for sending "Please remove card" |
In the next example, the terminal uses Bluetooth Classic to communicate with the phone. Here we can see the message "Insert/swipe card" being sent to the display of the reader.
 |
| Figure 10. "Insert/swipe card" message on mPOS terminal |
 |
| Figure 11. Bluetooth frame, shown in Wireshark, responsible for sending "Insert/swipe card" to the mPOS terminal |
In Figure 12, we can see that this data is made up of three parts: the leading value, message, and checksum (CRC). The leading value contains a counter, command ID, and size of the payload. The message contains the value "Insert/swipe card" in hex. The checksum is a simple XOR value.
 |
| Figure 12. Elements of packet responsible for sending "Insert/swipe card" |
Using this information, it is possible to calculate any value to send to the display of an mPOS terminal. Three tested devices were vulnerable to this attack vector.
 |
| Figure 13. List of terminals vulnerable to sending of arbitrary commands. Note that although the Square Contactless and Chip Card Reader (S8) does not have a display, arbitrary commands may be attempted. |
This attack vector can be used in conjunction with other vulnerabilities to downgrade a cardholder's transaction to a less secure payment method, such as magnetic stripe. Figures 14–16 depict this scenario. In addition, this vector could be used to display a "Payment declined" message to trick the cardholder into carrying out multiple transactions.
 |
| Figure 14. Cardholder attempting to insert card for payment |
 |
| Figure 15. "Please swipe card" message sent to the terminal forces the cardholder to carry out the transaction using magnetic stripe |
|
Figure 16. "Please sign now" message sent to mPOS terminal
|
Amount Tampering
Traffic between the mPOS terminal and the payment server can be intercepted in a number of ways. We have already described one way: enabling HCI logging on the mobile phone and analyzing the output. If restrictions prevent enabling developer mode, interception can also be accomplished by intercepting HTTPS traffic between the mobile application and the payment server, for example. This is possible because in most cases, the payment server generates commands and sends them to the mPOS terminal. To protect the mobile application against HTTPS interception, all vendors of the tested terminals implement SSL Pinning.
Here is an example of an initialized payment. We were able to intercept HTTPS traffic (via Man-in-the-Middle) and enable debug mode. The amount for this transaction is sent in plaintext. The value "0100", as seen in the figure, represents £1.00.
 |
| Figure 17. Initialized payment for an mPOS terminal |
By intercepting HTTPS traffic, we can modify the amount value for this transaction. Once the amount has been changed, the checksum will need to be recalculated. Then we can send this new value to the payment server for approval. We identified five terminals that are vulnerable to amount modification for magnetic stripe transactions.
 |
| Figure 18. mPOS terminals vulnerable to amount tampering |
This vulnerability can be used by a fraudulent merchant to trick a cardholder into approving a much higher amount than intended. During the transaction, the merchant displays one (lower) amount on the card reader but another (higher) amount is actually sent to the mPOS provider for approval. This attack is shown in Figure 19.
 |
| Figure 19. On the left: amount sent to the payment server (£1.23), on the right: amount shown to the cardholder for approval (£1.00) |
This vulnerability affects magnetic stripe transactions. The terminal sends only Track2 data during transactions; there is no signing of the transaction itself. This attack vector is not possible for EMV transactions because the amount is stored inside the payment cryptogram. For contactless payments (PayPass and payWave), less secure modes do not store the amount inside a cryptogram and therefore may also be affected by this vulnerability.
This issue becomes even more significant when we remember that less than 50 percent of all transactions in the U.S. are made using EMV. In addition, the limits for individual magnetic stripe transactions are incredibly high in both Europe and the U.S., at €50,000 and $50,000 per transaction, respectively.
This attack vector could be prevented by calculating a cryptographic checksum of the transaction, or else by implementing the payment amount in the magnetic stripe transaction and comparing the value of the transaction on the reader to the one initialized by the payment server. It is worth noting that the PCI-DSS standard (current version 3.2.2.1), which governs the storage, processing, and transmission of card data, does not require that these checks be implemented for
magnetic stripe transactions. So long as Track2 data is transmitted, the transaction will go through.
Remote Code Execution
We found that two of the tested terminals were vulnerable to execution of remote code. Exploitation of this vulnerability provides full access to the terminal's operating system. After an attacker has obtained full access to the operating system, it is possible to intercept Track2 data before it is encrypted and enable plain text mode (command mode) on the terminal's PIN pad to collect PINs.
 |
| Figure 20. List of terminals vulnerable to Remote Code Execution |
 |
Figure 21. Remote Code Execution provides full access to the file system of the terminal: here, an animation of Nyan Cat is playing on the Miura M010 terminal
|
Hardware
Physical security mechanisms within most mPOS terminals are robust. The Square Magnetic stripe Reader (S4) does not contain the level of security or sophistication found in the other contactless and chip readers. However, this is to be expected in a device that is provided free to all merchants. All the other terminals feature a good level of physical protection, anti-tampering mechanisms, and other measures to deter would-be hardware sleuths.
Anti-Tampering Mechanisms
A tamper detection circuit is used to protect against opening of the terminal and use of drills and other tools. If tampering is attempted, the circuit breaks and the device stops functioning. In addition, most card readers use proprietary standards. Without access to the documentation provided by hardware manufacturers to the product vendors, it is not viable to obtain any valuable information by physically probing these devices.
 |
| Figure 22. Insides of iZettle YRWCRONE |
 |
Figure 23. Tamper detection circuit within iZettle YRWCRONE
|
Conclusion
We found that over half of mPOS terminals were vulnerable to one or more attacks; terminals from all four mPOS vendors were affected. The issues we identified were serious and numerous: vulnerability to arbitrary commands, amount tampering, and Remote Code Execution.
Hardware security mechanisms in the terminals are generally sophisticated. However, many other aspects of payment—such as the mobile ecosystem and enrollment processes—are far less secure.
Vendors of mPOS terminals tend to emphasize usability and enrollment. These are key elements of their business model, but this approach has not taken into account that security must be very high across the board to counteract the low entry barriers. Without a doubt, fraudulent merchant accounts are, and will be, a significant issue for mPOS providers. Mitigation of this issue will require a sophisticated approach to security that encompasses checks during the enrollment process and stringent transaction monitoring.
Authors: Banking Security Team, Positive Technologies
