11 ms·

Root shell on a credit card terminal

840 points by stgl 1y ago

calltrace 1y ago
Great story, how long did this take you?
Lord_Zero 1y ago
Any way to reset the tamper protection from software?
- reliablereason 1y ago
  Hopefully the important private keys that is used to identify the terminal are erased when the tamper is activated.
  - drdaeman 1y ago
    I don’t know much about those terminals, but the screenshot hints at that (key=zeroes part), and then according to the diagram it waits for USB to flash new secure firmware and keys in case the terminal had to be serviced. This root shell is probably not a security issue - and maybe even meaningfully user-accessible (for some fancier network configurations or diagnostics) - as, I suspect, it’s nothing more than a glorious modem for a stream of encrypted and authenticated data, plus a firmware updater (likely useless without a valid signature) - it could be potentially pretty much the same as hacking the upstream router. Sensitive (so there’s probably a sticker intended) but not something that breaks device’s security.
Liftyee 1y ago
Bravo! I love thinking of ways to exploit and circumvent hardware restrictions like the extensive tamper protection here, but it seems I'd assumed that once they were triggered it was game over. Apparently not so - still plenty of interesting bits left over to poke around with. Makes sense that the secure part gets properly disabled though, otherwise I'd lose all confidence in their designers.
- lxgr 1y ago
  That's possibly still true for the hardened processor: As TFA notes, that's not what was compromised here. > [...] only text strings seem to be passed to a binary (display_tool), that issues some inter-processor messages. The same goes for the key pad or the card reader itself. I could not find any evidence that these peripherals could be accessed directly from Linux. > Instead, there is an entirely separate processor, refered to as mp1, that seems to handle all the “secure” stuff, like handling the card, getting the pin and showing information on the screen. The “insecure” Linux, running on the second processor, mp2, only handles the networking, the updating, and the business logic.
- fredthestair 1y ago
  From the description it sounded like the linux side may play some role in tamper event handling, but hopefully it can just also see it has occurred, otherwise getting a root shell first may lead to an opportunity to prevent the tamper event from clearing security keys.
mrbluecoat 1y ago
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 1y ago
  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.
  - deleted 1y ago
    [deleted]
  - kbolino 1y ago
    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.
    - zahlman 1y ago
      > 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 1y ago
        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.
dedicate 1y ago
I'm curious: with that level of access, even if you can't directly grab PANs, what are the practical limitations? Could they, say, intercept user input before encryption, or cause targeted denials of service?
- stgl 1y ago
  I cannot tell for sure. I didn't have time to really look at the Linux applications and what they do exactly. My guess is that most of the sensitive stuff is done on mp1 (reading the card, verifying the pin etc.) and the Linux just acts as untrusted relay to the network. Denial of service should be possible in the sense that it could just put the system in a boot loop.
  - robocat 1y ago
    > Denial of service should be possible That's sounds like an overcomplicatedengineer solution. The 10x engineer uses a hammer to deny service. Aside: I'm an artist-engineer. I like the performance art of using an oversized hammer to solve a problem that isn't obviously solved using a hammer - and I love the discovery process when my aims fail.
- Hilift 1y ago
  Devices such as this are cloned and used for fraud. It can be done without triggering any of the sensors. Secret service confiscated multiple cloned devices in an enforcement operation recently in NYC. "Recent incidents in the U.S. include criminals committing fraud through processing fraudulent return transactions. As part of the fraud scheme, criminals obtain Point-of-Sale (POS) devices—either from an acquirer or agent while posing as a merchant, from online resellers or auctions, or through theft—and program the POS devices with the credentials of a legitimate merchant, thus effectively cloning the unsuspecting merchant’s actual POS device. Criminals use the cloned POS devices to..." https://cardsystems.com/point-of-sale-clone-fraud-activity/ https://cardsystems.com/point-of-sale-clone-fraud-activity/
zzzeek 1y ago
is the rooted mp2 subsystem responsible for acquiring the tamper state from the hardware that's passed off to the mp1 system? the diagram seems to indicate this is the case. Why not then try to disable the tamper signal and get mp1 to boot up with the device opened?
- stgl 1y ago
  No, I don't think so. I think the tamper logic is implemented in hardware and cannot be easily fooled. It seems like both mp1 and mp2 access memory-mapped registers of the tamper subsystem to check its status (and other hardware system stuff like reset reason etc.) However, I am assuming that there is a way to gain write access to the hardware registers from Linux. After all, the manufacturer has the ability to "un-tamper" devices and there is this nor_update tool in Linux that might be able to do it. But my guess would be that first a key has to be loaded through some authenticated interface in order to unlock that functionality.
  - tomsonj 1y ago
    Reminds me of "Every 10-ft wall can be defeated with an 11-ft ladder"
  - qmarchi 1y ago
    Disc: Former Visa Employee Generally, these devices will use the mp1 to do all of the cryptographic operations around the devices. The biggest part of this is the keys defined between the terminal and the acceptance gateway (something like CyberSource or Authorize.net). When the temper protection is tripped the keys that are used are immediately dropped from RAM and you can't recover them, they have to manually be input into the device again to reset the tamper protection. (Side Note: keys are specific to a merchant. If you're able to extract them, it limits the blowback.)
