Root-Shell auf einem Kreditkartenterminal erlangt

• Für die Sicherheitsforschung zum Worldline Yomani XR Kreditkartenterminal wurde Reverse Engineering durchgeführt
• Beim Zerlegen des Geräts zeigte sich, dass die physische Manipulationserkennung zwar gut umgesetzt ist, softwareseitig jedoch eine Root-Shell über einen externen seriellen Port offengelegt wird
• Durch Auslöten des Speichers sowie Extraktion und Analyse der Firmware wurde eine Systemarchitektur auf Basis des Linux-3.6-Kernels und sehr alter Komponenten festgestellt
• Über den seriellen Konsolenport konnte nachgewiesen werden, dass sich auch ohne Zerlegen des Geräts leicht Root-Rechte erlangen und Schadcode installieren lassen
• Alle wichtigen Aufgaben rund um Zahlung und Authentifizierung werden jedoch von einem separaten Sicherheitsprozessor ausgeführt, sodass das Risiko einer Offenlegung tatsächlich sensibler Daten gering ist

---

Projektüberblick

• Dieses Projekt konzentriert sich auf den Reverse-Engineering-Prozess des Modells Worldline Yomani XR zu Forschungszwecken im Bereich der Sicherheit von Zahlungsterminals
• Dieses in der ganzen Schweiz weit verbreitete Modell wird zwar nicht mehr hergestellt, ist aber weiterhin in vielen großen Einzelhandelsgeschäften und kleinen Läden im Einsatz

Erste Beobachtungen und Hardware-Zerlegung

• Nach grundlegenden Untersuchungen wie UI-Erkundung und Port-Scans wurde mit der Hardware-Zerlegung begonnen
• Mehrere PCBs, ein gut konstruiertes Gehäuse, ein Dual-Core-Arm-Prozessor auf Basis eines kundenspezifischen ASICs und weitere Merkmale zeigten eine beachtliche Hardware-Sicherheit
• Das zentrale SoC ist ein dedizierter ASIC mit dem Codenamen Samoa II, ausgestattet mit externem Flash und RAM

Manipulationserkennung und Schutz vor Eingriffen

• Auch ohne Öffnen des Gehäuses konnten Manipulationsereignisse bereits durch eine fehlerhafte druckempfindliche Board-Verbindung (Zebra-Strip) oder gelockerte Schrauben erkannt werden
• Dank der Batterie blieb die Erkennung auch bei unterbrochener Stromversorgung aktiv
• Auf den wichtigsten PCBs sorgen zickzackförmige Leiterbahnen (Traces) und ein den Kartenleser umhüllendes flexibles PCB bei Beschädigung für Manipulationserkennung
• Nach kurzem Zerlegen und erneutem Zusammenbau zeigte das Gerät aufgrund der Manipulationserkennung nur noch einen roten Bildschirm mit "TAMPER DETECTED" und reagierte nicht mehr auf externe Eingaben

Chip-off-Extraktion der Firmware

• Der Onboard-Flash wurde ausgelötet und zur Firmware-Extraktion direkt angebunden
• Die Daten waren nicht verschlüsselt, allerdings wurden eine ungewöhnliche ECC-Struktur und die Metadaten-Anordnung des YAFFS2-Dateisystems festgestellt
• Durch die Implementierung eines Dateisystem-Readers konnte die vollständige Dateiliste gewonnen werden
• Das System verwendet einen 3.6-Kernel auf Basis von Buildroot aus dem Jahr 2010, dazu uClibc, busybox und zahlreiche veraltete Bibliotheken

Zufällige Entdeckung der Root-Shell

• Nach der Firmware-Analyse wurde der Flash wieder angeschlossen und über einen Logikanalysator das Signal abgegriffen, nachdem die Leitungen der seriellen Konsole identifiziert worden waren
• Zusammen mit dem Boot-Log wurde ein Login-Prompt sichtbar
• Bei Eingabe von "root" war sofortiger Zugriff auf eine Root-Shell ohne Passwort möglich
• Dieser serielle Port ist tatsächlich von außen direkt zugänglich, sobald nur die Abdeckung geöffnet wird
• Ein Angreifer könnte also ohne Zerlegen des Terminals schnell eine Verbindung herstellen und etwa Schadcode einschleusen

