Poor security decisions expose payment terminals to mass fraud

The terminals, used predominantly in Germany but also elsewhere in Europe, were designed without following best security principles, leaving them vulnerable to a number of attacks.

Researchers from Berlin-based Security Research Labs (SRLabs) investigated the security of payment terminals in Germany and were able to use them to steal payment card details and PIN numbers, hijack transactions and compromise merchant accounts. They plan to present their findings at the 32nd Chaos Communication Congress (32C3) later this month.

According to Karsten Nohl, the founder and chief scientist of SRLabs, most terminals in Germany use two communication protocols, ZVT and Poseidon, to talk with cash registers and payment processing providers respectively.

Both of these protocols have features that can be abused by hackers, but the problem is further exacerbated by poor design decisions by payment terminal manufacturers, like the reuse of cryptographic keys across all devices.

The ZVT protocol is used by around 80 percent of payment terminals in Germany to communicate with cashier workstations, SRLabs estimates. It was originally designed for serial connections, but it's now used mostly on TCP/IP networks. This means that on local networks attackers can use techniques such as ARP spoofing to position themselves between terminals and cashier stations in order to intercept and send ZVT commands.

Some of the ZVT traffic is unencrypted, according to SRLabs. For example, a man-in-the-middle attacker can use the protocol without authentication to read the information stored on the magnetic stripes of payment cards inserted into payment terminals.

The protocol also has a mechanism that allows requesting and obtaining a card's PIN number as well, but such requests need to be signed with a message authentication code (MAC). The MAC is verified using a key that's typically stored inside the payment terminal's hardware security module (HSM), a special component designed for secure key storage and cryptographic operations.

The problem is that most terminals, regardless of manufacturer, share the same signature key, violating a basic principle of security design, Nohl said.

The HSM in some terminal models is vulnerable to so-called timing side channel attacks that can be used to extract the key within minutes after gaining access to the terminal through a JTAG debugging connection or a remote code execution flaw, he said.

Attackers can easily find and buy such vulnerable terminals on eBay. Once they extract the key from it, they can use it against most other devices, including newer models, because of the pervasive key reuse among payment terminal manufacturers in Germany.

Terminals used in other countries, especially in Europe, use a different communications protocol called OPI (Open Payment Initiative) that is similar to ZVT, but lacks the remote management functionality that attackers can abuse.

However, some terminal manufacturers added proprietary extensions to OPI to implement that functionality, because they like the comfort of remote management, Nohl said. "At least we've seen this in a few cases. We can't guarantee that it's widespread, but every implementation of OPI that we've looked at had extensions that brought back remote manageability, and like in ZVT, it wasn't secure."

With magnetic stripe data and associated PIN numbers attackers can clone payment cards and perform fraud, even in countries where chip-protected (EMV) cards are widely deployed.

EMV-capable terminals still support magstripe-based transactions for cards that don't have a chip, and verifying whether the card has a chip or not is usually done by checking a specific bit stored on the magnetic stripe. So an attacker can simply change that bit on his cloned card, Nohl said.

Another attack that the SRLabs team found possible through ZVT is to force a terminal to associate with a different merchant account, like one controlled by a hacker, and which would receive all the money from transactions performed through that terminal.

This can be done by a man-in-the-middle attack through a password-protected command that instructs the terminal to change its ID to one that the payment processor associates with a different merchant. The password is the same for all terminals tied to a specific processor, the SRLabs researchers found.

When the terminal ID changes, the processor will send a new configuration back to the terminal including the new merchant's transaction limits and banner -- the merchant identifying information that appears on the printed receipts. The attacker can actually intercept this information and change it so that receipts retain the old merchant's banner, while the money is funneled to the different account controlled by the attacker.

A third attack is possible through the Poseidon protocol that's also widely used in Germany and in some other countries like France, Luxembourg and Iceland. This protocol is used by terminals to communicate with the backend servers of payment processors and is a variation of an international standard called ISO 8583.

Payment terminals require a secret key to authenticate with payment processors over the Poseidon protocol. However, like with ZVT, payment terminal manufacturers implemented the same authentication key across all of their terminals, SRLabs found.

This error can be abused to steal money from merchant accounts. While most transactions add money to such accounts in exchange for goods or services, there are a few that can cost merchants money, for example transaction refunds or top-up vouchers like those used to recharge prepaid SIM cards.

In the worst case scenario, attackers could hijack terminals and use them to issue refunds to bank accounts under their control from thousands of merchants by simply iterating through terminal IDs, which are usually assigned incrementally.

Nohl said that SRLabs performed a demonstration of the attacks for payment terminal manufacturers. Their response was that they haven't seen this type of fraud outside of a laboratory setting, but that they're working to address the issue, he said.

The people who implemented these protocols, which were developed independently from each other, didn't understand how to do proper key management in both cases, Nohl said.

Fortunately, there is functionality in them that allows older keys to be replaced with new ones and which could be used to provide every terminal with its own unique key, as long as the backend servers are also modified to support such a deployment, the researcher said.

The terminals would still be vulnerable to remote code execution or timing side channel attacks, but at least extracting a key would restrict the abuse to a single terminal, not hundreds of thousands.

In the short term, it's paramount to change existing keys with unique ones for every terminal, but in the longer term better standards should be designed that rely less on the security of the terminals themselves. This could be done by implementing things like public-key cryptography instead of symmetric-key algorithms, Nohl said.