halpow 1y ago
If you want to try easy mode, check out those newfangled android-based credit card terminal. I bet they're much more rewarding, especially since you tap your pin on the screen. Juicy.
- jeroenhd 1y ago
  That'd get you the PIN quite easily, but if they're designed the same way (with all the important bits being handed off to a secure secondary processor) you still wouldn't be able to do much with the card as modern cards do a whole load of cryptography on-card to prevent stuff like this. The attack would only work on terminals where every payment option but the magnetic card reader is broken, but those should give off skimmer alert alarm bells before you ever see a PIN prompt.
- user_7832 1y ago
  I'm not sure which type of android terminals you have where you are, but in India they seem to be running Android Oreo (support ended in Jan '21). Yummy!
  - user_7832 1y ago
    Also, it is possible to open other apps and the notification centre. And unsurprisingly the entire device is terribly laggy.
- _djo_ 1y ago
  The PIN data is still encrypted even when displayed on a touch pad, using user interfaces controlled by firmware running in the trusted zone. So the applications in between, that would be accessible in an attack like this, can't view the PIN.
- bmurray7jhu 1y ago
  The touch controller is generally connected to a MUX controlled by the security processor. When entering sensitive data (PIN/PANs), the touch controller output is routed directly to the security processor, bypassing any Android-derived OS responsible for the GUI.
thenthenthen 1y ago
These are everywhere in Europe. Not sure about Switzerland, but credit cards are not really owned or used in much of the Europe I know. I would call it a POS, point of sale (system), these things can read all kinda of cards. Nevertheless, nice write up!
- jajko 1y ago
  Oh yes they are. I detest having to juggle all those cards in my wallet, already have tons for various reasons (not just payment stuff), so no room for ie debit ones. Dont see the appeal of putting even more stuff into phone or ewatches (prefer good mechanical ones), losing it would be catastrophe enough as it is for privacy. But thats me.
  - pjerem 1y ago
    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.
ComputerGuru 1y ago
The (compromised) Linux decides whether to load the “compromised mode” code or the mp1 secure system? Sounds like an avenue to explore. It says the bootloader itself is secure, but that doesn’t mean much if it’s being loaded into a compromised environment, depending on where it is actually being executed. I guess the coprocessor could be considered a Secure Enclave of Sorts, but the fact that Linux could load a separate bootloader and run that (somehow) is of concern.
- stgl 1y ago
  No, it cannot load a separate bootloader. I tried to tamper with the loadercode (the "secure" bootloader), but it wouldn't boot. So I am guessing there is some third party (boot ROM) that verifies it. Also, I think Linux always loads loadercode + mp1.img, regardless of the tamper state. The different code paths depending on tamper state are taken within the (integrity protected) loadercode.
  - ComputerGuru 1y ago
    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.
    - _djo_ 1y ago
      The card details and payment are encrypted and then signed by the firmware running in the secure/trusted zone, using public keys provided by the acquirer.
londons_explore 1y ago
It's also possible that the root shell is opened up when the tamper seal is triggered. Ie. The system is either in secure mode (with all necessary crypto keys for operation), or it is in insecure mode with a root shell open for debugging and failure analysis, but that transition also deleted the critical private keys.
- fp64 1y ago
  Was my guess as well, maybe it's even possible to use it to flash new keys so the device can be used again? Now I am curious if I can find a terminal myself, if they are actually getting phased out it might not be too difficult to find a used one...
  - stgl 1y ago
    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.
    - numpad0 1y ago
      wtf? are you saying the shell can be hypothetically drilled for root access without triggering the tamper detection? that'll be ACTUALLY bad...
      - fp64 1y ago
        I think in the article it was even stated that the port is even accessible without drilling!
  - lelanthran 1y ago
    > 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?
