Blogy

For the Love of Money: Finding and Exploiting Vulnerabilities in Mobile Point of Sale Terminals

Positive Research Center - 21 Leden, 2019 - 15:48


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 testedFigure 2. mPOS readers testedWe selected five areas for assessment:
  1. Communication between the phone and the payment server
  2. Communication between the mPOS terminal and phone
  3. Security mechanisms within the mPOS terminal
  4. Mobile application
  5. Secondary factors affecting security, such as checks made during enrollment

Figure 3. Scope of assessment in our project
Payment ProcessWe 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 RiskWhen 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 AdoptionGlobal 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 CommandsDevice 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 displayInserting 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 terminalFigure 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 terminalIn 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 paymentFigure 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 TamperingTraffic 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 tamperingThis 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 ExecutionWe 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

HardwarePhysical 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 MechanismsA 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 YRWCRONEFigure 23. Tamper detection circuit within iZettle YRWCRONE

ConclusionWe 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

The Cost Of Security And Privacy For Telcos: How To Do The Math

Positive Research Center - 16 Leden, 2019 - 14:00
Image credit: Pexels
Join Positive Technologies’ telecoms expert Michael Downs for a thought-provoking webinar on the processes and best practices all operators should be following to ensure their networks are secure. In this informative webinar, participants will get an understanding of:

  • the critical security incidents facing telcos every day globally and how operators can remain vigilant in order to support revenue growth
  • how to get transparent TCO (total cost of ownership) estimates for security and significant return on investment while staying in budget
  • the steps required to guarantee compliance with an ever-growing list of requirements in the mobile sector, including 5G and Internet of Things (IoT)

During the webinar, Michael Downs will explain how telecommunication providers can establish ongoing security and data protection processes, and shift from a check-box approach to proactive protection – an essential step for operators in order to effectively fight modern threats. A GDPR expert will also join the discussion to offer attendees insights into how the legislation impacts the telecoms industry and the compliance issues many are facing. 

This immersive session will also include interactive polls and self-assessment surveys to help participants better understand the challenges their company faces and the ways they can improve their overall security posture.

Register hereTelecom privacy and security: how to do the math

Remarkable talks from 35C3

Positive Research Center - 15 Leden, 2019 - 15:51
The 35th Chaos Communication Congress was held at the end of December 2018 in Leipzig, Germany. I have attended a lot of interesting lectures. In this article I'll share the list of great technical talks which I liked the most.

1. Hanno Böck gave a great presentation on the history of SSL and TLS up to the new TLS 1.3, including attacks on the implementations of these protocols and the countermeasures taken. I was especially interested in the difficulties with moving the entire Internet over to the new protocol versions.

[Link to the schedule]



2. Thomas Roth, Josh Datko, and Dmitry Nedospasov jointly researched the security of hardware crypto wallets. They took a look at the security of the supply chain, firmware, and — the most interesting — device hardware. For example, they used a special antenna to remotely recognize the signal between the device display and CPU. They also successfully performed a glitching attack against the hardware crypto wallet and extracted the seed. Impressive work!

[Link to the schedule]



3. Hardware security was also covered by Trammell Hudson, in the context of the Supermicro implant story. He tried to give an objective overview of the controversy but reached some contradictory conclusions. Trammell tried to show that it was possible for the hardware backdoor described in the notorious Bloomberg article to exist. He even gave a demo in which he launched some BMC firmware in qemu and ran arbitrary commands as root by image-spoofing on the qemu side. But some experts have serious doubts about his arguments.

[Link to the schedule]



4. Researchers from Ruhr University delved into the structure of AMD CPU microcode. Their talk provides deep technical details on the topic. This is a continuation of last year's talk from the same team. What I really liked is that the researchers made a custom microcode for a hardware Address Sanitizer that works without the memory access instrumentation. Unfortunately, this approach was tried out only on a toy operating system, so it's unclear how much faster it is comparing to KASAN in the Linux kernel.

[Link to the schedule]



5. Saar Amar's talk was a superb overview of bypassing the userspace anti-exploitation protections in Windows 7 and 10. Live demos were great! This talk would be also interesting for researchers specializing on security of other operating systems, since the described techniques are generic.

[Link to the schedule]



6. Claudio Agosti told about a browser plug-in that monitors how Facebook personalizes and filters the content depending on user properties. This tool made its debut during the Italian elections, producing some very interesting statistics. The goal of the project is not to reverse-engineer Facebook's algorithms, but to get a better understanding of how any given public event is covered on social media.

[Link to the schedule]



7. The researchers from Graz University of Technology gave an entertaining overview of Meltdown and Spectre vulnerabilities. They presented a complex classification covering all public variants of these vulnerabilities. The researchers also disclosed some new Meltdown variants. Surprisingly, this information is not under embargo now and OS developers are not currently working on the mitigations. Maybe the industry is waiting for a real PoC exploit to appear?

[Link to the schedule]



8. Joscha Bach gave a very neat and sophisticated talk on the similarities and differences between the human mind and AI. Expect a heady mix of philosophy, math, neurophysics, and offbeat humor.

[Link to the schedule]



9. An 18-year-old guy from Israel described how he found an RCE vulnerability in the ChakraCore engine of Microsoft Edge browser. His discovery involves a classic example of type confusion, when a floating-point number turns into a pointer and is dereferenced.

[Link to the schedule]



10. I really liked Carlo Meijer's talk about breaking SSD self-encryption (which is trusted by BitLocker, incidentally). The presentation included discussion of the threat model (which is always nice), hacking of Self-Encrypting Drives (SEDs) from several manufacturers (all with demos), and the conclusion that SSD self-encryption in all cases is less secure than the full disk encryption performed by OS. Definitely worth watching.

[Link to the schedule]



11. Hacking the PlayStation Viva was a blast: the researchers even managed to extract the platform's most important key from its security-hardened ROM. Watching this talk was a treat, thanks to top-notch research and great presentation of the material.

[Link to the schedule]



12. Curious about blocking of Telegram in Russia? I was dreading that I would have to hear political propaganda, but instead was delighted by a lively technical talk. The researcher gave a history of the steps taken by the Roskomnadzor, showed statistics, explained some of the technical gaps, and gave a good-natured trolling to the authorities.

[Link to the schedule]



13. An inspiring talk on the software and hardware inside the Curiosity rover, which went to Mars. Beautiful slides and smooth presentation – I recommend it.

[Link to the schedule]



14. Everyone is in deep trouble, at least judging by this talk about the vulnerabilities in Broadcom's Bluetooth firmware. Updating or fixing it is not feasible for a number of reasons. Moreover, affected devices include nearly all smartphones made in the last five years, cars, and the IoT. Maybe we all just need to turn off Bluetooth?

[Link to the schedule]



These talks are just a starter list — I highly recommend checking the 35C3 recordings!

Enjoy!

Author: Alexander Popov, Positive Technologies

Chystá se konec a stěhování.

POOH.cz - 28 Květen, 2017 - 01:00
Takže, tohle je poslední příspěvek na starém Pooh.cz. A také jeden z prvních , co se objeví i na novém Pooh.cz, provozovaném na Wordpress.com.
Kategorie: Blogy

Aktuální vypsané termíny školení - sociální sítě, bezpečnost, internetový marketing, public relations

POOH.cz - 17 Květen, 2017 - 01:00
Více informací o všech školeních i dalších možnostech školení na míru najdete na www.bradbury.cz
Kategorie: Blogy
Syndikovat obsah