Watch infosec bods swipe PINs, magstripe data from card readers live on stage
32c3 Vulnerabilities in two widely deployed payment system protocols can be exploited to steal PINs, spoof transactions, and secretly reroute cash into other accounts.
The security shortcomings affect two protocols: ZVT, used by 80 per cent of German payment terminals, and Poseidon, a dialect of the global payment standard ISO 8583. The vulnerabilities were disclosed by ace researchers Karsten Nohl and Fabian Bräunlein at the 32nd Chaos Communications Congress, held this week in Germany.
ZVT is a protocol between cash registers and card readers, and Poseidon is used between the card readers and merchant banks. Neither require authentication, and ZVT is used over Ethernet – wired and wireless.
Through ARP spoofing, in which an attacker's device masquerades as another system on a network, a crook can receive a copy of the card's magstripe data sent from the card reader. Rather than go straight to the cashier's machine, the data passes through the thief's device, and can be used to clone new cards for fraud.
Clearly, the crim has to be on the same network as the reader and the register to pull this off. If a store uses an insecure wireless network to hook up readers and registers, the infiltration is all too easy; otherwise, it'll have to be an inside job, or a case of physically tampering with shop equipment when no one's looking.
That's magstripe, though. What about chip'n'PIN cards? PINs aren't supposed to leave the reader during a sale, so they can't be stolen by a network eavesdropper. Not so fast. To steal a PIN, a customer simply has to be tricked into typing their number code outside of a transaction.
One way to do this is to show a message on the card reader's screen asking for a PIN to be typed in, and then read back the keys pressed – thus tricking a victim into typing their secret code before a transaction begins.
It is entirely possible for a thief lurking on the network to send a command to a reader to display custom text (such as "Enter PIN: ") and receive the keypad presses. The crook can then tell the reader to carry out a non-PIN transaction to avoid raising any suspicion during the sale.
The receipt will say a PIN was not typed in, but no one checks that. Nohl and Bräunlein claim they were able to complete a number of PIN-less transactions this way while working on their research.
The commands to the reader are supposed to be cryptographically validated using message authentication codes (MACs) generated by the register.
Bräunlein demonstrated that it is possible to work out the correct MAC for a given command using a side-channel timing attack. As the processor in the reader checks a MAC byte by byte, it takes the CPU several cycles longer to confirm that a byte is correct. By measuring the time taken to validate different combinations of MAC bytes, it is eventually possible to calculate the required authentication codes to obtain a customer's PIN alongside the magstripe data – as the researchers demonstrated on stage in front of an audience.
First the buyers, now the sellers
Not only can customers be cheated through these vulnerabilities, but also the merchants themselves.
ZVT allows an attacker to reconfigure the ID numbers of a card reader by using a hardcoded password (which, of course, is available online). These ID numbers are used by banks to route money from cards processed by the reader to the account of the merchant that owns the device.
By reprogramming the ID numbers, money from the processed cards will go to another merchant account – such as one set up by crooks. A reader could be swiped, reconfigured, then put back without a shop owner noticing, and thus sales siphoned off. Think shopshifting rather than shoplifting.
Not just ZVT
Now let's look at Poseidon: a crook can buy a Poseidon payment terminal from the internet, and configure it to pretend to be a particular merchant's systems. To do this, you need three bits of information, which are trivial to obtain.
The first is a service management password, "which only service technicians should have," said Bräunlein, before noting that he was able to find it in documentation online using Google. Payment processors used the same password across all terminals, we're told. Next you need the terminal ID of the merchant you want to screw over, which can be found on its receipts. Finally, you need to carry out a simple brute-force attack to establish the other ID number required – a so-called port number.
With the service password, ID number, and port number, the terminal can be configured to appear to the banks as though it belongs to a particular merchant.
Now you can perform arbitrary refunds, drawing money from the store's funds. As there is no interruption to a merchant's service, the seller will be none the wiser until he or she audits their finances.
Watch the above video of the duo's conference presentation for more details. German banks have shrugged off their research as merely "theoretical." ®