Demontage des Starlink-Nutzerterminals

• Das Starlink-Nutzerterminal von SpaceX ist die zentrale Hardware für Internetverbindungen über Satelliten im niedrigen Erdorbit
• Bei der Zerlegung des Endgeräts zeigen sich vor allem das Hochfrequenz-(RF)-Frontend und ein selbst entwickeltes SoC als Hauptkomponenten
• Die Firmware-Analyse zeigt, dass der Großteil der zentralen Software Kernel-umgehende Netzwerkverarbeitung im User Space sowie einige Kryptofunktionen umfasst
• Der Sicherheitschip STSAFE-A110 dient als zusätzliche Root of Trust und stellt Datenverschlüsselung sowie eine eindeutige Identifikation bereit
• Das Terminal enthält zahlreiche konfigurierte SSH-Public-Keys sowie ein verdächtiges Tool zur Paketaufzeichnung, Hinweise auf eine Verletzung der Privatsphäre der Nutzer gibt es jedoch nicht

---

Überblick

• Starlink ist ein von SpaceX bereitgestellter Satelliten-Internetdienst im niedrigen Erdorbit
• Nutzer verbinden sich über ein Terminal mit nahegelegenen Satelliten, die dann über Boden-Gateways mit dem Internet verbunden sind
• Satelliten der neueren Generation können mithilfe von Laser-Links untereinander kommunizieren, was zu globaler Abdeckung und höherer Effizienz beiträgt
• Auch ohne lokales Gateway kann ein Starlink-Terminal über Gateways in Nachbarländern auf das Internet zugreifen, etwa in der Ukraine
• Dieser Artikel behandelt in Kurzform die eingehende Untersuchung eines Starlink-Nutzerterminals durch DARKNAVY

Hardware-Analyse

• Ein Starlink-Nutzerterminal besteht aus zwei Teilen: Router und Antenne (UTA)
• DARKNAVY kaufte in Singapur ein Standard-Actuated-Terminal (Rev3, GenV2) und zerlegte die Antenne
• Dabei zeigte sich, dass RF-Frontend-Chips (größtenteils von STMicroelectronics) einen erheblichen Teil der Platine einnehmen
• Im zentralen Steuerbereich sitzt ein kundenspezifisches ST-SoC exklusiv für SpaceX (Quad-Core Cortex-A53), zu dem jedoch keine öffentlichen Datenblätter vorliegen
• Auf der Black Hat USA 2022 stellte Dr. Lennert Wouters von der KU Leuven einen erfolgreichen Hack des Terminals der ersten Generation (GenV1) vor; SpaceX deaktivierte daraufhin per Firmware-Update die UART-Debug-Schnittstelle
• Dennoch wurde die Umgehung der Sicherheitsmechanismen später mit zusätzlichen Methoden erneut erfolgreich demonstriert

Firmware-Extraktion und -Analyse

• DARKNAVY dumpte die Firmware direkt vom eMMC-Chip
• Da das Rev3-Board keine separaten eMMC-Debug-Pins besitzt, wurde der eMMC entfernt und die Daten mit einem Programmer ausgelesen
• Der Großteil der Firmware ist nicht verschlüsselt, sodass Boot-Kette (außer BootROM), Kernel und Teile des Dateisystems offengelegt werden konnten
• Nach dem Kernel-Start wird die Laufzeitumgebung nach /sx/local/runtime entpackt und genutzt
• bin enthält die ausführbaren Starlink-Programme, dat die Konfigurationsdateien und revision_info die Versionsinformationen
• Das zentrale Kommunikationsprogramm user_terminal_frontend wurde in Go entwickelt, der Großteil der übrigen Software besteht aus statischen C++-Binärdateien ohne Symbole
• Die Architektur des Netzwerk-Stacks ähnelt DPDK, indem sie den Kernel umgeht und die Paketverarbeitung in User-Space-Programmen stattfindet
• Der Linux-Kernel dient hauptsächlich für Hardware-Treiber und Prozessverwaltung
• Ein Teil der Software enthält Funktionen, die ursprünglich für Satelliten oder Gateways vorgesehen waren
• Beim Start identifiziert das Gerät seinen Typ anhand der Hardware-Peripherie und lädt dann nur die entsprechende Logik