Wie schwerwiegend ist das Problem?

• Die Analyse von Boot-Vorgang und Systemkonfiguration ergab, dass Linux nur Netzwerk, Updates und einen Teil der Business-Logik übernimmt
• Kartenzahlung, PIN-Eingabe, Anzeige und alle sicherheitsrelevanten Funktionen werden von einem separaten mp1-Prozessor verwaltet
• Linux (mp2) startet immer mit und lädt danach über den sicheren Bootloader ein signiertes und verschlüsseltes Image in den Sicherheitskern
• Der Schutz des Sicherheitskerns funktionierte intern einwandfrei, und kritische Sicherheitsdaten werden durch die offengelegte Root-Shell nicht preisgegeben

Zeitplan für Offenlegung und Meldung

• 14. November 2024: Root-Shell entdeckt
• 15. November 2024: Hersteller mit Hinweis auf geplante Offenlegung nach 90 Tagen informiert
• 18. November 2024: Eingangsbestätigung des Berichts durch den Hersteller
• 1. Juni 2025: Veröffentlichung des Projekts

Fazit

• Die offengelegte Root-Shell über einen externen seriellen Port ist eindeutig eine unnötige Angriffsfläche und ein technischer Fehler
• Dank der Trennung über einen Sicherheitsprozessor ist das tatsächliche Risiko einer Offenlegung von Zahlungsdaten jedoch gering
• Möglicherweise wurde die erlaubte Root-Anmeldung versehentlich in die Produktions-Firmware übernommen oder unterscheidet sich je nach Version
• Im Verlauf der Untersuchung gab es auch Geräte, bei denen die Root-Anmeldung vollständig deaktiviert war
• Es ist gut möglich, dass das Problem intern bereits erkannt und behoben wurde

Dieses Projekt lieferte mehrere interessante Ergebnisse und zeigte erneut den Wert einer tiefgehenden Firmware-Analyse

[GN⁺]

Hacker-News-Kommentare

• Eine Bemerkung an junge Entwickler: Genau das ist die Bedeutung von „Hacker“ in „Hacker News“. Der Beitrag sei ein gutes Beispiel dafür, wie sich eine typische Hacker-Reise Schritt für Schritt nachvollziehen lasse. Wer mehr ähnliche Fälle sehen wolle, solle sich Hack-a-day ansehen. Der Autor wirke wie jemand mit großer Neugier und sehr soliden Grundlagen. Im Kern gehe es um das Studium von Chip-Datenblättern, zerstörungsfreies Entlöten, bei Speicherbausteinen um das Wiederverbinden per Draht, dazu Improvisation und Trial-and-Error. Beim nächsten Mal könne man bei flachen Bohrungen auch eine Pinhole-Kamera in Betracht ziehen, um Spuren von Beschädigungen zu vermeiden. Wenn der Autor zusätzlich noch die Manipulationserkennung umgangen und den Normalbetrieb wiederhergestellt hätte, wäre es wirklich noch interessanter gewesen.

  • Der Begriff Hacker sei nicht auf Computersicherheit beschränkt, sondern habe eine viel umfassendere Bedeutung und sogar eine philosophische Definition. Unter Verweis auf die von Guy Steele u. a. zusammengetragene Jargon File wird die Definition von Hacker erläutert, etwa als „jemand, der gern die Details programmierbarer Systeme lernt und ihre Grenzen erweitert“, „jemand, der leidenschaftlich gern programmiert“ oder auch „ein Experte, der in einem bestimmten Programm besonders versiert ist“. Vermutlich habe auch PG, der Gründer von Hacker News, den Namen mit dieser breiteren Definition im Kopf gewählt. Zur Geschichte des Begriffs müsse außerdem unbedingt The UNIX-HATERS Handbook erwähnt werden.

  • Volle Zustimmung zum ersten Satz. Wenn noch ein weiteres LLM-Wrapper-Startup auftaucht, reicht es langsam wirklich.

  • Nur weil die Seite aus einem VC-Startup-Inkubator stammt, müsse das nicht bedeuten, dass mit „Hacker“ Sicherheits-Hacking gemeint sei. Wahrscheinlich gehe es eher um das Startup-Verständnis von „move fast and break things“, also um einen Stil, bei dem man schnell Code produziert und sich so durch Probleme arbeitet.

  • Nach langem stillen Mitlesen habe jemand erst vor Kurzem einen Account erstellt und begonnen zu kommentieren; genau solche Beiträge mit hohem Informationsgehalt und echter Umsetzungskraft zeigten den Hacker-Geist von Hacker News.

  • Jemand gesteht, bei diesem Beitrag zum ersten Mal den Upvote-Knopf gedrückt zu haben, weil es tatsächlich einmal um echtes Hacking ging. Normalerweise vergebe man Upvotes nur für Kommentare, hier habe man eine Ausnahme gemacht.

