Root-Shell auf einem Kreditkartenterminal erlangt

• Bei der Zerlegung und Firmware-Analyse des in der Schweiz eingesetzten Worldline Yomani XR-Zahlungsterminals zeigte sich, dass über eine über die rückseitige Klappe zugängliche serielle Konsole durch bloßes Eingeben von root eine Root-Shell erreichbar war
• Das Terminal verfügte über Tamper-Schutz, der das Öffnen des Gehäuses, das Trennen von PCB-Kontakten, das Durchschneiden von Zickzack-Leiterbahnen und Beschädigungen der Flex-PCB rund um den Kartenleser erkennt, doch der exponierte Debug-Port stellte einen separaten Angriffsweg dar
• Die aus dem Onboard-Flash extrahierte Firmware enthielt ein unverschlüsseltes Dateisystem und lief auf Basis von Linux-Kernel 3.6, Buildroot 2010.02, BusyBox, uClibc und dem Custom-Bootloader Booter v1.7
• Sicherheitsfunktionen wie Karte, PIN, Bildschirm und Keypad scheinen von einem separaten Prozessor mp1 und dem verschlüsselten sowie signierten mp1.img übernommen zu werden; Hinweise auf direkt aus Linux mp2 möglichen Zugriff wurden nicht gefunden
• Die anfällige Firmware-Version konnte nicht eindeutig bestimmt werden, und es gab auch Geräte mit deaktiviertem Root-Login, doch in Umgebungen, in denen ein Terminal kurzzeitig physisch exklusiv verfügbar ist, bleibt eine unnötig große Angriffsfläche bestehen

---

Analyseziel: Worldline Yomani XR

• Untersucht wurde ein in der Schweiz weit verbreitetes Worldline Yomani XR-Zahlungsterminal
• Da weder die UI-Prüfung nach dem Booten noch Port-Scans auffällige Ergebnisse lieferten, wurde das Gerät hardwareseitig zerlegt
• Das Innere besteht aus mehreren PCBs
  • kleine Platine für externe Anschlüsse
  • Hauptplatine
  • vertikale Platine mit montiertem Kartenslot
• Der Main-SoC scheint ein Dual-Core-Arm-basierter Custom-ASIC zu sein, der in der Firmware unter dem Codenamen „Samoa II“ auftaucht
• Laut Worldline-Dokumentation handelt es sich bei diesem Chip nicht um ein Rebranding eines Standardchips, sondern um einen Custom-ASIC
• Neben dem SoC befinden sich ein kleiner externer Flash und RAM

Struktur des Hardware-Tamper-Schutzes

• Ein üblicher Gehäuseöffnungsschalter wurde nicht gefunden; stattdessen diente das board-to-board interconnect selbst als Öffnungserkennung
• Zwischen den Platinen befinden sich druckempfindliche Zebra-Strips, sodass der Kontakt nur bei fest verschraubten Platinen erhalten bleibt
  • Schon das Lösen einiger Schrauben kann den Kontakt unterbrechen und ein Tamper-Ereignis auslösen
  • Da die Erkennung auch bei getrenntem Strom funktionieren muss, wird eine Coin-Cell-Batterie verwendet
• Empfindliche PCB-Bereiche sind mit zickzackförmigen Tamper-Erkennungsleiterbahnen bedeckt
  • Bereits das Durchtrennen nur einer einzigen Kupferleiterbahn bei einem physischen Eingriff kann eine Tamper-Erkennung auslösen
• Der Kartenslot sitzt in einem separaten internen Gehäuse, und eine ihn umgebende Flex-PCB dient als Tamper-Schutz
• Nach dem Zusammenbau zeigte das Terminal nur noch einen großen roten Bildschirm mit „TAMPER DETECTED“ und schien in diesem Modus nicht auf externe Eingaben zu reagieren

Flash-Extraktion und Wiederherstellung des Dateisystems