Emulation

• Für die fortlaufende Analyse wurde eine QEMU-basierte Rev3-Firmware-Emulationsumgebung aufgebaut
• In dieser Umgebung gelang es, einige externe Dienste wie httpd, WebSocket und gRPC auszuführen und zu debuggen
• Dadurch ließ sich die Funktionsweise wichtiger Binärdateien und Dienste nachverfolgen

Sicherheitschip

• Zusätzlich zum Haupt-SoC ist ein STSAFE-A110-Sicherheitschip vorhanden, der eine CC-EAL5+-Zertifizierung beansprucht
• Der Chip kann unter NDA erworben werden, und das Firmware-Programm stsafe_cli interagiert mit ihm
• Die Analyse zeigt, dass der STSAFE-Chip Funktionen wie eine gerätespezifische UUID, die Verwaltung des Public-Key-Zertifikats (stsafe_leaf.pem) und die Ableitung symmetrischer Schlüssel bereitstellt
• Dieser Chip bildet eine zusätzliche Root of Trust unabhängig vom Secure Boot des SoC und entspricht damit modernen Anforderungen an Embedded-Sicherheitsdesigns

Easter Egg: Beobachtet Elon dich?

• Während der Analyse wurde das Programm Ethernet Data Recorder entdeckt, was Fragen nach einer möglichen Backdoor aufwarf
• Das Programm scheint Pakete aufzeichnen zu können und erfasst intern bestimmte Pakete mit einem pcap_filter-ähnlichen Mechanismus
• Die Regeln zeigen, dass vor allem UDP-Pakete im Zusammenhang mit Satelliten-Telemetrie erfasst werden
• Der aufgezeichnete Verkehr wird verschlüsselt gespeichert, und zwar mit einem Hardware-Schlüssel des SoC
• Bislang gibt es keine Hinweise darauf, dass Daten zur Privatsphäre der Nutzer gesammelt werden
• Erkennt das Gerät während der Initialisierung, dass es sich um ein Nutzerterminal handelt, werden 41 SSH-Public-Keys in /root/.ssh/authorized_keys eingetragen, und Port 22 ist im lokalen Netzwerk dauerhaft geöffnet
• Dass in einem kommerziellen Produkt zahlreiche unbekannte Public Keys hinterlegt sind, ist bemerkenswert

Fazit und Ausblick

• Mit der zunehmenden Nutzung von Satellitentechnologie in vielen Branchen dürften Komponenten von Satelliten-Internetsystemen wie Starlink künftig zu einem zentralen Schauplatz für Angriffe und Verteidigung im Sicherheitsbereich werden
• Aufgrund der Besonderheiten der Weltraumsicherheit kann bereits ein einziger Fehler zu einem dauerhaften Kommunikationsverlust mit dem Zielsystem führen, weshalb ein vorsichtiges Vorgehen erforderlich ist

[GN⁺]

Hacker-News-Kommentare

