Stealing PINs and pillaging bank accounts are both trivial. Credit card users could have their PINs stolen, and merchants could have their bank accounts pillaged, in a set of attacks demonstrated by researchers Karsten Nohl and Fabian Bräunlein at the Chaos Computing Club security conference.
Much research has been done into the chips found on credit cards and the readers and number pads used with these cards, but Nohl decided to take a different approach, looking instead at the communications protocols used by those card readers. There are two that are significant; the first, ZVT, is used between point of sale systems and the card readers. The second, Poseidon, is used between the card reader and the merchant’s bank. Nohl found that both had important flaws.
The ZVT protocol was originally designed for serial port connections, but nowadays is used over Ethernet, both wired and wireless. The protocol has no authentication, meaning that if an attacker can put themselves on the same network, they can act as a man-in-the-middle between the point-of-sale system and the card reader. The attacker can then read the magnetic stripe data from the card, and can also request a PIN.
This could then be used to harvest card details at a retailer. Each time the PoS system asks the card reader to perform a PIN-authenticated transaction, the card reader can intercept the request, and replace it with a request for the mag stripe, and then a request for the PIN. With this data harvested, the attacker can easily create cloned cards. To avoid raising suspicion, the attacker’s man-in-the-middle can then direct the card reader to perform an unauthenticated PIN-less transaction using the magstripe data, leaving both cardholder and retailer unaware that anything has gone wrong.
In principle, the card readers are designed to ensure that the PIN never leaves the secure part of the reader. Nohl used a ZVT feature that enables arbitrary text to be written to the reader’s screen—a prompt asking for the PIN, say—with a numeric response from the keyboard. This shouldn’t be possible; this feature of ZVT technically requires the arbitrary text to be paired with a message authentication code (MAC): a piece of cryptographic data that proves that the text has been generated only by a trusted party.
Unfortunately, the way this MAC is implemented is insecure; with brute force trial and error, the correct MAC for a piece of text can be determined through a timing attack—it takes slightly longer to accept a good MAC than it takes to reject a bad MAC.
This hack does betray its presence to a particularly observant shopper; the receipt will disclose that the transaction went through without using a PIN. It also requires access to the same network as is used between the reader and the PoS system.
The second attack that Nohl demonstrated was an attack on the merchant rather than the cardholder. The ZVT protocol is used for more than just performing transactions; it is also used to configure the card readers. Each card reader has a terminal ID, used to identify which merchant it belongs to, and a port number. The terminal ID and port pair are configured by the bank to refer to a specific bank account. ZVT allows both of these to be reconfigured by an attacker on the local network. If a retailer’s card reader is programmed with a different terminal ID and port, it will happily make transactions, but to merchant account of the attacker’s choosing.
Again, ZVT has no practical authentication to prevent this. Setting the terminal ID does require a password, but Nohl found that a fixed password was used, and that this password is widely available online.
Changing the terminal ID resets the terminal, which would normally reset things such as the store name and transaction limits. However, the Poseidon protocol—used for terminal-to-bank communication—can be used both to retrieve the correct version of this data, and program it into the card reader. This effectively masks that an attack is taking place.
The attack does have two issues; it still requires access to the network that the card reader is using—just as with the first flaw, the attacker must be a man-in-the-middle, though this time sitting between the card terminal and the Internet—and it also requires the attacker to have a merchant account of their own. This likely limits the applicability of the attack.
The third attack, this time focusing on the Poseidon protocol entirely, avoids both of these issues. It’s also absurdly simple: buy a card reader from e-Bay, configure that card reader to act as if it belonged to the victim you want to defraud, and then use it to process transactions.
To make its connection to the payment processor, the terminal sends its terminal ID to the processor using a particular port, and receives encrypted configuration data in response. Nohl and Bräunlein found some interesting features of this. First, the terminal IDs are issued sequentially, and are also printed on every receipt issued by the terminal. Second, that the encrypted data is secured using a service passcode. That service passcode is typically shared, with a payment processor using the same passcode for every single merchant. The port number must also be configured, but this can be done with brute force: test each port number and see which one responds to the victim terminal ID.
To steal from a victim, then, the card reader needs to be programmed with the victim’s terminal ID, service passcode, and port number. The terminal ID is trivially found, the service passcode can typically be found through searching the Web, and the port number can be brute forced. With these three piece of information, as far as the payment processor is concerned, the card reader belongs to the merchant.
With this done, the merchant can be robbed in two ways. The card readers can often be used to buy top-up codes for pay-as-you-go cell services. Using the card reader to buy a top-up will deduct the money from the merchant’s bank account, and the top-up code can be used for cell service.
Better yet—for the attackers, at least—the terminal can also be used to perform refunds. Refunds are simply negative valued transactions; there’s no requirement for a refund to be matched to a corresponding purchase or credit card. Money can simply be withdrawn from a merchant’s account and placed onto a credit card of the attacker’s choosing.
Spoofing a card terminal in this way doesn’t even disable the retailer’s own terminals, so they’ll never notice that anything has happened. Nohl and Bräunlein called this use of spoofed card terminals “shopshifting.”
For all these attacks, the root problem is a lack of proper authentication. The terminal ID and passcode form a username and password of sorts, but such measures are useless when the user IDs are trivially guessable and the password is always the same. Although techniques to protect against man-in-the-middle attacks are widely known and used, neither ZVT nor Poseidon uses them. This lack of authentication renders both protocols fundamentally insecure.
The good news, such as it is, is that all of these attacks are primarily aimed at German technology, and may be less effective internationally.
The ZVT protocol is German, and used in a few other European countries too. The main alternative is called OPI, Open Payment Initiative. Although this is a relatively new protocol, created in 2003, it retains ZVT’s lack of authentication and encryption. It should be a little safer as it doesn’t include the ZVT features used for remote management and configuration of card terminals, but the researchers found that vendors had extended OPI with their own proprietary extensions to reinstate this “missing” ZVT functionality.
As such, while non-German systems may be less susceptible to the man-in-the-middle attacks, some hardware may retain the same flaws.
Poseidon is a particular implementation of a global standard, ISO 8583. Other ISO 8583 implementations may well share similar, if not identical, flaws, as the specification does not require any kind of strong authentication.
In the short term, payment processors could make things a little more secure through the use of random passwords and terminal IDs. That would at least make the Poseidon attack less straightforward. However, a real fix is going to be much harder to deploy, as both protocols need to be altered to require strong authentication.
Nohl reported his findings to payment processors, but they have so far done little in response. Reuters writes that the German Association of Savings Banks, issued a statement on behalf of all German banks, saying the attack scenarios presented by Nohl were only theoretically possible. Nohl demonstrated this “theoretical” attack on stage at CCC, and says that he has made dozens of test transfers proving that the flaw is real.
Source:https://arstechnica.com/
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