• Da die Laufzeituntersuchung blockiert war, wurde der Onboard-Flash-Chip ausgelötet, per Kabel angebunden und ausgelesen
• Der Dump war entgegen der Erwartung insgesamt nicht verschlüsselt
• Im Flash wurde eine ungewöhnliche ECC-Anordnung verwendet
  • Es handelte sich nicht um das Standardlayout mit 2048 Byte Payload + 64 Byte ECC/Spare
  • Es gab drei Daten-Chunks mit je 694 Byte, hinter denen jeweils 10 ECC-Bytes folgten
  • Die letzten 16 Byte des Spare-Areas wirkten wie YAFFS2-Dateisystem-Metadaten
• Da der Metadatenbereich kleiner war als bei gewöhnlichem YAFFS2, musste das Dateisystem gepatcht werden, um eine kleinere Metadatenstruktur zu verarbeiten
• Nach der Implementierung eines kompatiblen Dateisystem-Readers konnte der Inhalt des Dateisystems erfolgreich extrahiert werden

Veraltetes Linux-basiertes System

• Das extrahierte Dateisystem bestätigte, dass das Terminal Linux ausführt
• Das System enthält veraltete Komponenten
  • Linux kernel 3.6
  • Buildroot 2010.02
  • Build vom Februar 2023
  • Custom-Bootloader Booter v1.7
  • init-Skript, BusyBox, uClibc
  • libcrypt 0.9.26
• Wie aktuell die gedumpte Firmware-Version war, ließ sich nicht verifizieren, sie muss jedoch nach Februar 2023 veröffentlicht worden sein

Root-Shell ohne Passwort

• Nachdem der Flash-Chip per Kabel wieder angeschlossen worden war, bootete das Terminal trotz Tamper-Meldung erneut
• Um das Linux-Boot-Log zu sehen, wurde der Bereich um den Debug-Connector mit einem Logic Analyzer untersucht; auf einem Pad des unbestückten Debug-Connectors wurde Aktivität gefunden
• Auf der seriellen Konsole erschien zusammen mit dem Linux-Boot-Log ein Login-Prompt
  • Im Boot-Log stand „Reset reason: Tamper“
  • Außerdem erschienen Logs wie dropbear is not present, Prüfung auf Firmware-Updates und Start eines Application-Monitoring-Daemons
  • Am Ende erschien der Prompt samoa login:
• Nach Eingabe von root als Login erschien ohne Passwort der Shell-Prompt ~ #
• Für diesen Zugriff waren weder eine Exploit-Kette noch Brute-Force-Passwort-Cracking nötig

Von außen zugänglicher Debug-Port

• Der Zugriff auf die Root-Shell war nicht nur auf Fälle mit geöffnetem Terminal beschränkt
• Der serial port war von außen über eine kleine Klappe auf der Rückseite des Terminals zugänglich
• So ließ sich eine Verbindung zum Debug-Connector herstellen, ohne das Gerät zu öffnen und den Tamper-Schutz auszulösen
• Wenn man das Terminal kurzzeitig exklusiv in Besitz hat, erscheint ein Szenario möglich, in dem man sich mit dem seriellen Port verbindet, sich einloggt, Malware platziert und wieder verschwindet

Aufgabentrennung zwischen Sicherheitsprozessor und Linux

• Die exponierte Root-Shell bedeutet nicht automatisch Zugriff auf Karten- oder PIN-Daten
• Das Linux-System ist nur ein Teil der Gesamtarchitektur; es wurden keine Hinweise gefunden, dass Display, Keypad oder Kartenleser direkt aus Linux heraus zugänglich wären
• Auch die Bildschirmausgabe schien nicht direkt über einen Framebuffer-Treiber zu laufen; stattdessen wurden Strings an das Binary display_tool übergeben, das dann Interprozessor-Nachrichten sendete
• Sicherheitsrelevante Funktionen wie Karte, PIN-Eingabe und Bildschirmanzeige scheinen von einem separaten Prozessor mp1 verarbeitet zu werden
• Linux auf dem zweiten Prozessor mp2 übernimmt Networking, Updates und Business-Logik

Boot-Ablauf und gesichertes Image