• Mit einem 2-Dollar-USB-Kartenleser lasse sich eine gefälschte Kredit-/Debitkartentransaktion simulieren. Alle Spezifikationen und Protokolle seien zwar umfangreich, aber öffentlich, sodass man das allein anhand der Dokumentation implementieren könne. Um jedoch eine echte Transaktion genehmigt zu bekommen, müsse man die Daten über das Internet an eine Bank senden, und dann würden sehr schnell die Behörden, etwa das FBI, vor der Tür stehen. Der Kartenleser selbst habe kaum Schutzmechanismen, verwende meist Linux und schwache Passwörter; die eigentliche Sicherheit stamme aus Verträgen und Vorschriften zwischen Händler und Bank.

  • Dem Einwand, Kartenleser hätten „keine Schutzmechanismen“, wird widersprochen. Tatsächlich könnten nur signierte Binärdateien ausgeführt werden, das ausführbare Dateisystem sei schreibgeschützt, auf dem Daten-Dateisystem sei das noexec-Flag gesetzt, Root-Login sei deaktiviert, es gebe eine abgespeckte busybox, Schlüssel würden beim Booten aus einem sicheren Bereich geladen, das Einspielen des Master Keys sei nur im Werk möglich, auch der Bootvorgang selbst sei sehr sicher, und bei Manipulation werde der Chip selbst auf leer zurückgesetzt. Billige, nicht zertifizierte Low-End-Terminals hätten womöglich fast keine Sicherheit, aber aus Sicht von jemandem mit EMV-Entwicklungserfahrung seien reale Terminals nahezu perfekt verriegelt.

  • Dass die Regulierung zwischen Händler und Bank die einzige Sicherheit sei, stimme allerdings. Deshalb seien Verschwörungstheorien, wonach Leute mit tragbaren Kartenlesern kontaktlose Karten ausräumen könnten, in der Praxis schwer umzusetzen. Selbst wenn man eine Transaktion erzeugen könne, sei es wegen der nachgelagerten Schritte und der nötigen Vorbereitungen fast unmöglich, das Geld sicher abzuziehen. Vor allem heute, wo Push-Benachrichtigungen für Transaktionen üblich seien, würde ein Betrugsversuch wahrscheinlich schnell auffallen.

  • Beunruhigender sei das Szenario, dass ein Kartenleser vor Ort kompromittiert werde, um zwischengespeicherte Kreditkartendaten auszulesen oder Interceptor-Malware zu installieren. Gerade deshalb sei Forschung in diesem Bereich wichtig.

  • Die Aussage, Transaktionen müssten zur Genehmigung per Internet an die Bank gesendet werden, sei so nicht korrekt. Banken hätten keine Open API im Internet, über die Kartentransaktionen verarbeitet würden.

  • Der Behauptung, die Sicherheit von Kartenlesern sei schwach, wird ebenfalls widersprochen. In echten Händlerterminals stecke Sicherheits-Hardware, die Bank- und Zahlungsnetzwerkschlüssel sicher speichere. Wenn diese Schlüssel kompromittiert würden, ließen sich legitime Transaktionen fälschen.