avipars 1y ago
Can it run doom?
- blooalien 1y ago
  > Can it run doom? Almost certainly yes.
  - Bad_CRC 1y ago
    I expect an updated post with it running doom as the author is not strange to it: https://stefan-gloor.ch/voip-phone-hack https://stefan-gloor.ch/voip-phone-hack
    - account42 1y ago
      It sounds like the Linux system he got access to doesn't control the screen though so this might not be that easy.
joshstrange 1y ago
Aside from the fact that I wouldn't know what I was looking at, I've been tempted to crack open one of the Stripe M2 readers I have and look inside. Unfortunately, out of 36 readers that I bought, 7 have "died" (2 won't hold a charge, 1 won't scan NFC, and 4 report "tampered"). That attrition rate is pretty bad on the surface but it doesn't tell the whole story of course, how often were they used? How old are they? The answer to those questions is much more damning. The devices are 1-3 years old (I bought them over time) and have been used a max of 9 days total [0]. Yes, 9 days _total_ of use and 7 of 36 readers failed in some fashion. Oh, and the readers are all kept in hardshell cases with foam inserts (1 slot per reader) whenever they are moved. Needless to say, I'm not a huge fan of the M2 readers but they are still the best option for me :/ [0] Some background, my company handles festival payments. We travel to events and handle the in-person payments (most happens on web/app) with iPads+M2 Readers. That's why there are so few "days of use" over 3 years.
- mrbuttons454 1y ago
  I'd be sure to charge them before storing them for the next show. Most batteries don't like being stored for long periods in a low SoC state. And I'm sure the tamper requires a functional battery.
  - joshstrange 1y ago
    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.
absurdo 1y ago
For the young players: this is what hacker in “Hacker News” stands for. This is 101 and it’s very simply explained which makes it a great step by step example of a typical journey. Hack-a-day is full of these if you want more. The author is clearly curious and leads in knowing a lot to begin with. The work-behind-the-work is looking up data sheets for the chips involved, desoldering them without damaging them, in the case of memory resoldering with hookup wire and hopefully its access is slow enough that it can work fine over the length of the wire, following hunches, trying things, and knowing (for next time) the possibility of using a pinhole camera or something of the sort when drilling shallow holes and looking through for tamper traces to avoid in further drills, if so desired be. As others have mentioned, it would be interesting if the author stuck in and got past the tamper checks to see if it would work as normal. Oh well!
- deleted 1y ago
  [deleted]
- deleted 1y ago
  [deleted]
- zidoo 1y ago
  Amen for the first sentence. One more LLM wrapper today, and I would die.
  - account-5 1y ago
    It's so tiresome and is slowly ruining HN for me personally.
    - deleted 1y ago
      [deleted]
  - lucianbr 1y ago
    Hear hear.
  - paulddraper 1y ago
    Or UI pontifications
Disposal8433 1y ago
You can make fake debit/credit card transactions on a $2 USB card reader. All the specs are here and the protocol is public and documented (IIRC 5000 pages in a lot of PDF, it's a pain in the ass to read). But to validate those transactions, you must send them to the bank over the internet, and you'll get a visit from the feds/FBI/whatever if you do it. There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.
- csinode 1y ago
  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 does seem to be difficult/impossible in this specific case, but it means research in this area is relevant.)
  - christina97 1y ago
    There are much easier ways to skim cards than hacking the terminal.
    - account42 1y ago
      Not without leaving physical evidence.
  - rockbruno 1y ago
    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.
    - literalAardvark 1y ago
      Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance. And maybe even send the money to a different account.
ofjcihen 1y ago
The look into these is neat but…why immediately open it up and trigger the tamper state? Did they not know most readers would have one? Any real testing happening in the tamper state might be meaningless. Perhaps the shell is available after the tamper state triggers for resetting purposes. It just seems like opening it would be the last thing you would try.
- stgl 1y ago
  Well, I felt like I first had to get a feeling for what I am working with. Hardware, what SoC, interfaces, flash etc... Otherwise I am too much in the dark. But sure, in hindsight I could've just tapped the debug connector and could have been done with it. No, I got a shell on second, untampered one, as well.
  - allenrb 1y ago
    Specifics of this hack aside, I wish I could solder like that!
