Zerlegung eines Starlink-Nutzerterminals

 (darknavy.org)
1 Punkte von GN⁺ 2025-05-11 | 1 Kommentare | Auf WhatsApp teilen
  • DARKNAVY hat die Antenne eines in Singapur gekauften Starlink Standard Actuated zerlegt und Hardware, Firmware, Sicherheitschip sowie Möglichkeiten zur Emulation vorläufig analysiert
  • Der größte Teil der Antennen-PCB wird vom RF-Frontend von STMicroelectronics eingenommen; die zentrale Steuereinheit ist auf einer Seite des Boards konzentriert, was einer Struktur ähnelt, wie man sie von typischen IoT-Geräten kennt
  • Die Rev3-Firmware wurde durch Ausbau und Dumpen der eMMC extrahiert; da sie größtenteils unverschlüsselt war, konnten Teile der Boot Chain, der Kernel, Teile des Dateisystems und die Laufzeitkonfiguration untersucht werden
  • Die extrahierte Software enthält offenbar nicht nur Funktionen für Nutzerterminals, sondern auch für Satelliten und Boden-Gateways; beim Start scheint die Geräteart anhand von Hardware-Peripherie identifiziert zu werden
  • Der Ethernet Data Recorder zeichnet Pakete im Zusammenhang mit Satelliten-Telemetrie auf und verschlüsselt sie mit einem Hardware-Schlüssel; auf der UTA werden jedoch automatisch 41 öffentliche SSH-Schlüssel registriert, und Port 22 ist im lokalen Netzwerk dauerhaft geöffnet

Starlink-Nutzerterminal und Umfang der Analyse

  • Starlink ist der Satelliteninternetdienst im niedrigen Erdorbit von SpaceX; Nutzer verbinden sich über ein Nutzerterminal mit Satelliten in niedriger Erdumlaufbahn und gelangen über Boden-Gateways ins Internet
  • Neuere Satellitengenerationen enthalten schrittweise Laserlinks, sodass einige Satelliten direkt miteinander kommunizieren können
    • Dadurch sinkt die Abhängigkeit von Bodenstationen, die Übertragungseffizienz steigt und die globale Abdeckung verbessert sich
    • Auch auf dem ukrainischen Schlachtfeld ohne lokale Bodenstationen können Starlink-Nutzerterminals über Inter-Satellite-Links indirekt Gateways in Nachbarländern erreichen
  • Die Untersuchung von DARKNAVY konzentriert sich nicht auf das gesamte Starlink-Nutzerterminal, sondern auf die Antennenkomponente, die User Terminal Antenna, UTA
    • Das Zielgerät war ein in Singapur gekauftes Starlink Standard Actuated
    • Es wird auch als Rev3 oder GenV2 bezeichnet

Ergebnisse der Hardware-Zerlegung

  • Ein vollständiges Starlink-Nutzerterminal besteht aus zwei Teilen: Router und Antenne
  • Die PCB der zerlegten UTA war fast so groß wie das Außengehäuse
    • Den größten Teil des Boards nehmen von STMicroelectronics hergestellte RF-Frontend-Chips ein
    • Die zentralen Steuerkomponenten sind überwiegend auf einer Seite der PCB gruppiert
  • Abgesehen von der RF-Antenne ähnelt das Gesamtdesign des Kernbereichs der UTA stark einem typischen IoT-Gerät
  • Der Haupt-SoC ist ein von ST kundenspezifisch für SpaceX gefertigter quad-core Cortex-A53
    • Hardware und Datenblatt dieses Chips sind derzeit vertraulich und nicht öffentlich zugänglich
  • Auf der Black Hat USA 2022 demonstrierte Dr. Lennert Wouters von der KU Leuven einen Fault-Injection-Angriff auf die Starlink-Antenne der ersten Generation, GenV1, und erlangte eine Root-Shell auf dem Gerät
    • SpaceX deaktivierte anschließend per Firmware-Update die UART-Debug-Schnittstelle der PCB, um die Widerstandsfähigkeit gegen Fault-Angriffe zu erhöhen
    • Wouters verbesserte seinen Ansatz und konnte erneut eindringen