• Jemand berichtet von 36 gekauften Stripe-M2-Lesern, von denen 7 ausgefallen seien: Bei 2 lade der Akku nicht mehr, 1 könne kein NFC mehr scannen, 4 seien mit einem „tampered“-Fehler gestorben. Oberflächlich betrachtet sei das eine alarmierende Ausfallquote, aber man müsse auch Nutzungstage und Alter berücksichtigen. Noch gravierender erscheine, dass insgesamt nur an 9 Tagen mit 1 bis 3 Jahre alten Lesern gearbeitet worden sei und trotzdem gleich 7 ausgefallen seien. Beim Transport würden sie jeweils in Hartschalenkoffern mit Schaumstoffeinlagen sorgfältig geschützt, an schlechter Lagerung liege es also nicht. Trotzdem seien Stripe-M2-Leser noch immer die brauchbarste Option, sodass man sie notgedrungen weiter verwende. Hintergrund sei, dass die Firma Zahlungen bei Festivals abwickle und deshalb kurzfristig viele Geräte auf einmal nutze.

  • Für die nächste Veranstaltung wird empfohlen, die Geräte unbedingt vollgeladen zu lagern. Die meisten Akkus mögen es nicht, lange in niedrigem Ladezustand zu bleiben, und auch die Manipulationserkennung funktioniere womöglich nur bei ordnungsgemäß versorgtem Akku.

• Jemand spekuliert, dass bei aktivierter physischer Manipulationserkennung vielleicht eine Root-Shell geöffnet werde, also entweder in einem Sicherheitsmodus mit allen nötigen kryptografischen Schlüsseln oder alternativ in einem Modus für Debugging/Fehleranalyse mit Root-Shell. In dem Fall hoffe man aber, dass wichtige private Schlüssel automatisch gelöscht worden seien.

  • Auch jemand anders fragt sich, ob man über eine Root-Shell neue Schlüssel flashen und das Gerät wiederverwenden könnte. Wenn das Terminal ohnehin ausgemustert werde, sei es wahrscheinlich nicht allzu schwer, eines gebraucht zu bekommen.

• Mit Verweis auf die Aussage des Originalbeitrags, dass Kartendaten „selbst bei geöffneter Root-Shell nicht gefährdet“ seien, wird der Artikel als Pflichtlektüre für Sicherheitsarchitekten empfohlen.

  • Wenn man physischen Zugriff auf das Terminal habe und zusätzlich Root-Rechte, sei die Behauptung, dass man dann keine Kartennummern auslesen könne, überhaupt nicht überzeugend. In der Security-Praxis bedeuteten physischer Zugriff und Root-Zugriff letztlich, dass das System gehackt worden sei.

• Es wird die Ansicht geäußert, dass das manipulierte Linux entscheide, ob der „compromised mode“-Code oder das MP1-Sicherheitssystem geladen werde. Selbst wenn der Bootloader an sich sicher sei, hänge seine Bedeutung davon ab, in welcher Umgebung tatsächlich ausgeführt werde. Ein Co-Prozessor könne zwar die Rolle einer Secure Enclave übernehmen, aber wenn Linux die Möglichkeit habe, einen separaten Bootloader zu laden, wäre das sicherheitstechnisch ein gravierendes Problem.

  • Dem wird widersprochen: Ein separater Bootloader lasse sich nicht laden. Man habe selbst nach einer Manipulation versucht, den Bootloader zu verändern, aber das Gerät habe dann nicht normal gebootet; vermutlich prüfe ein drittes Boot-ROM die Integrität. Außerdem lade Linux unabhängig vom Manipulationsstatus immer sowohl loadercode als auch mp1.img, und je nach Manipulationsstatus verzweige dann der in seiner Integrität geschützte loadercode intern.

• Anfängern wird empfohlen, es lieber zuerst mit einem modernen Android-basierten Kreditkartenterminal zu versuchen. Das Eintippen der PIN über den Touchscreen mache mehr Spaß.

  • Der Touch-Controller sei in der Regel an einen MUX angeschlossen, der vom Sicherheitsprozessor gesteuert werde. Bei der Eingabe sicherheitsrelevanter Informationen würden Touch-Eingaben direkt an den Sicherheitsprozessor geleitet, ohne dass das Android-artige Betriebssystem eingreife.

  • Selbst wenn die PIN auf dem Touchpad angezeigt werde, würden die PIN-Daten von Firmware verwaltet, die in einer Trust Zone laufe, und blieben verschlüsselt. Dazwischenliegende Apps könnten die PIN nicht sehen.

  • Selbst wenn man ein solches Android-Terminal hacke, würde bei gleichem Sicherheitsdesign die Karte selbst komplexe Kryptografie ausführen, sodass praktisch keine verwertbaren Informationen übrig blieben. Solche Angriffe funktionierten nur, wenn nur noch ein bloßer Kreditkartenleser übrig sei; ein solches Terminal wäre für Nutzer ohnehin schon ein Warnsignal für Skimming.

  • Nebenbei wird interessant gefunden, dass in Indien verwendete Android-Terminals noch immer mit Android Oreo laufen, dessen Support im Januar 2021 endete.