• Der Linux-Core scheint unabhängig vom Tamper-Status immer zu booten
• Anschließend lädt Linux den Secure-Bootloader loadercode in den Speicher
• loadercode prüft dann, ob der Tamper-Schutz ausgelöst wurde
  • Wenn Tamper erkannt wurde, zeigt es den roten Bildschirm an
  • Wenn kein Problem vorliegt, bootet es das eigentliche Secure-Image mp1.img
• mp1.img befindet sich im Linux-Dateisystem, scheint aber verschlüsselt und von zwei Entitäten signiert zu sein
• Das Secure-Image, das Karte, Display und Keypad verarbeitet, war angemessen verschlüsselt und signiert

Offenlegungszeitplan und verbleibende Unsicherheiten

• Der Offenlegungszeitplan wurde wie folgt festgehalten
  • 14. November 2024: Root-Shell entdeckt
  • 15. November 2024: Hersteller informiert und geplante Offenlegung nach 90 Tagen angekündigt
  • 18. November 2024: Hersteller bestätigt den Eingang der Meldung
  • 1. Juni 2025: Veröffentlichung
• Die exponierte Root-Shell stellt eine unnötig große Angriffsfläche dar, doch es wurden keine Hinweise gefunden, dass darüber sensible Daten wie Karteninformationen kompromittiert werden konnten
• Welche Firmware-Versionen anfällig sind, konnte nicht abschließend bestimmt werden
• Während der Untersuchung wurden auch Geräte mit deaktiviertem Root-Login gefunden
• Es konnte nicht geklärt werden, ab wann das Debug-Feature in Production-Firmware enthalten war oder ob der Hersteller das Problem intern bereits entdeckt und behoben hatte

[GN⁺]

Meinungen auf Hacker News

• Mit einem USB-Kartenleser für 2 Dollar kann man gefälschte Debit-/Kreditkartentransaktionen erzeugen.
  Die Spezifikationen sind alle öffentlich, und das Protokoll ist ebenfalls dokumentiert. Soweit ich mich erinnere, hat das PDF etwa 5000 Seiten und ist sehr mühsam zu lesen.
  Um diese Transaktion aber zu verifizieren, muss man sie über das Internet an die Bank schicken, und dann könnten Bundesbehörden/FBI oder Ähnliches vor der Tür stehen.
  Im Kartenleser selbst gibt es kaum echten Schutz; meist läuft darauf ein kleines Linux mit miserablen Passwörtern. Der Schutz ergibt sich aus Verträgen und Regulierung zwischen Händler und Bank.

  • Dass Kartenleser keinen Schutz hätten, stimmt nicht. Es werden nur signierte Binaries ausgeführt, das ausführbare Dateisystem ist schreibgeschützt, und für das Datendateisystem ist noexec gesetzt.
    Root-Login ist deaktiviert, es wird ein stark abgespecktes busybox verwendet, und die Schlüssel werden beim Booten aus einem Sicherheitsbereich geladen. Das Injizieren des Master Keys ist nur beim Laden im Werk möglich, auch der Bootvorgang selbst ist bis zu einem gewissen Grad abgesichert, und wenn Manipulation erkannt wird, wird der Chip geleert.
    Bei einem billigen, nicht EMV-zertifizierten Android-Terminal aus Asien ist es natürlich gut möglich, dass darauf ein Standard-Linux mit les-/schreibbarem Root-Dateisystem, Root-Login und sogar aktiviertem sudo für den App-ausführenden Benutzer läuft. Manipulationserkennung gibt es dann möglicherweise auch nicht, Screen-Casting ist nicht gesperrt, Ports lassen sich öffnen, und busybox kann fast vollständig vorhanden sein.
    Aus meiner Sicht als jemand, der über Jahre EMV-Anwendungen für Kartenakzeptanz entwickelt hat und das gelegentlich immer noch tut: Selbst der Entwicklungsmodus erfordert, dass der Vendor eine Entwickler-ID bereitstellt, und ist ziemlich stark verriegelt.
  • Der Punkt, dass Verträge und Regulierung zwischen Händler und Bank der Kern des Schutzes sind, ist korrekt.
    Deshalb sind auch Verschwörungstheorien falsch, nach denen jemand mit einem tragbaren Kartenleser herumläuft und von kontaktlosen Karten Geld stiehlt. Solche Transaktionen kann man zwar erzeugen, aber das Problem ist, was danach passiert und welche Einrichtung vorher nötig ist.
    Es ist nicht einmal sicher, ob man das Geld herausbekäme, bevor man erwischt und gesperrt wird. Heutzutage haben viele Leute Push-Benachrichtigungen für Transaktionen aktiviert, daher dürfte es noch schwieriger sein.
  • Das stimmt nicht. Händlerterminals haben eingebaute Sicherheitshardware, die Schlüssel von Banken und Kartennetzwerken speichert.
    Wenn diese Schlüssel abfließen, kann jemand legitime Transaktionen vortäuschen.
  • Mehr Sorgen macht mir, dass ein Kartenleser im Feld kompromittiert wird und zwischengespeicherte oder gespeicherte echte Kartendaten ausgelesen werden oder dass Abfang-Malware installiert wird.
    In diesem konkreten Fall scheint das schwierig oder unmöglich zu sein, aber genau deshalb ist Forschung in diesem Bereich sinnvoll.
  • Kannst du den Teil „mit einem USB-Kartenleser für 2 Dollar kann man gefälschte Debit-/Kreditkartentransaktionen erzeugen“ etwas genauer erklären? Ich meine nicht: „Bring mir bei, wie es geht.“