Firmware-Extraktion und Softwarestruktur

  • Für eine tiefere Analyse der UTA dumpte DARKNAVY die Firmware direkt aus dem eMMC-Chip
    • Auf dem Rev3-Board gab es keine klar erkennbaren eMMC-Debug-Pins
    • Der eMMC-Chip musste von der PCB entfernt und anschließend mit einem Programmer ausgelesen werden
  • Der Großteil der extrahierten Firmware war unverschlüsselt
    • Boot Chain mit Ausnahme des BootROM
    • Kernel
    • Unverschlüsselte Bereiche des Dateisystems
  • Nach dem Kernelstart wird der Großteil der Laufzeitumgebung von der eMMC gelesen und in das Verzeichnis /sx/local/runtime entpackt
  • In der Laufzeitstruktur enthält bin die für den Starlink-Software-Stack benötigten ausführbaren Dateien, dat speichert Konfigurationsdateien, und revision_info dokumentiert die aktuellen Software- und Hardwareversionen
  • user_terminal_frontend, das die Kommunikation mit externen Nutzern verarbeitet, ist in Go geschrieben; die meisten übrigen Programme sind statisch kompilierte C++-Executables ohne Symbole
  • In einer ersten Analyse auf Basis früherer Forschung ähnelt die Architektur des Netzwerk-Stacks in gewissem Maß DPDK
    • Vor allem C++-Programme im User Space verarbeiten Netzwerkpakete unter Umgehung des Kernels
    • Der Linux-Kernel dient hauptsächlich der Bereitstellung grundlegender Hardwaretreiber und des Prozessmanagements
  • Die aus der UTA extrahierte Kernsoftware enthält auch Funktionen, die offenbar zu Satelliten oder Boden-Gateways gehören
    • Nach anfänglichem Reverse Engineering identifiziert das System beim Start die Geräteart anhand der Hardware-Peripherie
    • Danach lädt und startet es die zur jeweiligen Geräteart passende Logik

QEMU-basierte Emulation

  • DARKNAVY baute eine QEMU-basierte Emulationsumgebung für die Rev3-Firmware auf, um die UTA kontinuierlich leichter analysieren zu können
  • In dieser Umgebung gelang es, Teile der Software auszuführen und zu debuggen, die mit externen Entitäten interagieren
    • httpd
    • WebSocket
    • gRPC-Dienste

Sicherheitschip STSAFE-A110

  • Neben dem Haupt-SoC ist in der UTA ein dedizierter Sicherheitschip, der STSAFE-A110, verbaut
    • Dieser Chip beansprucht die Sicherheitszertifizierung CC EAL5+
    • Anders als der kundenspezifische SoC kann er legal unter NDA erworben werden
  • In der UTA-Firmware übernimmt ein User-Space-Programm namens stsafe_cli die Interaktion mit diesem Chip
  • Das Reverse Engineering legt nahe, dass STSAFE vor allem folgende Funktionen bereitstellt
    • Eindeutige Kennung jedes Geräts, UUID
    • Verwaltung des öffentlichen Schlüsselzertifikats stsafe_leaf.pem, das vermutlich für die Authentifizierung der Satellitenkommunikation genutzt wird
    • Ableitung symmetrischer Verschlüsselungsschlüssel für die Übertragung von Nutzerdaten
  • Der Chip fungiert unabhängig vom Secure-Boot-Mechanismus des SoC als zusätzlicher Root of Trust und passt damit zu modernen Sicherheitsdesigns für Embedded-Systeme

Ethernet Data Recorder und SSH-Schlüssel

  • Während der Analyse wurde ein Programm namens Ethernet Data Recorder gefunden, das allein nach Name und Funktion als Backdoor zum Erfassen von Nutzerdaten verdächtig wirken könnte
  • Eine genauere Prüfung ergab, dass dieses Programm über einen pcap_filter-ähnlichen Mechanismus bestimmte Netzwerkpakete aufzeichnet
    • Beispiele für Capture-Regeln enthalten die Bedingung udp and dst port 10017 sowie bestimmte Multicast-Zielhosts
    • Anderen Hinweisen in der Firmware zufolge stehen diese Pakete im Zusammenhang mit Satelliten-Telemetrie
  • Der gesamte aufgezeichnete Traffic wird mit einem in den SoC gefuseten Hardware-Schlüssel verschlüsselt
  • Auf Basis der derzeit verfügbaren Informationen lässt sich schwer sagen, dass diese Funktion Daten zur Privatsphäre der Nutzer sammelt
  • Wenn das System sich während der Geräteinitialisierung als Nutzerterminal identifiziert, schreibt ein Initialisierungsskript automatisch 41 öffentliche SSH-Schlüssel nach /root/.ssh/authorized_keys
    • Port 22 der UTA ist im lokalen Netzwerk dauerhaft geöffnet
    • Auffällig ist, dass in einem Verbraucherprodukt so viele unbekannte Login-Schlüssel vorhanden sind