_trampeltier 1y ago
I know they run Linux, once a such terminal updated and rebooted when I would pay. It was in the evening rush hour on in a shop. The other person before me paid, then the salesperon scanded my things and suddenly an update was on the screen.
bill_mcgonigle 1y ago
What a nice writeup! Just curious - what kind of wire do you use to solder on the pins - enameled? I wonder if they offer their customers source to keep the Busybox folks happy?
- stgl 1y ago
  Yes, 0.1 mm diameter enameled copper wire. Chasing GPL violations sounds like a fun hobby :)
  - zoobab 1y ago
    I think US based SFLC has budgets if you request it to enforce the GPL. Pre-OpenWRT days I was maintained a Linux distro ISL3893 that ended up in court in Germany, the first GPL enforcement: http://isl3893.wikidot.com/ http://isl3893.wikidot.com/ "17 apr 2004 — GPL testing in court by the Netfilter/Iptables team, due to refuse to give source code of the Sitecom WL-122 (isl3893 based!). In the same time, some source code has appeared on the webserver of Sitecom."
jdefr89 1y ago
UART always the first place I look…
- Sakthimm 1y ago
  My thoughts exactly. Why desolder the flash chip before probing for UART? Still, impressive work.
  - stgl 1y ago
    Thanks! Yep, I feel foolish. I just could not imagine it would be that easy on a locked-down terminal. But I learned for next time :)
fdspopofe 1y ago
[dead]
SamuelAdams 1y ago
Alright sorry if this is dumb but how does the OP know about all this?
tialaramex 1y ago
Light Blue Touchpaper https://www.lightbluetouchpaper.org/ https://www.lightbluetouchpaper.org/ might well be interested in this work, the card payment tech is something they spent lots of time looking at and they tend to have a more realistic assessment of where the weaknesses might be that the industry which tends to see itself as infallible.
deleted 1y ago
[deleted]
wkat4242 1y ago
Very interesting. These terminals are super common in the Netherlands also. The exact same ones. Kudos to the author, rigging up a BGA chip is no small feat. I love this kind of curiosity (one of the reasons I like HN)
kriro 1y ago
Excellent article. Reminds me of a CCC talk in the early 2000s where an enthusiast checked ATMs of different banks across Germany and most where running unpatched Windows 98 (I think). If my memory is correct it was also very easy to get physical access. I believe removing a couple of normal screws got you to an ethernet port or something similar.
israrkhan 1y ago
Once he got the root shell on "insecure" processor, that could have been used as an attack point for the secure processor. It would be much more interesting to pwn the secure processor from insecure Linux OS.
grishka 1y ago
These are (were?) popular in Finland and confused me a lot every time I visited. The NFC reader in them is on the side, which is very unusual compared to the kinds of terminals I'm used to, which have it in the screen so you just tap your card/phone on the screen.
davedx 1y ago
I used to work with set-top-boxes for a big media corporation, those also had the debug serial port. I remember it being fiddly but also absolutely vital to be able to do any useful work with the STB's. It's quite eye opening now reading this to see that they're also a huge potential security hole (in the right hands), unless everything is locked down with the second secure processor like in this setup.
ttkari 1y ago
Reading about all the tamper detection on the device makes me wonder what would be the easiest way to trigger the tamper mode. After all, being able to do that on just a handful of devices would be an efficient denial of service attack on a retail location when the majority - and sometimes all - of payments go through these things.
- neop1x 1y ago
  Dropping it on the floor or pouring water on it.
anemic 1y ago
I once had the (dis)pleasure of working with these Yomani terminals. I got a development unit (with red text "DO NOT PAY" on the side). I plugged it in my home internet which has a public ip with dhcp just to get it quickly online and keep it out of my internal home network. The next day I got a call from my ISP saying I had a compromised machine in my network with malware. I was like WTF?! and they gave me the mac address and it was the Yomani terminal! I promptply unplugged it from the network and started investigating. Indeed, this development unit had a telnet(!) port open and root login without password was possible. So, having a wide open telnet port on a public ip and it's just a matter of minutes until someone uploads a generic arm malware onto it. I returned the terminal to the vendor with explanation but never got a followup. Lesson learned: never attach anything to public internet, even if it looks secure. I guess Atos Worldline really doesn't like root passwords.
- stgl 1y ago
  Very interesting!
rswail 1y ago
So a few things: 1. Under the current EMV standards for terminals, the NFC and/or chip connection is via a secure element that protects the data in the transaction both in transit and at rest. 2. The transaction is protected in transmission not only by TLS encryption, but with an individual HMAC generated using a key that is derived from a base key that is unique to the terminal and merchant. The interaction with the card is relatively read-only. There is a "dynamic CVV" that is generated on the card in chip/contactless transactions that adds some security, however, the data on the card is mostly open (PAN, expiry date, CC name etc). The CHI (cardholder information) has to be maintained in an encrypted state at all times. The business processes (where this article found the root shell) is not involved in the actual card or transaction security. It communicates with the secure element via a protocol that allows it to specify the amount and other details for a transaction, but the authorization (PIN or otherwise) and encrypted messages are entirely within the secure element.