• Beim Initialisieren des Geräts wurde festgestellt, dass das Initialisierungsskript automatisch 41 öffentliche SSH-Schlüssel in die Datei /root/.ssh/authorized_keys schreibt, wenn das System es als Benutzerterminal erkennt; Port 22 ist im lokalen Netzwerk ebenfalls immer offen. Da stellt sich die Frage, was 41 Schlüssel bedeuten sollen und wer eigentlich Root-Zugriff auf ein Benutzerterminal hat, das „Ihnen gehört“.
  • Wahrscheinlich Sie selbst. Ernsthafter betrachtet unterscheidet sich das nicht wesentlich davon, dass ein ISP in einem bereitgestellten Router ein Remote-Management-System hat. Selbst wenn SpaceX keinen Zugriff auf das Benutzerterminal hätte, könnte der Traffic über Satelliten oder Bodenstationen überwacht werden.
  • In letzter Zeit fragt man sich, wer die beste Person wäre, um zu prüfen, ob sich darunter rückverfolgbare SSH-Schlüssel von Leuten mit besonderen Regierungsaufgaben befinden. Kürzlich gab es ja auch einen brauchbaren Leak.
  • Die 41 Schlüssel könnten einfach 41 Regionen derselben Serverinstanz entsprechen. Starlink ist ein globaler Dienst, daher ist das an sich kein Grund zur Sorge. Wenn 41 Instanzen sich einen einzigen Schlüssel teilen würden, fände ich das deutlich bedenklicher.
  • In meiner jetzigen Firma werden SSH-Schlüssel von Entwicklern nur in DEV- oder QA-Firmware ausgerollt. Produktions-Images werden nach dem Signieren vollständig ohne SSH ausgeliefert. Für Ferndiagnosen in Produktion wird separate Software verwendet, die ebenfalls über Zugriffsrechte und Freigabeprozesse im DevOps-Team kontrolliert wird. Deshalb wirkt die Entscheidung von SpaceX ungewöhnlich.
  • Ich bin ein Einzelbenutzer und habe trotzdem 25 Zeilen in authorized_keys. Darin sind verschiedene YubiKeys meines Laptops, Schlüssel vom iPad und iPhone sowie Secure-Enclave-Schlüssel vom Mac gemischt. Ich nehme an, dass es bei Starlink mindestens ein oder zwei zusätzliche Systemadministratoren gibt; selbst 100 öffentliche Schlüssel wären also keine besonders seltsame Zahl.
  • Eigentlich könnte das viel normaler und sicherheitstechnisch sinnvoller sein, als es zunächst wirkt. Es ist besser, viele getrennte Schlüssel je nach Seriennummer oder Produktionszeitraum zu verwenden, statt dass Millionen Endgeräte alle denselben Schlüssel oder nur sehr wenige Schlüssel nutzen. Die privaten Schlüssel würden dann nur zur Verwaltung kleiner Gerätegruppen dienen, und auch das Schlüsselmanagement könnte segmentiert sein.
  • Ich vermute, dass auf dieses Terminal von außen per Schlüssel nur zugegriffen werden kann, wenn gleichzeitig eine Internetverbindung im lokalen Netzwerk besteht. Ich frage mich auch, wie SSH-Verbindungen überhaupt über das Satellitennetz laufen und welche Netzstruktur Starlink dabei verwendet, etwa NAT.
• Es wird ein Link zu einem früheren Beitrag mit ähnlichem Thema über das Zerlegen eines Starlink-Benutzerterminals geteilt.
• Es wäre interessant, die 41 öffentlichen Schlüssel zu veröffentlichen und herauszufinden, welche Entwickler sie verwenden.
• Ein Archivlink zu Blogposts rund um Starlink wird geteilt.
• Der Autor wird gebeten, den Tippfehler im Titel ("ternimal") zu korrigieren.
  • Dazu kommt die scherzhafte Bemerkung, dass dies ein klassischer Fall eines keming-Problems sei.
• Überraschend ist, dass alle Pakete im Userspace verarbeitet werden. Bei 1-Gbps-Traffic mit 100-Byte-UDP-Paketen wären das eine Million Pakete pro Sekunde; auf einer 1-GHz-CPU bleiben dann nur 1000 Zyklen pro Paket. Theoretisch machbar, aber keineswegs einfach — auf einem Niveau, bei dem Ingenieure in handgeschriebenem Assembler jeden Trick ausschöpfen müssten.
  • Laut einem Paper ähnelt die Struktur des Netzwerk-Stacks der von DPDK, wobei Kernel-Bypass bei der Paketverarbeitung zentral ist. In der Praxis verarbeitet Software womöglich nur das erste Paket, und nach Aufbau einer Session kann an die Hardware übergeben werden. Manche Muster könnten weiterhin in Software behandelt werden. Etwas Ähnliches gab es früher auch bei Intel-Puma-basierten Kabelmodem-Routern.
  • Bei DPDK-artigem Forwarding gibt es weniger Pufferkopien, was sogar schneller sein kann. Starlink liegt eher im Bereich von 25–200 Mbps, und bei durchschnittlichen Paketgrößen, die 7- bis 8-mal größer sind, kommt man auf ungefähr 36.000 Pakete pro Sekunde. Für eine 1-GHz-CPU ist das gut beherrschbar.
  • Es stellt sich die Frage, warum die Paketverarbeitung im Userspace weniger effizient sein sollte als im Kernel. Wenn Hardware-Queues direkt in den Userspace gemappt werden, wird die Trennung zwischen Kernel und Userspace weit weniger relevant.
  • Bei Starlink werden eher normale 1500-Byte-MTUs verwendet als 100-Byte-UDP-Pakete.
  • Wenn Pakete im Userspace verarbeitet werden, reduziert das unnötige Speicherkopien und kann deutlich schneller sein.