• Ich weiß zwar nicht, wonach ich suchen müsste, war aber versucht, einen meiner Stripe M2 Reader zu öffnen und mir das Innere anzusehen.
  Das Problem ist, dass 7 der 36 gekauften Reader „gestorben“ sind. 2 halten die Ladung nicht, 1 kann kein NFC scannen, und 4 zeigen „tampered“ an. Oberflächlich betrachtet ist die Ausfallquote schlecht, aber für das Gesamtbild muss man Nutzungshäufigkeit und Alter berücksichtigen.
  Nur fällt die Antwort darauf noch schlechter aus. Die Geräte sind 1 bis 3 Jahre alt und wurden insgesamt höchstens 9 Tage genutzt. Bei insgesamt 9 Nutzungstagen sind also 7 von 36 Geräten auf irgendeine Weise ausgefallen. Beim Transport werden sie außerdem alle in einem Hartschalenkoffer mit Schaumstoffeinlage und separatem Slot pro Reader aufbewahrt.
  Deshalb bin ich kein großer Fan der M2 Reader, aber sie sind für mich immer noch die beste Option.
  [0] Als Hintergrund: Unser Unternehmen wickelt Zahlungen auf Festivals ab. Wir fahren zu Veranstaltungsorten und verarbeiten Vor-Ort-Zahlungen mit iPads und M2 Readern; die meisten Zahlungen passieren im Web/in der App. Daher gibt es über 3 Jahre hinweg so wenige „Nutzungstage“.

  • Vor der Lagerung bis zur nächsten Veranstaltung sollte man sie unbedingt aufladen. Die meisten Akkus mögen es nicht, lange mit niedrigem Ladestand gelagert zu werden.
    Und die Manipulationserkennung braucht wahrscheinlich ebenfalls einen funktionsfähigen Akku.

• Es könnte so aufgebaut sein, dass eine Manipulationssiegelung beim Auslösen eine Root-Shell öffnet.
  Also entweder befindet sich das System in einem sicheren Modus mit den für den Betrieb nötigen kryptografischen Schlüsseln, oder in einem unsicheren Modus mit geöffneter Root-Shell für Debugging und Fehleranalyse, wobei beim Übergang wichtige private Schlüssel gelöscht werden.

  • Das habe ich auch vermutet. Vielleicht ist es sogar möglich, neue Schlüssel zu flashen und das Gerät wieder nutzbar zu machen.
    Ich frage mich, ob man tatsächlich an so ein Terminal kommen kann. Wenn sie gerade ersetzt werden und verschwinden, ist es vielleicht gar nicht so schwer, eines gebraucht zu finden.