• Verwunderung darüber, dass beim Analysieren des Terminal-Innenlebens sofort geöffnet und direkt der Manipulationsmodus ausgelöst wurde. Vielleicht habe man schlicht nicht gewusst, dass die meisten Lesegeräte über Manipulationserkennung verfügen. Tests im Manipulationsmodus könnten weniger aussagekräftig sein, und vielleicht öffne sich nach dem Auslösen der Manipulationserkennung sogar nur eine Shell für die Initialisierung. Abschließend der Rat, noch einmal zu überlegen, ob es wirklich selbstverständlich sei, das Gerät von Anfang an zu öffnen.

  • Die Antwort darauf: Zunächst habe man Hardware, SoC, Schnittstellen, Flash und andere Grundinformationen erfassen wollen und es deshalb geöffnet. Ohne Vorabrecherche hätte sich das wie ein Start im völligen Dunkeln angefühlt. Rückblickend sei es vielleicht schon ausreichend gewesen, nur vorsichtig an den Debug-Anschluss zu gehen. Ergänzend wird erwähnt, dass man beim zweiten, unversehrten Terminal ebenfalls erfolgreich eine Shell erhalten habe.

• Gelobt wird, dass trotz gründlicher Manipulationssicherung noch immer viele Umgehungsmöglichkeiten und interessante Spuren geblieben seien. Der Sicherheitsteil sei offenbar so ausgelegt, dass er sicher ausfalle.

  • Es wird betont, dass der gehärtete Prozessor (mp1) weiterhin nicht kompromittiert sei. Tatsächlich würden nur String-Daten an das Binärprogramm display_tool übergeben, das dann mit dem anderen Prozessor Nachrichten austausche. Auf Kartenleser oder Tastatur könne Linux nicht direkt zugreifen; der vollständig getrennte mp1-Prozessor übernehme die gesamte „sichere“ Verarbeitung wie Karten-, PIN- und Bildschirmeingaben, während das Linux auf mp2 nur Netzwerk, Updates und Business-Logik verarbeite.

  • Möglich sei allerdings, dass die Linux-Seite die Verarbeitung des Manipulationsereignisses erkenne. Wenn Sicherheitsschlüssel aber erst gelöscht würden, nachdem die Manipulation vollständig erkannt wurde, könnte es riskant sein, weil dann vielleicht ein Ablauf denkbar wäre, bei dem man sich zuerst eine Root-Shell verschafft und anschließend die Manipulationserkennung umgeht.

• Es wird angemerkt, dass solche Terminals in ganz Europa verbreitet seien. Für die Schweiz sei man sich nicht sicher, aber in vielen europäischen Regionen, die man kenne, trügen Menschen selten Kreditkarten mit sich. Da POS-Terminals ohnehin allerlei Karten lesen könnten, sei die Bezeichnung „POS-System“ passender. Der Beitrag habe trotzdem Spaß gemacht zu lesen.

  • Jemand beklagt sich, dass er es hasse, mehrere Karten im Portemonnaie mit sich herumzutragen. Es platze ohnehin schon aus allen Nähten, und zwar aus vielen Gründen, nicht nur wegen Zahlungsmitteln. Deshalb wolle man weder dem Handy noch der Smartwatch noch mehr hinzufügen, und beim Verlust eines solchen Geräts wären die Datenschutzfolgen viel zu gravierend. Das sei Geschmackssache, aber man bevorzuge mechanische Uhren und nutze aus all diesen Gründen keine Lösungen zur Kartenkonsolidierung.