Fehlerpunkt: Hacken eines POS-Geräts mit WHIDBOARD

VON DER KASSE ZUR ROOT-SHELL

Vor einiger Zeit war ich in der Stadt einkaufen, als mir ein interessantes POS-Terminal (Point of Sale) auffiel. Während die Kassiererin die Einkaufstüte packte, holte ich schnell mein Handy heraus und machte ein paar Fotos für später…

Zu Hause angekommen, sah ich mir die Etiketten unter dem POS genauer an und stellte sofort etwas Interessantes fest… eine FCC-ID war deutlich zu erkennen (d. h. SEKMA512)! 😎

Passive RECON – Zeit für OSINT!

Mit dieser Information konnte ich schnell weitere Details über dieses neue DUT (Device Under Test) in Erfahrung bringen, auch ohne (noch) selbst eines zu besitzen.

In der FCC-Datenbank konnte ich weitere Details über die internen Leiterplatten, die Funktionsweise des Geräts und eventuelle Manipulationsschutzfunktionen erhalten, die Hardware-Hacking-Versuche verhindern sollen.

Insbesondere konnte ich beim Durchsehen des Handbuchs bestätigen, dass dieses POS-Gerät (wie jedes andere ähnliche Gerät, das Kreditkartendaten verarbeitet) tatsächlich über einige Schutzmaßnahmen verfügt, um zu verhindern, dass Angreifer die Leiterplatte physisch manipulieren, wie in den obigen Abbildungen dargestellt.

Ich gab jedoch nicht auf und setzte meine Recherche in den Dokumenten der FCC-Datenbank fort, um ein besseres Verständnis des gesamten Prüfobjekts zu erlangen und mein anfängliches Bedrohungsmodell zu vervollständigen, wobei ich nach potenziellen Angriffspunkten suchte.

Wie Sie auf dem obigen Bild sehen können, verfügt die Hauptplatine über eine Reihe von Testpunkten. Einige davon weckten mein Interesse, insbesondere weil sie von außen zugänglich zu sein schienen, ohne das POS-Gehäuse öffnen zu müssen – was bedeutet, dass sie geprüft werden konnten, ohne die Manipulationsschutzmechanismen auszulösen, die den Speicher des Geräts löschen würden.

Nachdem ich nun einige potenzielle Einstiegspunkte gefunden hatte, war es an der Zeit, online einige Muster zu erwerben…

Aktives RECON – Pin-Aufzählung mit WHIDBOARD

Einige Tage später trafen die DUT-Muster ein, und der erste Schritt bestand darin, die Testpunkte mit einem Multimeter zu prüfen, um festzustellen, welche elektrisch relevant waren. Nachdem ich die Auswahl eingegrenzt hatte, nutzte ich die in WHIDBOARD integrierte Logikanalysator-Funktion, um zu überprüfen, ob vom POS Daten ausgegeben wurden.

Nachdem ich verschiedene Pins ausprobiert hatte, fand ich schließlich, wie Sie auf dem Screenshot unten sehen können, die TX-Leitung einer UART-Debug-Schnittstelle. 😎

Nun ist es an der Zeit, die Pin-Enumerator-Funktion von WHIDBOARD zu nutzen, um auch den RX-Pin zu finden!

Als ich das DUT den Bootvorgang abschließen ließ, kam es zu etwas völlig Unerwartetem…

Dieser POS legte nicht nur eine voll funktionsfähige UART-Schnittstelle außerhalb seiner manipulationssicheren Sicherheitsgrenze offen – was auf ein Versagen sowohl bei der Bedrohungsmodellierung während der Forschung und Entwicklung als auch bei der Sicherheitsvalidierung vor der Produktion hindeutet –, sondern diese Debug-Schnittstelle führte auch direkt in eine Root-Shell. 💥🤯

Lassen Sie uns die Ärmel hochkrempeln – Interaktion mit dem DUT als Root

An diesem Punkt eskalierte die Situation schnell. Mithilfe von WHIDBOARD hatte ich eine exponierte UART identifiziert, die zu einem vollständigen, UNAUTORISIERTEN ROOT-ZUGANG führte…

Was als Nächstes folgte, war, dass ich das Dateisystem des Geräts erkundete, laufende Prozesse untersuchte und die interne Architektur des DUT verstand.

Schließlich extrahierte ich die gesamte Firmware über einen USB-Stick mit den folgenden Befehlen…

Und um zu beweisen, dass ich das Dateisystem nicht nur lesen, sondern auch manipulieren konnte … habe ich tatsächlich einige Änderungen vorgenommen … 😎

