This ArsTechnica article describes three new man-in-the-middle attacks that were demonstrated at the Chaos Computing Club security conference. Banks may be concerned as the first hack demonstrated how a user’s PIN could be harvested. While the demonstration utilized protocols implemented primarily in Germany, the article identifies significant similarity with the protocols used to drive US-based POS systems.
All three hacks require criminals gain access to the merchant’s physical or electronic POS communications infrastructure, which under PCI would likely make the merchant liable for any fraud conducted using this hack:
“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.”
The article goes on to explain why this hack is possible in greater detail and then goes on to describe a variant of this same hack that focuses on defrauding the merchant rather than the cardholder or issuing bank:
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 hack focuses on the communications between the POS and the acquirer and in theory enables a POS controlled by the criminal to be connected to the merchant’s bank account, enabling the criminals POS to apply credits from the merchant’s account to the criminal’s cards:
“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 article then explains that these German protocols that were hacked are similar to US-based protocols:
“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.”
The researcher that discovered these hacks claims to have communicated the basis to payment processors with little to no response and the article indicates that the German Association of Savings Banks calls the attacks “theoretical” and therefor apparently uninteresting. Mercator expects the disinterest is more associated with the fact that this hack is against the merchant’s infrastructure which is the merchant’s responsibility to fix:
“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.
Fortunately, however, criminals have not yet taken advantage of these weaknesses.”
Overview by Tim Sloane, VP, Payments Innovation at Mercator Advisory Group
Read the full story here