• Für Leute, die sich leicht aufregen, noch der Hinweis: Dort steht, dass „die offengelegte Root-Shell kein so großes Risiko zu sein scheint, wie zunächst befürchtet. Es wurden keine Hinweise gefunden, dass sensible Daten wie Karteninformationen auf diese Weise kompromittiert werden könnten.“
  Für Sicherheitsarchitekten ist es trotzdem eine gute Lektüre.

  • Dass man trotz physischem Zugriff auf das Terminal und sogar Root-Rechten keine Kreditkartennummern lesen kann, ist äußerst verdächtig.
    In der Sicherheit gilt physischer Zugriff, und in geringerem Maße auch Root-Zugriff, praktisch fast als erfolgreicher Hack.

• Wenn das kompromittierte Linux entscheidet, ob es den Code für den „kompromittierten Modus“ oder das mp1-Sicherheitssystem lädt, wirkt das wie ein untersuchenswerter Pfad.
  Der Bootloader selbst soll zwar sicher sein, aber wenn er je nach tatsächlichem Ausführungsort in die kompromittierte Umgebung geladen wird, könnte das wenig bedeuten.
  Man könnte den Co-Prozessor als eine Art Secure Enclave betrachten, aber dass Linux einen separaten Bootloader laden und ausführen kann, ist bedenklich.

  • Einen separaten Bootloader kann es nicht laden. Ich habe versucht, den „sicheren“ Bootloader namens loadercode zu manipulieren, aber damit bootete es nicht.
    Daher vermute ich, dass eine dritte Instanz, vermutlich das Boot-ROM, ihn verifiziert.
    Außerdem scheint Linux unabhängig vom Manipulationszustand immer loadercode und mp1.img zu laden. Der je nach Manipulationszustand unterschiedliche Codepfad scheint innerhalb von loadercode ausgewählt zu werden, der durch Integritätsschutz abgesichert ist.

• Wenn man den einfachen Modus will, sollte man sich die heutigen Android-basierten Kartenterminals ansehen.
  Vor allem, weil die PIN direkt auf dem Bildschirm eingegeben wird, dürfte das deutlich lohnender sein.

  • Der Touch-Controller ist normalerweise mit einem Multiplexer verbunden, der vom Sicherheitsprozessor gesteuert wird.
    Bei der Eingabe sensibler Daten wie PIN oder PAN wird die Ausgabe des Touch-Controllers direkt zum Sicherheitsprozessor geroutet und umgeht dabei das Android-artige Betriebssystem, das für die GUI zuständig ist.
  • PIN-Daten sind, selbst wenn sie auf dem Touchpad angezeigt werden, weiterhin verschlüsselt und verwenden eine Benutzeroberfläche, die von Firmware in einer Trusted Zone gesteuert wird.
    Deshalb können Zwischenanwendungen, die bei solchen Angriffen zugänglich sind, die PIN nicht sehen.
  • So ließe sich die PIN wohl ziemlich leicht bekommen, aber wenn die wichtigen Teile nach demselben Prinzip so gestaltet sind, dass sie an den Sicherheits-Coprozessor übergeben werden, kann man mit der Karte trotzdem nicht viel anfangen.
    Moderne Karten führen viele kryptografische Operationen im Inneren der Karte aus, um solche Angriffe zu verhindern.
    Dieser Angriff dürfte höchstens bei Terminals funktionieren, bei denen von den Zahlungsoptionen nur noch der Magnetstreifenleser aktiv ist; bei solchen Terminals sollten die Skimmer-Warnlampen schon leuchten, bevor man überhaupt eine PIN-Abfrage sieht.
  • Ich weiß nicht, welche Android-Terminals je nach Region verwendet werden, aber in Indien scheinen sie Android Oreo auszuführen. Der Support endete im Januar 2021.

