Démontage d’un terminal utilisateur Starlink

 (darknavy.org)
1 points par GN⁺ 2025-05-11 | 1 commentaires | Partager sur WhatsApp
  • DARKNAVY a démonté l’antenne du Starlink Standard Actuated acheté à Singapour afin de mener une analyse préliminaire du matériel, du firmware, de la puce de sécurité et des possibilités d’émulation
  • La majeure partie du PCB de l’antenne est occupée par le front-end RF de STMicroelectronics, tandis que l’unité de contrôle principale est concentrée sur un côté de la carte, une structure similaire à celle d’un appareil IoT classique
  • Le firmware Rev3 a été dumpé en retirant l’eMMC ; la majeure partie étant non chiffrée, il a été possible d’examiner une partie de la chaîne de démarrage, le noyau, une partie du système de fichiers et la configuration d’exécution
  • Le logiciel extrait inclut des fonctionnalités qui semblent destinées non seulement au terminal utilisateur, mais aussi aux satellites et aux passerelles au sol ; au démarrage, le type d’appareil semble être identifié via les périphériques matériels
  • Ethernet Data Recorder enregistre des paquets liés à la télémétrie satellite et les chiffre avec une clé matérielle, mais 41 clés publiques SSH sont automatiquement enregistrées sur l’UTA et le port 22 reste toujours ouvert sur le réseau local

Terminal utilisateur Starlink et périmètre de l’analyse

  • Starlink est le service d’Internet par satellites en orbite basse de SpaceX : les utilisateurs se connectent aux satellites en orbite terrestre basse via un terminal utilisateur, puis à Internet via des passerelles au sol
  • Les nouvelles générations de satellites intègrent progressivement des liaisons laser, permettant à certains satellites de communiquer directement entre eux
    • Cela réduit la dépendance aux stations au sol, améliore l’efficacité de transmission et étend la couverture mondiale
    • Même sur le champ de bataille ukrainien, où il n’existe pas de station au sol locale, les terminaux utilisateur Starlink peuvent accéder indirectement aux passerelles de pays voisins grâce aux liaisons intersatellites
  • L’enquête de DARKNAVY ne porte pas sur l’ensemble du terminal utilisateur Starlink, mais se concentre sur le composant d’antenne, la User Terminal Antenna, UTA
    • L’équipement étudié est un Starlink Standard Actuated acheté à Singapour
    • Il est aussi appelé Rev3 ou GenV2

Résultats du démontage matériel

  • Un terminal utilisateur Starlink complet se compose de deux parties : un routeur et une antenne
  • Le PCB de l’UTA démontée était presque aussi grand que le boîtier externe
    • La majeure partie de la carte est occupée par des puces front-end RF fabriquées par STMicroelectronics
    • Les principaux composants de contrôle sont surtout regroupés sur un côté du PCB
  • En excluant l’antenne RF, la conception globale de la zone centrale de l’UTA ressemble beaucoup à celle d’un appareil IoT classique
  • Le SoC principal est un Cortex-A53 quad-core conçu sur mesure par ST pour SpaceX
    • Le matériel et la fiche technique de cette puce sont actuellement confidentiels et non publics
  • À Black Hat USA 2022, le Dr Lennert Wouters de la KU Leuven a démontré une attaque par injection de fautes sur l’antenne Starlink de première génération GenV1, obtenant un shell root sur l’appareil
    • SpaceX a ensuite renforcé la résistance aux attaques par faute au moyen d’une mise à jour du firmware désactivant l’interface de débogage UART du PCB
    • Wouters a amélioré son approche et est parvenu à s’introduire de nouveau dans l’appareil