Sicherheitskontext von Satelliteninternetsystemen

  • Da sich Satellitentechnologie weiterentwickelt und in unterschiedlichen Branchen eingesetzt wird, können die einzelnen Komponenten von Starlink und anderen Satelliteninternetsystemen künftig zu wichtigen Bereichen für Angriffs- und Verteidigungsoperationen werden
  • In der Weltraumsicherheit müssen sich Entwickler und Hacker nicht nur mit der digitalen Domäne, sondern auch mit den Beschränkungen der Weltraumphysik auseinandersetzen
    • Eine einzige falsche Operation kann dazu führen, dass der Kontakt zum Ziel dauerhaft verloren geht

Referenzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-11
Meinungen auf Hacker News

  • Dass bei der Initialisierung, wenn es als Nutzerterminal erkannt wird, automatisch 41 öffentliche SSH-Schlüssel in /root/.ssh/authorized_keys eingetragen werden, lässt mich eher fragen, wer eigentlich keinen Root-Zugriff auf „mein“ Nutzerterminal hat.

    • Vermutlich der Nutzer selbst.
      Etwas ernster betrachtet: Ist das so viel anders als ein Remote-Management-System auf einem vom ISP bereitgestellten Router? Selbst wenn SpaceX nicht direkt auf das Nutzerterminal zugreifen kann, können sie den Traffic auf Satelliten oder Bodenstationen mitschneiden.
    • Ich frage mich, wer wohl am besten in der Lage wäre, einige dieser Schlüssel mit Personen in Verbindung zu bringen, die zuletzt an speziellen Regierungsaufträgen beteiligt waren. Es gab ja auch ein paar gute Leaks.
    • 41 Schlüssel müssen nicht unbedingt besorgniserregend sein. Es könnten Server-Instanzen in 41 Regionen sein, die jeweils ihren eigenen Schlüssel haben; Starlink ist schließlich ein globaler Dienst.
      Eher würde ich mir Sorgen machen, wenn 41 Instanzen einen einzigen Schlüssel gemeinsam nutzen würden.
    • Selbst mein authorized_keys als einzelner Privatanwender hat 25 Zeilen. Unterschiedliche YubiKeys pro Laptop, Schlüssel von iPad und iPhone sowie der Secure-Enclave-Schlüssel des Macs.
      Starlink dürfte auch mehr als nur ein oder zwei Systemadministratoren haben, daher halte ich etwa 100 öffentliche Schlüssel für vertretbar.
    • Diese Entscheidung verstehe ich wirklich kaum. Bei meinem aktuellen Arbeitgeber werden Entwickler-SSH-Schlüssel nur auf Geräte mit DEV- oder QA-Firmware verteilt; Produktions-Images sind signiert und SSH ist vollständig deaktiviert.
      Für die Diagnose technischer Probleme an Produktionsgeräten gibt es separate Remote-Access-Software, mit der man zwar eine REPL starten kann, der Zugriff ist aber durch Zugriffskontrollen und DevOps-Freigaben abgesichert.

  • Frühere Diskussion zu einer ähnlichen Einreichung: Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 (2. Dezember 2020 — 158 Punkte, 138 Kommentare)

  • Wenn 41 öffentliche Schlüssel eingetragen sind, kann man vermutlich herausfinden, welche Entwickler sie verwenden.

  • https://web.archive.org/www.darknavy.org/blog/a_first_glimps...

  • Dass alle Pakete im User Space verarbeitet werden, ist überraschend.
    Wenn man 1 Gbps Traffic mit 100-Byte-UDP-Paketen verarbeitet, muss man eine Million Pakete pro Sekunde schaffen. Bei einer 1-GHz-CPU bleiben nur 1000 Zyklen pro Paket.
    Möglich ist das, aber einfach ist es nicht, es sei denn, die Ingenieure schreiben gern Assembler von Hand und tüfteln an allen möglichen Lookup-Table-Tricks.

    • Üblicherweise werden die ersten Pakete in Software verarbeitet, und sobald der Endpunkt etabliert ist, geht der weitere Flow an die Hardware über. Bestimmte Muster werden auch immer in Software verarbeitet.
      Die Software kann ein gepatchter Kernel sein oder ein XDP-artiger Kernel-Bypass. Das ist eine Vermutung aus meiner Rand-Erfahrung mit DPDK oder Ähnlichem bei Intel-Puma-Kabelmodem-Routern/-Gateways.
    • Bei der Weiterleitung kann ein DPDK-artiger Ansatz schneller sein, weil er Buffer-Kopien reduziert.
      Starlink liegt bei etwa 25 bis 200 Mbps, und die durchschnittlichen Pakete sind 7- bis 8-mal größer; damit sind es höchstens ungefähr 36.000 Pakete pro Sekunde, was selbst bei 1 GHz ziemlich gut zu bewältigen ist.
    • Ich sehe nicht, warum das weniger effizient sein sollte als die Paketverarbeitung im Kernel. Es gibt Ansätze, Hardware-Queues in den User Space zu mappen, und der Artikel sagt ebenfalls, dass das System eine DPDK-ähnliche Struktur hat.
      An dem Punkt verstehe ich nicht, warum es wichtig sein sollte, ob der Polling-Code im Kernel liegt.
    • 100 Byte? Starlink verwendet eine normale 1500-Byte-MTU.
    • Die Verarbeitung im User Space ist viel schneller, weil man ein zusätzliches memcpy vermeiden kann.

  • Es wäre gut, den Tippfehler im Titel zu korrigieren. Aktuell steht dort „Ternimal“.

    • Ein klassisches Keming-Problem.

  • Ich frage mich, wie man mit so etwas anfängt. Reverse Engineering ist schwierig, und ich denke, Basteleien an Geräten sind meistens entweder wirklich teuer oder betreffen alte Hardware, die nicht mehr weiterentwickelt wird. Ausnahmen gibt es sicher.

    • Erstens: das Ding kaufen. Zweitens: zerlegen. Drittens: sich einen Angriffsweg überlegen. Viertens: es tatsächlich ausprobieren. Fünftens: es kaputtmachen und fluchen.
      Normalerweise gibt es UART, aber beim Starlink-Terminal scheint es keinen UART zu geben, also hat diese Person stattdessen den eMMC-Speicherchip ausgelötet. Im Grunde so etwas wie eine fest verlötete microSD-Karte.
    • Zuerst sollte man wohl etwas Hardware-Engineering lernen. Wenn man nicht weiß, was die Bauteile tun und wie man mit ihnen umgeht, ist Reverse Engineering schwierig.

  • Dort steht: „DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware“. Ich frage mich, ob es Materialien oder fertige Lösungen gibt, um Firmware zu emulieren, die mit externen Geräten wie GPS verbunden ist.

    • https://android.googlesource.com/platform/external/qemu/+/2d...
      Der Android Emulator ist ein Downstream des QEMU-Emulators und ergänzt Unterstützung für das Booten von Android-Geräten sowie die Emulation typischer Android-Hardware (OpenGL, GPS, GSM, Sensoren) und GUI-Schnittstellen. Der Android Emulator erweitert QEMU auf mehrere Arten.

  • Mich interessiert, wie man Firmware in einem Produkt vor Reverse Engineering schützen sollte. Gibt es Materialien, die die von SpaceX verwendeten Techniken vorstellen?

    • Schritt 1 wäre wohl so etwas wie verschlüsselte Firmware, aber SpaceX scheint nichts zu tun oder nur nachträglich zu reagieren. Es gab sogar Debug-Pins, bis jemand einen Angriff über diese Pins veröffentlicht hat.
    • Mindestens sollte man rootfs mit einem Geheimnis verschlüsseln, das aus einem Security-Element schwer zu extrahieren ist. Einen Schritt weiter könnte man etwas wie ARMs TrustZone verwenden, um sensible Aufgaben wie Bootloader, Entschlüsselung und Image-Signaturen zu verbergen.
      Dass man das Dateisystem einfach dumpen konnte, legt nahe, dass SpaceX außer dem im Artikel erwähnten Bootloader keinen besonderen Schutz angewendet hat.
    • Aus der Perspektive von jemandem, der viele gute Produkte mit schlechter Firmware genutzt hat: Bitte macht das nicht, wenn es keinen starken, realistischen und ausreichend analysierten Grund dafür gibt.
      Ich fände es besser, die Ressourcen für Dinge einzusetzen, die allen nützen und das Produkt verbessern. Für fortgeschrittene Nutzer kann die theoretische Möglichkeit, ein Produkt zu modifizieren — sogar auf eine Art, an die der Hersteller nie gedacht hat — ein großer Vorteil sein.
      Aus Sicht eines technischen Endnutzers sieht es so aus: Ich bin wirklich müde davon und ein bisschen deprimiert, dass ich Geräte hacken muss, um Lampen, Katzenfutterautomaten und inzwischen sogar Rudergeräte richtig zu nutzen.
    • Wenn sie Linux verwenden, könnte das vermutlich zu einer GPL-Verletzung führen.

  • Wäre cool, wenn das auf derselben Codebasis basiert, die sie auch für Raketen verwenden, oder?

    • Noch cooler gesagt wäre es wohl eine Codebasis, die mit den Satelliten geteilt wird. Oder vielleicht ein Satellitensimulator; in jedem Fall irgendetwas, das Telemetrie senden muss.
    • Nein, es basiert auf OpenWRT.