840 points by stgl 1y ago

calltrace 1y ago

Great story, how long did this take you?

Lord_Zero 1y ago

Any way to reset the tamper protection from software?

reliablereason 1y ago
Hopefully the important private keys that is used to identify the terminal are erased when the tamper is activated.
- drdaeman 1y ago
  I don’t know much about those terminals, but the screenshot hints at that (key=zeroes part), and then according to the diagram it waits for USB to flash new secure firmware and keys in case the terminal had to be serviced. This root shell is probably not a security issue - and maybe even meaningfully user-accessible (for some fancier network configurations or diagnostics) - as, I suspect, it’s nothing more than a glorious modem for a stream of encrypted and authenticated data, plus a firmware updater (likely useless without a valid signature) - it could be potentially pretty much the same as hacking the upstream router. Sensitive (so there’s probably a sticker intended) but not something that breaks device’s security.

Liftyee 1y ago

Bravo! I love thinking of ways to exploit and circumvent hardware restrictions like the extensive tamper protection here, but it seems I'd assumed that once they were triggered it was game over. Apparently not so - still plenty of interesting bits left over to poke around with. Makes sense that the secure part gets properly disabled though, otherwise I'd lose all confidence in their designers.

lxgr 1y ago
That's possibly still true for the hardened processor: As TFA notes, that's not what was compromised here. > [...] only text strings seem to be passed to a binary (display_tool), that issues some inter-processor messages. The same goes for the key pad or the card reader itself. I could not find any evidence that these peripherals could be accessed directly from Linux. > Instead, there is an entirely separate processor, refered to as mp1, that seems to handle all the “secure” stuff, like handling the card, getting the pin and showing information on the screen. The “insecure” Linux, running on the second processor, mp2, only handles the networking, the updating, and the business logic.
fredthestair 1y ago
From the description it sounded like the linux side may play some role in tamper event handling, but hopefully it can just also see it has occurred, otherwise getting a root shell first may lead to an opportunity to prevent the tamper event from clearing security keys.

mrbluecoat 1y ago

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 1y ago
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.
- deleted 1y ago
  [deleted]
- kbolino 1y ago
  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.
  - zahlman 1y ago
    > 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 1y ago
      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.

dedicate 1y ago

I'm curious: with that level of access, even if you can't directly grab PANs, what are the practical limitations? Could they, say, intercept user input before encryption, or cause targeted denials of service?

stgl 1y ago
I cannot tell for sure. I didn't have time to really look at the Linux applications and what they do exactly. My guess is that most of the sensitive stuff is done on mp1 (reading the card, verifying the pin etc.) and the Linux just acts as untrusted relay to the network. Denial of service should be possible in the sense that it could just put the system in a boot loop.
- robocat 1y ago
  > Denial of service should be possible That's sounds like an overcomplicatedengineer solution. The 10x engineer uses a hammer to deny service. Aside: I'm an artist-engineer. I like the performance art of using an oversized hammer to solve a problem that isn't obviously solved using a hammer - and I love the discovery process when my aims fail.
Hilift 1y ago
Devices such as this are cloned and used for fraud. It can be done without triggering any of the sensors. Secret service confiscated multiple cloned devices in an enforcement operation recently in NYC. "Recent incidents in the U.S. include criminals committing fraud through processing fraudulent return transactions. As part of the fraud scheme, criminals obtain Point-of-Sale (POS) devices—either from an acquirer or agent while posing as a merchant, from online resellers or auctions, or through theft—and program the POS devices with the credentials of a legitimate merchant, thus effectively cloning the unsuspecting merchant’s actual POS device. Criminals use the cloned POS devices to..." https://cardsystems.com/point-of-sale-clone-fraud-activity/ https://cardsystems.com/point-of-sale-clone-fraud-activity/

zzzeek 1y ago

is the rooted mp2 subsystem responsible for acquiring the tamper state from the hardware that's passed off to the mp1 system? the diagram seems to indicate this is the case. Why not then try to disable the tamper signal and get mp1 to boot up with the device opened?

stgl 1y ago
No, I don't think so. I think the tamper logic is implemented in hardware and cannot be easily fooled. It seems like both mp1 and mp2 access memory-mapped registers of the tamper subsystem to check its status (and other hardware system stuff like reset reason etc.) However, I am assuming that there is a way to gain write access to the hardware registers from Linux. After all, the manufacturer has the ability to "un-tamper" devices and there is this nor_update tool in Linux that might be able to do it. But my guess would be that first a key has to be loaded through some authenticated interface in order to unlock that functionality.
- tomsonj 1y ago
  Reminds me of "Every 10-ft wall can be defeated with an 11-ft ladder"
