Root shell on a credit card terminal

The OP device tried to mount a USB volume and would have started dropbear if it had been found (presumably in PATH). Maybe maybe maybe…

> Even in dev mode (which requires the vendor to provide IDs of the developers), these things are very much locked down solidly.

Probably different vendors but this has not been my experience.

Have you considered using dm-verity instead of signed binaries?

If I buy a device it sure as shit better give me root.

If a payment system is relying on my local privilige on some random-ass device to authenticate a payment it deserves every garbage request it gets.

> Sure there is: only signed binaries can run, executable filesystem is read-only, data filesystem has noexec bit set, root login is disabled, crippled busybox misses a lot of functionality, keys are loaded from a secure area on bootup, master key injection only available when loading at the factory, bootup itself is more or less secure, tamper detection blanks the chip, etc.

Sounds good. Has anyone been hired to attempt to attack the device and find vulnerabilities?

I did somehow have two different cards (an Amex and a Visa) compromised at the same time about two months ago, and I do wonder if it was some kind of skimmer setup - if it was just one of them then I'd assume it was just some online store I'd used it at that had been hacked, but I've not used both those cards on the same sites.

I got a notification asking me to confirm a transaction on the Visa and then looked in my app and found they'd actually got another transaction pending at a hotel. I called them up and the hotel said they would "kick out the guests" and refund me. Not sure why they didn't want to call the police on them, because when I called later they said I should report it to the police, but all of the transactions had been refunded so I literally had zero loss and there was nothing really to report... It was them who'd provided the services and suffered the loss, the hotel should have had the police remove them!