Extraction du firmware et structure logicielle

  • Pour analyser plus en profondeur l’UTA, DARKNAVY a dumpé directement le firmware depuis la puce eMMC
    • La carte Rev3 ne disposait pas de broches de débogage eMMC clairement identifiables
    • Il a fallu dessouder la puce eMMC du PCB, puis la lire avec un programmateur
  • La majeure partie du firmware extrait était non chiffrée
    • La chaîne de démarrage, à l’exception de la BootROM
    • Le noyau
    • Les zones non chiffrées du système de fichiers
  • Après le démarrage du noyau, la majeure partie de l’environnement d’exécution est lue depuis l’eMMC et décompressée dans le répertoire /sx/local/runtime
  • Dans la structure d’exécution, bin contient les exécutables nécessaires à la pile logicielle Starlink, dat stocke les fichiers de configuration, et revision_info consigne les versions actuelles du logiciel et du matériel
  • user_terminal_frontend, qui gère les communications utilisateur externes, est écrit en Go, tandis que la plupart des autres programmes sont des exécutables C++ compilés statiquement et dépourvus de symboles
  • D’après une analyse initiale fondée sur des travaux existants, l’architecture de la pile réseau ressemble dans une certaine mesure à DPDK
    • Les paquets réseau sont principalement traités par des programmes C++ en espace utilisateur, en contournant le noyau
    • Le noyau Linux joue surtout le rôle de fournisseur de pilotes matériels de base et de gestion des processus
  • Le logiciel central extrait de l’UTA inclut aussi des fonctionnalités qui semblent relever des satellites ou des passerelles au sol
    • D’après le reverse engineering initial, le système identifie le type d’appareil au démarrage à partir des périphériques matériels
    • Il charge et exécute ensuite la logique correspondant à ce type d’appareil

Émulation basée sur QEMU

  • Afin de faciliter l’analyse continue de l’UTA, DARKNAVY a construit un environnement d’émulation basé sur QEMU pour le firmware Rev3
  • Dans cet environnement, l’équipe a réussi à exécuter et déboguer certains logiciels interagissant avec des entités externes
    • httpd
    • WebSocket
    • Services gRPC

Puce de sécurité STSAFE-A110

  • Outre le SoC principal, l’UTA embarque une puce de sécurité dédiée, la STSAFE-A110
    • Cette puce revendique un niveau de sécurité CC EAL5+
    • Contrairement au SoC personnalisé, elle peut être achetée légalement sous NDA
  • Dans le firmware de l’UTA, un programme en espace utilisateur appelé stsafe_cli gère les interactions avec cette puce
  • Le reverse engineering suggère que STSAFE fournit principalement les fonctions suivantes
    • Un identifiant unique, UUID, pour chaque appareil
    • La gestion du certificat de clé publique stsafe_leaf.pem, supposément utilisé pour l’authentification des communications satellite
    • La dérivation de clés de chiffrement symétriques pour la transmission des données utilisateur
  • Cette puce joue le rôle de root of trust supplémentaire, indépendant du mécanisme de secure boot du SoC, ce qui correspond aux pratiques modernes de conception de sécurité embarquée

Ethernet Data Recorder et clés SSH

  • Au cours de l’analyse, un programme nommé Ethernet Data Recorder a été découvert ; à en juger uniquement par son nom et ses fonctions, il pourrait être soupçonné d’être une porte dérobée de capture de données utilisateur
  • Un examen détaillé montre que ce programme enregistre certains paquets réseau au moyen d’un mécanisme similaire à pcap_filter
    • Des exemples de règles de capture incluent la condition udp and dst port 10017 ainsi qu’un hôte de destination multicast spécifique
    • D’après d’autres indices présents dans le firmware, ces paquets sont liés à la télémétrie satellite
  • Tout le trafic capturé est chiffré à l’aide d’une clé matérielle fusionnée dans le SoC
  • Au vu des informations actuellement disponibles, il est difficile de considérer que cette fonctionnalité collecte des données de confidentialité utilisateur
  • Lors de l’initialisation de l’appareil, si le système s’identifie comme terminal utilisateur, un script d’initialisation écrit automatiquement 41 clés publiques SSH dans /root/.ssh/authorized_keys
    • Le port 22 de l’UTA est toujours ouvert sur le réseau local
    • La présence d’un si grand nombre de clés de connexion inconnues dans un produit destiné aux utilisateurs est notable