- qmarchi 1y ago
  Disc: Former Visa Employee Generally, these devices will use the mp1 to do all of the cryptographic operations around the devices. The biggest part of this is the keys defined between the terminal and the acceptance gateway (something like CyberSource or Authorize.net). When the temper protection is tripped the keys that are used are immediately dropped from RAM and you can't recover them, they have to manually be input into the device again to reset the tamper protection. (Side Note: keys are specific to a merchant. If you're able to extract them, it limits the blowback.)

halpow 1y ago

If you want to try easy mode, check out those newfangled android-based credit card terminal. I bet they're much more rewarding, especially since you tap your pin on the screen. Juicy.

jeroenhd 1y ago
That'd get you the PIN quite easily, but if they're designed the same way (with all the important bits being handed off to a secure secondary processor) you still wouldn't be able to do much with the card as modern cards do a whole load of cryptography on-card to prevent stuff like this. The attack would only work on terminals where every payment option but the magnetic card reader is broken, but those should give off skimmer alert alarm bells before you ever see a PIN prompt.
user_7832 1y ago
I'm not sure which type of android terminals you have where you are, but in India they seem to be running Android Oreo (support ended in Jan '21). Yummy!
- user_7832 1y ago
  Also, it is possible to open other apps and the notification centre. And unsurprisingly the entire device is terribly laggy.
_djo_ 1y ago
The PIN data is still encrypted even when displayed on a touch pad, using user interfaces controlled by firmware running in the trusted zone. So the applications in between, that would be accessible in an attack like this, can't view the PIN.
bmurray7jhu 1y ago
The touch controller is generally connected to a MUX controlled by the security processor. When entering sensitive data (PIN/PANs), the touch controller output is routed directly to the security processor, bypassing any Android-derived OS responsible for the GUI.

thenthenthen 1y ago

These are everywhere in Europe. Not sure about Switzerland, but credit cards are not really owned or used in much of the Europe I know. I would call it a POS, point of sale (system), these things can read all kinda of cards. Nevertheless, nice write up!

jajko 1y ago
Oh yes they are. I detest having to juggle all those cards in my wallet, already have tons for various reasons (not just payment stuff), so no room for ie debit ones. Dont see the appeal of putting even more stuff into phone or ewatches (prefer good mechanical ones), losing it would be catastrophe enough as it is for privacy. But thats me.
- pjerem 1y ago
  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.

ComputerGuru 1y ago

The (compromised) Linux decides whether to load the “compromised mode” code or the mp1 secure system? Sounds like an avenue to explore. It says the bootloader itself is secure, but that doesn’t mean much if it’s being loaded into a compromised environment, depending on where it is actually being executed. I guess the coprocessor could be considered a Secure Enclave of Sorts, but the fact that Linux could load a separate bootloader and run that (somehow) is of concern.

stgl 1y ago
No, it cannot load a separate bootloader. I tried to tamper with the loadercode (the "secure" bootloader), but it wouldn't boot. So I am guessing there is some third party (boot ROM) that verifies it. Also, I think Linux always loads loadercode + mp1.img, regardless of the tamper state. The different code paths depending on tamper state are taken within the (integrity protected) loadercode.
- ComputerGuru 1y ago
  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.
  - _djo_ 1y ago
    The card details and payment are encrypted and then signed by the firmware running in the secure/trusted zone, using public keys provided by the acquirer.

londons_explore 1y ago

It's also possible that the root shell is opened up when the tamper seal is triggered. Ie. The system is either in secure mode (with all necessary crypto keys for operation), or it is in insecure mode with a root shell open for debugging and failure analysis, but that transition also deleted the critical private keys.

fp64 1y ago
Was my guess as well, maybe it's even possible to use it to flash new keys so the device can be used again? Now I am curious if I can find a terminal myself, if they are actually getting phased out it might not be too difficult to find a used one...
- stgl 1y ago
  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.
  - numpad0 1y ago
    wtf? are you saying the shell can be hypothetically drilled for root access without triggering the tamper detection? that'll be ACTUALLY bad...
    - fp64 1y ago
      I think in the article it was even stated that the port is even accessible without drilling!
- lelanthran 1y ago
  > 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?

avipars 1y ago

Can it run doom?