Anyway, on the same day the Visa had been used at the hotel, I also had some fraudulent transactions on the Amex, although most of them seemed to be automatically refunded by the vendor themselves (so maybe it was flagged by the vendor's anti-fraud mechanisms and refunded to avoid a chargeback from American Express) before I cancelled the card. They'd tried three times with a similar amount and they'd all refunded.

The other weird thing was that the hotel that the Visa was used at claimed that it had to be a card-present transaction or in a digital wallet, but I didn't get any notification about it being enrolled in a digital wallet and I always had the physical card with me. So not sure if that was mistaken or BS or if they managed to somehow fake the digital wallet.

But yeah it didn't work out for them because I caught the transaction the same day they'd checked in to a hotel with the card and then both were cancelled that day...

I remember when contactless was introduced in France, someone from the CB bank card group (https://en.m.wikipedia.org/wiki/CB_Bank_Card_Group) said that contactless was secure because you are insured. At that time France was already using chip+pin for a while.

At the end of the day the money only goes from one bank account to another, account can be frozen, charge reversed, ... So you just need to secure the POS enough that user feel safe to use it and there is a low number of people that can hack them and are willing to risk prison.

> Yes you can walk around and make those transactions, what comes after (and the setup you had to do before) is the problem

I mean with the amount of stolen card details routinely traded and used successfully (at least for a while) and with how little crime like that is investigated or punished in some jurisdictions, I dunno...

Still it's not quite as simple as "taking the money from your card" like said crackpots think.

Didn't people manage to present a remote card (i.e. in a mark's pocket) to a legitimate terminal through an NFC tunnel of sorts? Limited to no pin required amounts, but still.

Aren't the contracts and regulations holding back the honest people only? But not those who violate contracts and regulations, like the dishonest ones?

> If those keys leaked, someone could spoof legitimate transactions.

You mean, whenever those keys leak. It's not that hard to do, see e.g. https://media.ccc.de/v/32c3-7368-shopshifting#t=2207

Aren't credit cards nowadays basically physical private keys? IIRC transactions are one-time payloads signed specifically for that operations, so intercepting that won't help you if I'm not mistaken about how cards work nowadays.

Someone with a root access to a card reader could just make it collect CC details with every transaction, no caches needed. It could also make certain transactions "temporarily fail", while siphoning a certain amount of funds to another, legit-looking, merchant under the hood.

There are much easier ways to skim cards than hacking the terminal.

I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware.

That's happened at least several times already.

I believe breached PoS terminals were what happened in the big Target hack.

This story about a physical card reader checker to detect skimmer devices was interesting and posted here a couple years back.

https://tech.target.com/blog/cybersecurity-easysweep

https://news.ycombinator.com/item?id=36788831

I believe GP is confused.

You can read a card (stripe) with one of those cheap readers. The magnetic stripe is not encrypted and you can extract the card number (PAN), expiration date, and cardholder name. Some other less important bits too. You cannot extract the CVV this way, but that is not required for transactions.

Most cards are EMV now. That data is encrypted and it's read/write. These keys can leak, putting you back into a similar state as if you'd read the card via magnetic stripe.

But no amount of card reading gives you the ability to submit transactions to the network. For that, you'd need merchant credentials for their gateway or processor, and you'd usually need to have a presence on the merchant's network (to get through the upstream firewall).

These are all achievable things. Doing so gets you the ability to create transactions against the card. These transactions will be submitted to the network and approved or declined. If approved, funds will settle from the issuing bank to the merchant bank, possibly in multiple steps.

I'm oversimplifying a bit, but the essential point is that funds will settle to the merchant's bank account, not yours. You can cause some headaches, but you cannot steal money.

The compromise of a credit card terminal is only interesting because it gives an attacker the ability to steal the card details for all cards that are subsequently used at the compromised terminal. They can be saved and retrieved later, or sent out to a C&C server, etc. Then these card details can be used for all the usual types of credit card fraud.

I agree that this isn't how it works.

The first thing to understand at an even higher level about payment cards is that they have always had two separate and barely related components, Authorisation and Settlement.

Authorisation is concerned with whether this specific transaction has been approved in some sense by a card issuer. Authorization today is relatively high tech, there's somewhat decent cryptography, tamper resistance, uniqueness = they really care - and that's because when Authorization problems occur the banks might lose money, which they hate.

Settlement is "just" moving the money from one customer to another. $123.45 from Jim Smith to Terrible Goose Inc, done. This is very mid-late-20th century technology, we're not talking pieces of paper and scribbly hand writing, but fixed width ASCII fields on magnetic tape is fine - it's the customer's money so the banks don't care more than legally required.

Settlement replays are how you get "accidents" where a big store's customers all get charged twice for a whole day - the associated Authorizations can't be replayed, that's the banks money at risk - but the settlements aren't protected.

Merchants can, and some do, choose not to care about Authorization. In a huge business it could make sense to eat say 2% of sales as undetected fraud (ie you never receive payment) rather than have any transactions fail. If you operate a food truck using a terminal to take $1000 per day on your iPhone the people who supply your terminal may not let you opt out because that's risk they don't want. But if Jeff Bezos or Doug McMillon makes more without Auth he's turning it off.

It's over the Internet, because you're not going to run a dedicated fiber to every card reader. But it's not over the unprotected internet; your card reader will establish a VPN connection of sorts, or at least talk via an encrypted channel (think TLS) is you use e.g. a Square terminal.

Not that a random person can hit these endpoints, unauthenticated, and try to run a transaction.

I mean, maybe they don't have an open API, but they sure do have an API on the internet. Surely the payment terminals are communicating with the issuing bank in someway, perhaps over an interface of some kind.

I believe what this comment is getting at is that making fake transactions is useless without a connection to a bank that will execute them.

Maybe today, when the line between a Credit and a Debit card has gotten significantly blurrier (except in the US).

I definitely remember making an _offline_ payment with an AMEX card at a restaurant in the UK some 10 years ago.

Also, most airlines that take payments on board also run the terminals in offline mode.

There must be some mapping of BIN codes and whether to allow an offline transaction.

All readers are charged for a day minimum after a festival before I pull the power. I then normally power them up at least a week before the next event so I can update them all and check that no more have randomly died on me. I keep a healthy buffer of devices so that I can replace them without paying for express shipping from Stripe which saved me for the last event I did where I had 6 of them die (before that pre-event check I only had the 1 bad NFC reader from the previous year).

I have to assume that one of the hard-shell cases got thrown around a little too much which caused 4 readers to go into tamper mode. 3 of the tamper mode readers were in the same case but the other was in my nicest case and still had the issue ("nicest" = custom made case vs pick-and-pluck-style).

The tampers I can somewhat understand (still just so odd to have 4 die "at once"), maybe they did get banged up, but the failed NFC and not holding a charge issues are less acceptable to me given the time/use.

I had the same idea, but no, I tried with a second, untampered one and I also got a working shell. So it does not seem to be dependent on the tamper state.

> Was my guess as well, maybe it's even possible to use it to flash new keys so the device can be used again?

What keys would you flash them with? Anything encrypted with your "new" keys can't be decrypted on the other end of the transaction anyway, so what would be the point?

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.

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".

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.

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

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

Keep in mind that no tamper mode will be set if you use the external debug interface. If Linux is used for networking then maybe you could MITM payments.

And as a user, I have absolutely no way of distinguishing this from a device that had all secure features removed, and is running a random Android that proxies the NFC or chip data to a real reader, siphoning off what they can, while my PIN gets proxied by a human typing it into the real reader in real time. All I'd notice is a second or so of latency.

Also, it is possible to open other apps and the notification centre. And unsurprisingly the entire device is terribly laggy.

Specifics of this hack aside, I wish I could solder like that!

Actually, putting your card on your phone is a better protection against theft : they cannot be used without biometric identification, can be remotely revoked and you can still keep your plastic cards as backup.

I could easily live without it and I wouldn’t even consider it to be an important gesture for my next phone but it’s pretty useful when you have it.

Also, idk for Android but on iPhone it’s faster than plastic cards and more secure.

But I hope plastic cards are there to stay because that’s yet another thing locking us into the iOS/Android duopoly.