Aktives RECON – Netzwerkscan

An dieser Stelle habe ich aus Neugier auch nach offenen Netzwerkdiensten auf der Ethernet-Schnittstelle des DUT gesucht. Die Ergebnisse waren alarmierend: Der Telnet-Port 23/TCP war OFFEN… 🤯💥

Und ja… man konnte sich dort (als root) OHNE Passwort anmelden!

An diesem Punkt beschloss ich, auf Shodan zu überprüfen, ob eines dieser POS-Terminals mit dem Internet verbunden war. Das Ergebnis: Mindestens 61 davon waren im Internet exponiert… 🙊🙉🙈

Schlussfolgerungen

Dieses Testgerät war eine ziemliche Überraschung – in über einem Jahrzehnt der POS-Sicherheitsforschung war mir noch nie ein Gerät mit so vielen sich überschneidenden Schwachstellen begegnet. Lassen Sie uns analysieren, was schiefgelaufen ist und warum dies von Bedeutung ist.

Versagen mehrerer Ebenen der tiefgreifenden Verteidigung. Dieses Gerät wies mindestens vier unterschiedliche, unabhängig voneinander ausnutzbare Schwachstellen auf:

1. Von außen zugängliche Debug-Testpunkte, die physische Manipulationsschutzmaßnahmen umgehen;
2. Eine aktive, nicht authentifizierte UART-Konsole, die Root-Shell-Zugriff gewährt;
3. Telnet auf Port 23/TCP mit passwortfreier Root-Anmeldung über die Netzwerkschnittstelle;
4. Mindestens 61 über Shodan auffindbare Instanzen, die direkt dem Internet ausgesetzt sind.

Jeder einzelne dieser Punkte wäre für sich genommen bereits ein kritischer Befund. Zusammen stellen sie ein systemisches Versagen im Sicherheitslebenszyklus des Produkts dar – von der Bedrohungsmodellierung und dem sicheren Design über die Implementierung bis hin zu Tests vor der Produktion.

Auswirkungen auf die Zahlungsinfrastruktur. Ein POS-Terminal mit Root-Zugriff auf das Dateisystem zum Lesen und Schreiben – sowohl physisch als auch über das Netzwerk erreichbar – öffnet die Tür für Firmware-Backdoors, das Abfangen von Zahlungsdaten und die dauerhafte Installation von Schadcode. In Umgebungen, in denen PCI-DSS-Konformität erwartet wird, stellt diese Art von Schwachstelle keine marginale Lücke dar: Sie untergräbt das gesamte Vertrauensmodell. Die Tatsache, dass diese Geräte mit dem Internet verbunden waren, verstärkt das Risiko von einem lokalen physischen Angriff zu einem aus der Ferne skalierbaren Angriff.

Der regulatorische Kontext: CRA und darüber hinaus. Da der EU-Cyber-Resilience-Act (CRA) in die Umsetzungsphase eintritt, müssen Produkte mit digitalen Komponenten, die auf den europäischen Markt gebracht werden, während ihres gesamten Lebenszyklus wesentliche Cybersicherheitsanforderungen erfüllen – einschließlich einer standardmäßig sicheren Konfiguration, minimierter Angriffsflächen und Verpflichtungen zum Umgang mit Schwachstellen. Ein Gerät, das mit unauthentifiziertem Root-Zugriff sowohl über UART als auch über Telnet ausgeliefert wird, wäre ein klassisches Beispiel für eine Nichteinhaltung der Vorschriften. Hersteller und Importeure sollten solche Erkenntnisse als Vorgeschmack darauf betrachten, worauf die Regulierungsbehörden achten werden.

Wichtige Erkenntnisse für Praktiker: Unterschätzen Sie niemals öffentlich zugängliche OSINT-Informationen. Allein die FCC-Datenbank lieferte genügend Informationen, um ein vorläufiges Bedrohungsmodell zu erstellen, Manipulationsschutzgrenzen zu identifizieren und potenzielle Einstiegspunkte zu lokalisieren – und das alles, bevor auch nur ein einziges Gerät gekauft wurde. Für Red-Teamer und Sicherheitsforscher ist dies eine Erinnerung daran, dass passive Aufklärung anhand von behördlichen Einreichungen die Hardware-Bewertung erheblich beschleunigen kann. Für Hersteller und Blue-Teamer ist dies eine Erinnerung daran, dass Ihre FCC-Einreichungen, Teardowns und Servicehandbücher Teil Ihrer Angriffsfläche sind.