• Großartig. Ich mag es, darüber nachzudenken, wie man solche umfassenden Hardware-Beschränkungen wie Manipulationsschutz umgehen und ausnutzen kann, war aber bisher davon ausgegangen, dass es vorbei ist, sobald er ausgelöst wird.
  Das ist aber offenbar nicht zwingend so; es blieben immer noch viele interessante Bereiche zum Hineinschauen. Dass der Sicherheitsteil ordentlich deaktiviert wird, ist allerdings selbstverständlich. Andernfalls hätte ich jegliches Vertrauen in die Entwickler verloren.

  • Für den gehärteten Prozessor kann das immer noch stimmen. Der Originaltext schreibt ebenfalls, dass nicht dieser Teil kompromittiert wurde.
    Es sieht so aus, als würden nur Textstrings an ein Binary namens display_tool übergeben, das dann offenbar Nachrichten zwischen Prozessoren verschickt. Beim Tastenfeld und Kartenleser ist es ähnlich. Ich habe keinen Hinweis gefunden, dass diese Peripherie direkt von Linux aus zugänglich ist.
    Stattdessen scheint ein völlig separater Prozessor namens mp1 die „sicheren“ Aufgaben zu übernehmen, etwa Kartenverarbeitung, PIN-Eingabe und die Anzeige von Bildschirminformationen. Das „nicht sichere“ Linux, das auf dem zweiten Prozessor mp2 läuft, kümmert sich nur um Networking, Updates und Business-Logik.
  • Der Beschreibung nach wirkte es so, als könnte die Linux-Seite irgendeine Rolle bei der Behandlung von Manipulationsereignissen spielen.
    Ich hoffe trotzdem, dass die Architektur nur erlaubt zu sehen, dass eine Manipulation stattgefunden hat. Andernfalls könnte man sich erst eine Root-Shell verschaffen und dann eine Chance bekommen, zu verhindern, dass ein Manipulationsereignis die Sicherheitsschlüssel löscht.

• Beim Lesen über all die Manipulationserkennung des Geräts habe ich mich gefragt, wie man den Manipulationsmodus wohl am einfachsten auslöst.
  Wenn man am Ende nur ein paar solcher Geräte in diesen Zustand bringen kann, wäre das für ein Geschäft, in dem die meisten oder alle Zahlungen über diese Terminals laufen, ein effizienter Denial-of-Service-Angriff.

  • Auf den Boden fallen lassen oder Wasser darüberkippen.

• Es ist interessant, sich solche Geräte anzusehen, aber ich verstehe nicht, warum man es sofort geöffnet und damit den Manipulationszustand ausgelöst hat. Wusste man nicht, dass die meisten Lesegeräte so etwas haben?
  Die eigentlichen Tests im Manipulationszustand könnten bedeutungslos sein. Es ist durchaus möglich, dass bei einem Manipulationszustand zu Initialisierungszwecken eine Shell geöffnet wird.
  Meiner Ansicht nach sollte das Öffnen des Geräts etwas sein, das man ganz am Ende versucht.

  • Ich hatte das Gefühl, erst einmal ein Gefühl dafür bekommen zu müssen, womit ich es zu tun habe: Hardware, welcher SoC, Schnittstellen, Flash und so weiter.
    Sonst tappt man zu sehr im Dunkeln. Im Rückblick hätte ich natürlich auch einfach den Debug-Connector anzapfen und fertig sein können.
    Und ich habe auch auf einem zweiten, nicht manipulierten Gerät eine Shell bekommen.

• Solche Geräte gibt es überall in Europa. Bei der Schweiz bin ich mir nicht sicher, aber in weiten Teilen Europas, die ich kenne, besitzt oder nutzt man Kreditkarten eigentlich nicht besonders viel.
  Ich würde das POS nennen, also ein Point-of-Sale-System. Solche Geräte können alle möglichen Arten von Karten lesen. Jedenfalls ein guter Artikel.

  • Doch, sie werden tatsächlich viel genutzt. Ich habe keine Lust, all die vielen Karten im Portemonnaie mitzunehmen. Aus verschiedenen Gründen habe ich ohnehin schon haufenweise Karten, die nicht zum Bezahlen gedacht sind, sodass für etwas wie eine Debitkarte kein Platz mehr ist.
    Ich sehe auch nicht den Reiz, noch mehr Dinge ins Handy oder in die Smartwatch zu packen. Ich bevorzuge mechanische Uhren, und wenn ich mein Handy verliere, ist das aus Datenschutzsicht ohnehin schon Katastrophe genug. Aber klar, das ist nur bei mir so.