[mrbluecoat]

For those easily excited:

> the exposed root shell does not seem to be as big of a risk as initially feared. ... I could not find any evidence that sensitive data, such as card details, could become compromised this way

A good read for security designers, though.

[LunaSea]

I highly doubt that having root a physical access to a terminal doesn't let you read credit card numbers.

In security, physical access and to a lesser extent root access are equivalent to a guaranteed hack.

[kbolino]

Which is why modern card technologies like chip cards and tap-to-pay don't expose the sensitive numbers at all. The card reader can't steal a number that doesn't exist. Only magnetic stripe cards are so insecure, but the card reader exploited here doesn't even have a magnetic stripe reader.

That having been said, this isn't perfect security. While a chip/tap card is in contact with the reader, it can still be used for fraudulent purposes. And physical access can open the door to other exploits, like trying to break the card's own security or installing a camera to capture images of the card.

[Tijdreiziger]

> […] the card reader exploited here doesn't even have a magnetic stripe reader.

It does, it’s on the right side of the terminal.

https://worldline.com/content/dam/worldline/local/sl-si/docu...

[kbolino]

Good catch, I didn't see it (nor the usual symbol that accompanies it) when I looked at the pictures in the article.

Ideally, the use of these stripes should be completely eliminated, as they can't possibly be secured.

[ianburrell]

Magstripes will start going away in 2027 and should be gone by 2029.

I got impression that the chips used to contain the magstripe info, but I hope they removed that when rollout got going.

Already, merchants take on liability for magstripe transactions.

[kbolino]

It does look like the EMV contact standard allows for falling back to SDA operation, which involves the card just handing over the static application data, which doesn't ever change and can be cloned fairly easily onto a fake card. I don't know if it's the same data as is encoded in the magnetic stripe, but it's not much better. A hacked card reader might be able to exploit this by pretending to only support SDA. On the other hand, cards can mitigate this by not supporting SDA.

[_joel]

It was 2006 in the UK when chip and pin came in. Amazing these things are still in the wild.

[ChocolateGod]

I've seen stores still have a magnetic readers on their machines, but it's used for vouchers, loyalty cards etc or to scan card numbers to issue refunds. But not for payments.

[Tijdreiziger]

I've never seen vouchers or loyalty cards handled on payment terminals here in the Netherlands, they always just have a regular bar code that the cashier scans (or that you scan yourself, at a self-checkout).

Refunds work with chip insertion or contactless.

[zahlman]

> Which is why modern card technologies like chip cards and tap-to-pay don't expose the sensitive numbers at all.

How can they verify the transaction details without those numbers?

[ElectricalUnion]

Your bank holds the public key of the "a certain credit card".

Your thing in the shape of a credit card is a HSM that holds the private key of the "a certain credit card".

A public key (your bank) can verify if a given digital signature generated by a private key (yor card) is valid or not.

The "CC Terminal" is a device that given the inputs (timestamp+value_of_transaction+password), asks the "CC HSM" to generate the signature of said values. "CC HSM" is smart and will ON PURPOSE refuse to generate valid signatures if you're being funny and inputing wrong passwords. Bank can further check if the signature makes sense or not.

Merchant doesn't need to know the public key, the private key, or your password.

[runeks]

> The "CC Terminal" is a device that given the inputs (timestamp+value_of_transaction+password), asks the "CC HSM" to generate the signature of said values.

Which makes a hacked terminal problematic since it can display $1.00 as the amount and actually request the CC HSM to sign a $500 transaction.

[ElectricalUnion]

In a more safe world, the CC HSM would have it's own display and pin entry, to avoid this exact issue. You really can't validate if the terminal is honest.

Because as you rightly pointed out, who said the evil merchant or MitM thief are either MitM'ing the display system, or even have total control of the display system?

[__MatrixMan__]

If this terminal is anything like the ones I've worked with, the device he had a root shell on was only the "same device" as whatever handles the card details in the sense that it lives in the same housing and on the same PCB. They are otherwise two separate computers.

In my case, the "outer" system was Android, so we could use ADB to control it however we liked--with relatively lax security. The "secure board" only took over for the part where it had to handle payment details. In order to test the payment flows we ended up revamping a bunch of 3D printers to hold a stylus instead because the inbuilt android tools couldn't see or touch anything that secure board was doing except for a relatively narrow set of actions like "start payment flow for $X" and "user canceled" and "payment for $X complete".

[emidln]

If you take a look at the binary that decides whether to boot the secure firmware or the tamper screen, it's probably trivial to patch to get the secure firmware running for more inspection. If the point of the linux system is networking and updates, that implies a method for updating the firmware of the secure portion which isn't ideal. If their check for whether it's tampered or not is in the linux userland, I'd be awfully suspect of their firmware update.

[stgl]

The binary that decides whether to boot or go into tamper mode is the "loadercode", which is integrity-protected (I think by a Boot ROM or similar).

The secure firmware can be updated, but it is signed as well.

[emidln]

If the integrity protection is like any of the TPM implementations I've seen, it often doesn't apply once the thing is already in memory, just that when it first loads that it (and everything before it) was attested. This matters a lot once you get into the userland, esp with an older system, since any random off the shelf exploit can be chained into modifying kernel memory with the intention of modifying the binfmt loader for loadercode (or anything else). Of course, if the loadercode is just a thin shim to prod the secure firmware and that's what has the tamper mode rather than being two separate firmwares for controlling the display, you probably can't progress very far.

I'm essentially skeptical that if you have the ability to control the linux root filesystem for a very old linux distro that any other security measures for the linux binaries themselves matter.

[stgl]

Linux does not handle any secure binaries. It only shares a filesystem where the signed and encrypted secure images are. The loadercode verification is not done in Linux, rather the insecure bootloader will read it from the filesystem load it to some memory address, that's it. From there, it is integrity-checked (?) and then executes on the second, secure core. This will then verify and chainload the secure image.

[pelorat]

These are all over the Netherlands, this particular model. They don't accept any credit cards, only debit.

[Ambroos]

That depends on how they're set up. There is no real protocol difference between MasterCard and Visa debit vs credit. Delhaize in Belgium also uses them and you can definitely use all types of credit cards with them (at least Visa/MC and even AmEx).

[zoobab]

And Belgium. I paid this afternoon in a supermarket with this model.

[IshKebab]

Read the article. The actual work is done by another processor that only runs signed images.