• Jemand fragt sich, wie man überhaupt mit dem Reverse Engineering solcher Geräte beginnt. Reverse Engineering ist schwierig, und viele Beispiele sind alt oder teuer und daher nicht leicht nachzuvollziehen.
  • Zunächst sollte man Hardware Engineering lernen. Wenn man die Funktion oder Eigenschaften der Bauteile nicht kennt, ist Reverse Engineering an sich schon schwer.
  • Erstens muss man das Produkt kaufen und zerlegen. Zweitens muss man nach dem Zerlegen einen Weg zum Eindringen finden. Drittens probiert man es tatsächlich aus. Viertens ist man frustriert, weil man es kaputtgemacht hat. Üblicherweise steigt man über einen UART-Port ein, aber den scheint Starlink nicht zu haben, daher wurde in einem Fall der eMMC-Speicherchip ausgelötet und analysiert.
• Es wird gefragt, ob es Referenzmaterial oder fertige Lösungen für firmwarebezogene Emulation in einer QEMU-basierten Umgebung gibt, bei der externe Geräte wie GPS angeschlossen sind.
  • Als Beispiel wird angeführt, dass der Android-QEMU-Fork verschiedenste Hardware und GUI-Schnittstellen wie OpenGL, GPS, GSM und Sensoren emuliert.
• Jemand möchte lernen, wie man Firmware vor Reverse Engineering schützt, und fragt nach Einführungen zu den von SpaceX verwendeten Techniken.
  • Schritt 1 sind Maßnahmen wie Firmware-Verschlüsselung. SpaceX scheint hier aber nicht besonders proaktiv zu sein, sondern eher laufend Patches einzuspielen, wenn etwas entdeckt wird. Früher gab es sogar Debug-Pins.
  • Bei vielen Produkten, die ich genutzt habe, war die Firmware insgesamt eher unausgereift. Abgesehen von echten Sicherheitsgründen sollte man Geräte nicht unnötig absperren, sondern Ressourcen lieber für Dinge verwenden, die allen helfen. Für Power-User ist es eher ein Vorteil, wenn sie Geräte selbst modifizieren können. Wenn kein wirklich schweres Risiko besteht, sollte man dafür nicht unnötig Zeit verschwenden. Es ist schade und manchmal deprimierend, dass man so viele Geräte erst hacken muss, damit sie den eigenen Anforderungen genügen.
  • Das Mindeste wäre, das Root-Dateisystem zu verschlüsseln und dabei Geheimnisse aus einem echten Sicherheitschip zu nutzen, die sich nur schwer stehlen oder extrahieren lassen. Wenn man das Schutzniveau weiter erhöhen will, kann man mit ARM TrustZone sensible Aufgaben wie Bootloader, Entschlüsselung und Image-Signierung isolieren. Dass sich das Dateisystem so leicht dumpen lässt, bedeutet letztlich, dass SpaceX keine wirksamen Schutzmechanismen einsetzt: Nur der Bootloader ist geschützt, alles andere liegt offen.
• Es wird die Vermutung geäußert, dass dieses Gerät vielleicht denselben Codebestand wie eine Rakete nutzt, was faszinierend wirkt.
  • Noch cooler wäre es eigentlich, wenn es sich den Codebestand mit den Satelliten oder zumindest mit einem Satellitensimulator teilt, schließlich müssen allerlei Telemetriedaten übertragen werden.
  • Tatsächlich basiert es auf OpenWRT.