blooalien 1y ago
> Can it run doom? Almost certainly yes.
- Bad_CRC 1y ago
  I expect an updated post with it running doom as the author is not strange to it: https://stefan-gloor.ch/voip-phone-hack https://stefan-gloor.ch/voip-phone-hack
  - account42 1y ago
    It sounds like the Linux system he got access to doesn't control the screen though so this might not be that easy.

joshstrange 1y ago

Aside from the fact that I wouldn't know what I was looking at, I've been tempted to crack open one of the Stripe M2 readers I have and look inside. Unfortunately, out of 36 readers that I bought, 7 have "died" (2 won't hold a charge, 1 won't scan NFC, and 4 report "tampered"). That attrition rate is pretty bad on the surface but it doesn't tell the whole story of course, how often were they used? How old are they? The answer to those questions is much more damning. The devices are 1-3 years old (I bought them over time) and have been used a max of 9 days total [0]. Yes, 9 days _total_ of use and 7 of 36 readers failed in some fashion. Oh, and the readers are all kept in hardshell cases with foam inserts (1 slot per reader) whenever they are moved. Needless to say, I'm not a huge fan of the M2 readers but they are still the best option for me :/ [0] Some background, my company handles festival payments. We travel to events and handle the in-person payments (most happens on web/app) with iPads+M2 Readers. That's why there are so few "days of use" over 3 years.

mrbuttons454 1y ago
I'd be sure to charge them before storing them for the next show. Most batteries don't like being stored for long periods in a low SoC state. And I'm sure the tamper requires a functional battery.
- joshstrange 1y ago
  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.

absurdo 1y ago

For the young players: this is what hacker in “Hacker News” stands for. This is 101 and it’s very simply explained which makes it a great step by step example of a typical journey. Hack-a-day is full of these if you want more. The author is clearly curious and leads in knowing a lot to begin with. The work-behind-the-work is looking up data sheets for the chips involved, desoldering them without damaging them, in the case of memory resoldering with hookup wire and hopefully its access is slow enough that it can work fine over the length of the wire, following hunches, trying things, and knowing (for next time) the possibility of using a pinhole camera or something of the sort when drilling shallow holes and looking through for tamper traces to avoid in further drills, if so desired be. As others have mentioned, it would be interesting if the author stuck in and got past the tamper checks to see if it would work as normal. Oh well!

deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
zidoo 1y ago
Amen for the first sentence. One more LLM wrapper today, and I would die.
- account-5 1y ago
  It's so tiresome and is slowly ruining HN for me personally.
  - deleted 1y ago
    [deleted]
- lucianbr 1y ago
  Hear hear.
- paulddraper 1y ago
  Or UI pontifications

Disposal8433 1y ago

You can make fake debit/credit card transactions on a $2 USB card reader. All the specs are here and the protocol is public and documented (IIRC 5000 pages in a lot of PDF, it's a pain in the ass to read). But to validate those transactions, you must send them to the bank over the internet, and you'll get a visit from the feds/FBI/whatever if you do it. There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.

csinode 1y ago
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 does seem to be difficult/impossible in this specific case, but it means research in this area is relevant.)
- christina97 1y ago
  There are much easier ways to skim cards than hacking the terminal.
  - account42 1y ago
    Not without leaving physical evidence.
- rockbruno 1y ago
  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.
  - literalAardvark 1y ago
    Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance. And maybe even send the money to a different account.

ofjcihen 1y ago

The look into these is neat but…why immediately open it up and trigger the tamper state? Did they not know most readers would have one? Any real testing happening in the tamper state might be meaningless. Perhaps the shell is available after the tamper state triggers for resetting purposes. It just seems like opening it would be the last thing you would try.

stgl 1y ago
Well, I felt like I first had to get a feeling for what I am working with. Hardware, what SoC, interfaces, flash etc... Otherwise I am too much in the dark. But sure, in hindsight I could've just tapped the debug connector and could have been done with it. No, I got a shell on second, untampered one, as well.
- allenrb 1y ago
  Specifics of this hack aside, I wish I could solder like that!

_trampeltier 1y ago

I know they run Linux, once a such terminal updated and rebooted when I would pay. It was in the evening rush hour on in a shop. The other person before me paid, then the salesperon scanded my things and suddenly an update was on the screen.

bill_mcgonigle 1y ago

What a nice writeup! Just curious - what kind of wire do you use to solder on the pins - enameled? I wonder if they offer their customers source to keep the Busybox folks happy?

