Readit News logoReadit News
stgl commented on Root shell on a credit card terminal   stefan-gloor.ch/yomani-ha... · Posted by u/stgl
anemic · 6 months 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 · 6 months ago
Very interesting!
stgl commented on Root shell on a credit card terminal   stefan-gloor.ch/yomani-ha... · Posted by u/stgl
Sakthimm · 6 months ago
My thoughts exactly. Why desolder the flash chip before probing for UART? Still, impressive work.
stgl · 6 months 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 :)
stgl commented on Root shell on a credit card terminal   stefan-gloor.ch/yomani-ha... · Posted by u/stgl
emidln · 6 months ago
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 · 6 months ago
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.
stgl commented on Root shell on a credit card terminal   stefan-gloor.ch/yomani-ha... · Posted by u/stgl
emidln · 6 months ago
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 · 6 months ago
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.

stgl commented on Root shell on a credit card terminal   stefan-gloor.ch/yomani-ha... · Posted by u/stgl
bill_mcgonigle · 7 months 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 · 7 months ago
Yes, 0.1 mm diameter enameled copper wire. Chasing GPL violations sounds like a fun hobby :)
stgl commented on Root shell on a credit card terminal   stefan-gloor.ch/yomani-ha... · Posted by u/stgl
fp64 · 7 months 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 · 7 months 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.
stgl commented on Root shell on a credit card terminal   stefan-gloor.ch/yomani-ha... · Posted by u/stgl
ofjcihen · 7 months 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 · 7 months 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.

stgl commented on Root shell on a credit card terminal   stefan-gloor.ch/yomani-ha... · Posted by u/stgl
ComputerGuru · 7 months 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 · 7 months 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.

u/stgl

KarmaCake day313August 9, 2024View Original