Contexte de sécurité des systèmes Internet par satellite

  • À mesure que les technologies satellitaires continuent de progresser et d’être appliquées à divers secteurs, chaque composant de Starlink et d’autres systèmes d’Internet par satellite pourrait devenir un domaine important pour les futures opérations d’attaque et de défense
  • Dans la sécurité spatiale, développeurs et hackers doivent composer non seulement avec le domaine numérique, mais aussi avec les contraintes de la physique spatiale
    • Une seule mauvaise manipulation peut faire perdre définitivement le contact avec la cible

Références

À lire aussi

1 commentaires

 
GN⁺ 2025-05-11
Commentaires sur Hacker News

  • Le fait qu’à l’initialisation, si l’appareil est identifié comme un terminal utilisateur, il ajoute automatiquement 41 clés publiques SSH à /root/.ssh/authorized_keys me fait surtout me demander qui n’a pas d’accès root à « mon » terminal utilisateur

    • Probablement l’utilisateur lui-même.
      Plus sérieusement, est-ce si différent d’un système d’administration à distance sur un routeur fourni par un FAI ? Même si SpaceX ne peut pas accéder directement au terminal utilisateur, l’entreprise peut tout de même capturer le trafic depuis un satellite ou une station au sol
    • Je me demande qui serait le mieux placé pour faire le lien entre certaines de ces clés et des personnes récemment impliquées dans des missions gouvernementales spéciales. Il y a aussi eu quelques bonnes fuites de données
    • 41 clés n’est pas forcément inquiétant. Il se peut que des instances serveur dans 41 régions aient chacune leur clé, et comme Starlink est un service mondial, cela paraît naturel.
      Ce qui m’inquiéterait davantage, ce serait que 41 instances partagent une seule clé
    • Même mon authorized_keys, pour un seul utilisateur particulier, fait 25 lignes. J’ai une YubiKey différente pour chaque laptop, les clés de mon iPad et de mon iPhone, et la clé Secure Enclave de mon Mac.
      Starlink doit avoir plus d’un ou deux administrateurs système, donc une centaine de clés publiques me semblerait raisonnable
    • Ce choix est vraiment difficile à comprendre. Dans mon entreprise actuelle, les clés SSH des développeurs ne sont déployées que sur les appareils exécutant un firmware DEV ou QA, les images de production sont signées et SSH est complètement désactivé.
      Pour diagnostiquer les problèmes d’ingénierie sur les appareils de production, il existe un logiciel d’accès à distance distinct qui peut lancer un REPL, mais l’accès est encadré par le contrôle d’accès et des validations DevOps

  • Discussion précédente d’une soumission similaire : Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 (2 décembre 2020 — 158 points, 138 commentaires)

  • Si les 41 clés publiques sont publiées, on pourra probablement vérifier quels développeurs les utilisent

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

  • Le fait que tous les paquets soient traités en espace utilisateur est surprenant.
    Pour traiter 1 Gbit/s de trafic avec des paquets UDP de 100 octets, il faut traiter un million de paquets par seconde. Avec un CPU à 1 GHz, cela ne laisse que 1 000 cycles par paquet.
    C’est possible, mais ce n’est pas simple, sauf si les ingénieurs aiment coder de l’assembleur à la main et réfléchir à toutes sortes de techniques de tables de correspondance

    • En général, les paquets initiaux sont traités en logiciel, puis une fois l’endpoint établi, le flux suivant est transféré au matériel. Certains motifs sont aussi toujours traités en logiciel.
      Le logiciel peut être un noyau patché, ou un contournement du noyau façon XDP. C’est une supposition fondée sur une expérience périphérique avec DPDK ou des solutions similaires sur des routeurs/passerelles de modems câble Intel Puma
    • Pour le forwarding, une approche façon DPDK peut être plus rapide en réduisant les copies de buffers.
      Starlink est plutôt autour de 25 à 200 Mbit/s et la taille moyenne des paquets est 7 à 8 fois plus grande, donc au maximum environ 36 000 paquets par seconde, ce qui reste assez gérable même à 1 GHz
    • Je ne vois pas pourquoi cela devrait être moins efficace que de traiter les paquets dans le noyau. Il existe des façons de mapper les files matérielles en espace utilisateur, et l’article indique aussi que le système a une architecture similaire à DPDK.
      À ce stade, je ne vois pas en quoi il importe que le code de polling soit dans le noyau ou non
    • 100 octets ? Starlink utilise une MTU classique de 1 500 octets
    • Le traitement en espace utilisateur permet d’éviter un memcpy supplémentaire, donc c’est beaucoup plus rapide

  • Ce serait bien de corriger la faute de frappe dans le titre. Pour l’instant, il est écrit « Ternimal »

    • Un problème typique de crénage (keming)

  • Je me demande comment on se lance dans ce genre de choses. La rétro-ingénierie est difficile, et bricoler du matériel est généralement soit très coûteux, soit concerne du matériel ancien qui n’est plus développé. Il y a des exceptions, bien sûr

    • Premièrement, acheter l’objet. Deuxièmement, le démonter. Troisièmement, réfléchir à une méthode d’intrusion. Quatrièmement, essayer pour de vrai. Cinquièmement, le casser et jurer.
      En général il y a un UART, mais il semble que le terminal Starlink n’en ait pas, donc cette personne a plutôt dessoudé la puce mémoire eMMC. En pratique, c’est un peu comme une carte microSD soudée
    • Il faut sans doute commencer par apprendre un peu d’ingénierie matérielle. Si l’on ne sait pas à quoi servent les composants ni comment les manipuler, la rétro-ingénierie est difficile

  • Il est écrit que « DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware » ; je me demande s’il existe des ressources ou des solutions toutes prêtes pour émuler un firmware connecté à des périphériques externes comme le GPS

    • https://android.googlesource.com/platform/external/qemu/+/2d...
      Android Emulator est un dérivé downstream de l’émulateur QEMU ; il ajoute la prise en charge du démarrage des appareils Android et émule le matériel Android courant (OpenGL, GPS, GSM, capteurs) ainsi que l’interface graphique. Android Emulator étend QEMU de plusieurs façons

  • Je m’intéresse à la manière dont il faudrait protéger un firmware dans un produit pour empêcher sa rétro-ingénierie. Existe-t-il des ressources présentant les techniques utilisées par SpaceX ?

    • La première étape serait quelque chose comme un firmware chiffré, mais SpaceX semble ne rien faire, ou seulement réagir après coup. Il y avait même des broches de debug jusqu’à ce que quelqu’un publie une attaque les utilisant
    • Au minimum, il faudrait chiffrer le rootfs avec une valeur secrète difficile à extraire depuis un élément sécurisé. En allant plus loin, on peut utiliser quelque chose comme TrustZone d’ARM pour dissimuler les opérations sensibles comme le bootloader, le déchiffrement et la signature des images.
      Le fait qu’il ait été possible de simplement dumper le système de fichiers suggère que, hormis le bootloader mentionné dans l’article, SpaceX n’a pas appliqué beaucoup de protections
    • Pour avoir utilisé beaucoup de bons produits au firmware médiocre, je vous en prie, ne faites pas cela sans une raison solide, réaliste et suffisamment analysée.
      Je pense qu’il vaut mieux consacrer les ressources à quelque chose qui profite à tout le monde et améliore le produit. Pour les utilisateurs avancés, la possibilité théorique de modifier le produit, y compris d’une manière que le fabricant n’avait même pas imaginée, peut être un gros avantage.
      Du point de vue d’un utilisateur final technique, c’est ainsi que je le vois. Je suis vraiment fatigué, et un peu déprimé, de devoir hacker des appareils pour utiliser correctement des lampes, des distributeurs de nourriture pour chats, et maintenant même un rameur
    • Si cela utilise Linux, cela peut probablement entraîner une violation de la GPL

  • Ce serait cool si c’était basé sur une base de code partagée avec les fusées, non ?

    • Pour le dire de façon encore plus cool, ce serait une base de code partagée avec les satellites. Ou alors peut-être un simulateur de satellite ; en tout cas, quelque chose qui doit envoyer de la télémétrie
    • Non, c’est basé sur OpenWRT