stgl 1y ago
Yes, 0.1 mm diameter enameled copper wire. Chasing GPL violations sounds like a fun hobby :)
- zoobab 1y ago
  I think US based SFLC has budgets if you request it to enforce the GPL. Pre-OpenWRT days I was maintained a Linux distro ISL3893 that ended up in court in Germany, the first GPL enforcement: http://isl3893.wikidot.com/ http://isl3893.wikidot.com/ "17 apr 2004 — GPL testing in court by the Netfilter/Iptables team, due to refuse to give source code of the Sitecom WL-122 (isl3893 based!). In the same time, some source code has appeared on the webserver of Sitecom."

jdefr89 1y ago

UART always the first place I look…

Sakthimm 1y ago
My thoughts exactly. Why desolder the flash chip before probing for UART? Still, impressive work.
- stgl 1y ago
  Thanks! Yep, I feel foolish. I just could not imagine it would be that easy on a locked-down terminal. But I learned for next time :)

fdspopofe 1y ago

[dead]

SamuelAdams 1y ago

Alright sorry if this is dumb but how does the OP know about all this?

tialaramex 1y ago

Light Blue Touchpaper https://www.lightbluetouchpaper.org/ https://www.lightbluetouchpaper.org/ might well be interested in this work, the card payment tech is something they spent lots of time looking at and they tend to have a more realistic assessment of where the weaknesses might be that the industry which tends to see itself as infallible.

deleted 1y ago

[deleted]

wkat4242 1y ago

Very interesting. These terminals are super common in the Netherlands also. The exact same ones. Kudos to the author, rigging up a BGA chip is no small feat. I love this kind of curiosity (one of the reasons I like HN)

kriro 1y ago

Excellent article. Reminds me of a CCC talk in the early 2000s where an enthusiast checked ATMs of different banks across Germany and most where running unpatched Windows 98 (I think). If my memory is correct it was also very easy to get physical access. I believe removing a couple of normal screws got you to an ethernet port or something similar.

israrkhan 1y ago

Once he got the root shell on "insecure" processor, that could have been used as an attack point for the secure processor. It would be much more interesting to pwn the secure processor from insecure Linux OS.

grishka 1y ago

These are (were?) popular in Finland and confused me a lot every time I visited. The NFC reader in them is on the side, which is very unusual compared to the kinds of terminals I'm used to, which have it in the screen so you just tap your card/phone on the screen.

davedx 1y ago

I used to work with set-top-boxes for a big media corporation, those also had the debug serial port. I remember it being fiddly but also absolutely vital to be able to do any useful work with the STB's. It's quite eye opening now reading this to see that they're also a huge potential security hole (in the right hands), unless everything is locked down with the second secure processor like in this setup.

ttkari 1y ago

Reading about all the tamper detection on the device makes me wonder what would be the easiest way to trigger the tamper mode. After all, being able to do that on just a handful of devices would be an efficient denial of service attack on a retail location when the majority - and sometimes all - of payments go through these things.

neop1x 1y ago
Dropping it on the floor or pouring water on it.

anemic 1y ago

I once had the (dis)pleasure of working with these Yomani terminals. I got a development unit (with red text "DO NOT PAY" on the side). I plugged it in my home internet which has a public ip with dhcp just to get it quickly online and keep it out of my internal home network. The next day I got a call from my ISP saying I had a compromised machine in my network with malware. I was like WTF?! and they gave me the mac address and it was the Yomani terminal! I promptply unplugged it from the network and started investigating. Indeed, this development unit had a telnet(!) port open and root login without password was possible. So, having a wide open telnet port on a public ip and it's just a matter of minutes until someone uploads a generic arm malware onto it. I returned the terminal to the vendor with explanation but never got a followup. Lesson learned: never attach anything to public internet, even if it looks secure. I guess Atos Worldline really doesn't like root passwords.

stgl 1y ago
Very interesting!

rswail 1y ago

So a few things: 1. Under the current EMV standards for terminals, the NFC and/or chip connection is via a secure element that protects the data in the transaction both in transit and at rest. 2. The transaction is protected in transmission not only by TLS encryption, but with an individual HMAC generated using a key that is derived from a base key that is unique to the terminal and merchant. The interaction with the card is relatively read-only. There is a "dynamic CVV" that is generated on the card in chip/contactless transactions that adds some security, however, the data on the card is mostly open (PAN, expiry date, CC name etc). The CHI (cardholder information) has to be maintained in an encrypted state at all times. The business processes (where this article found the root shell) is not involved in the actual card or transaction security. It communicates with the secure element via a protocol that allows it to specify the amount and other details for a transaction, but the authorization (PIN or otherwise) and encrypted messages are entirely within the secure element.