Démontage du terminal utilisateur Starlink

• Le terminal utilisateur Starlink de SpaceX constitue le matériel clé de la connexion Internet par satellite en orbite terrestre basse
• Le démontage du terminal utilisateur montre que les principaux composants sont le frontend radiofréquence (RF) et un SoC conçu sur mesure
• L’analyse du firmware révèle que la majeure partie du logiciel critique comprend un traitement réseau en espace utilisateur contournant le kernel ainsi que certaines fonctions de chiffrement
• La puce de sécurité STSAFE-A110 joue le rôle de racine de confiance supplémentaire et fournit le chiffrement des données ainsi qu’un identifiant unique
• Le terminal inclut de multiples configurations de clés publiques SSH et un outil suspect d’enregistrement de paquets, mais aucun indice d’atteinte à la vie privée des utilisateurs n’a été observé

---

Vue d’ensemble

• Starlink est un service Internet par satellite en orbite terrestre basse proposé par SpaceX
• Les utilisateurs se connectent à un satellite proche via le terminal, qui est ensuite relié à Internet par une passerelle au sol
• Les satellites de nouvelle génération utilisent des liaisons laser pour communiquer entre eux, ce qui contribue à améliorer la couverture mondiale et l’efficacité
• Même sans passerelle locale, comme en Ukraine par exemple, le terminal Starlink peut accéder à Internet via une passerelle située dans un pays voisin
• Cet article présente brièvement les résultats de l’enquête approfondie de DARKNAVY sur un terminal utilisateur Starlink

Analyse matérielle

• Un terminal utilisateur Starlink se compose de deux parties : un routeur et une antenne (UTA)
• DARKNAVY a acheté à Singapour un terminal Standard Actuated (Rev3, GenV2) et a démonté l’antenne
• Le démontage a montré que les puces du frontend RF (principalement fabriquées par STMicroelectronics) occupaient une grande partie de la carte
• La zone de contrôle centrale embarque un SoC ST personnalisé exclusif à SpaceX (quad-core Cortex-A53), mais sa fiche technique n’est pas publique
• Lors de Black Hat USA 2022, le Dr Lennert Wouters de la KU Leuven a présenté un cas de compromission réussie d’un terminal de première génération (GenV1), et SpaceX a ensuite désactivé l’interface de debug UART via une mise à jour du firmware
• Cependant, d’autres méthodes ont par la suite permis à nouveau de contourner la sécurité

Extraction et analyse du firmware

• DARKNAVY a extrait directement le firmware depuis la puce eMMC
• La carte Rev3 ne disposant pas de broches de debug eMMC dédiées, la méthode utilisée a consisté à retirer l’eMMC puis à extraire les données avec un programmateur
• La majeure partie du firmware n’était pas chiffrée, ce qui a permis de révéler la chaîne de boot (hors BootROM), le kernel et une partie du système de fichiers
• Après le démarrage du kernel, l’environnement d’exécution est décompressé dans /sx/local/runtime
• bin contient les exécutables logiciels de Starlink, dat les fichiers de configuration, et revision_info les informations de version
• Le programme de communication principal, user_terminal_frontend, est développé en Go, tandis que la plupart des autres sont des binaires C++ statiques sans symboles
• L’architecture de la stack réseau ressemble à DPDK, avec des programmes en espace utilisateur chargés du traitement des paquets en contournant le kernel
• Le kernel Linux sert principalement aux pilotes matériels et à la gestion des processus
• Une partie du logiciel inclut des fonctions initialement conçues pour des usages satellite ou passerelle
• Au démarrage de l’appareil, le type est identifié à partir des périphériques matériels, puis seule la logique correspondante est chargée et utilisée

Émulation

• Un environnement d’émulation du firmware Rev3 basé sur QEMU a été mis en place pour poursuivre l’analyse
• Dans cet environnement, l’exécution et le debug de certains services exposés comme httpd, WebSocket et gRPC ont réussi
• Il est ainsi devenu possible de suivre le fonctionnement des principaux exécutables et services

Puce de sécurité

• En plus du SoC principal, une puce de sécurité STSAFE-A110 est présente et revendique une certification CC EAL5+
• Cette puce peut être achetée sous NDA, et le programme stsafe_cli du firmware interagit avec elle
• L’analyse montre que les fonctions fournies par la puce STSAFE incluent l’attribution d’un UUID unique à l’appareil, la gestion du certificat à clé publique (stsafe_leaf.pem) et la dérivation de clés symétriques
• Cette puce constitue une racine de confiance supplémentaire distincte du secure boot du SoC, conformément aux principes modernes de conception de sécurité embarquée

Easter egg : Elon vous surveille-t-il ?

• Au cours de l’analyse, le programme Ethernet Data Recorder a été identifié, soulevant des questions sur une éventuelle possibilité de backdoor
• Ce programme semble disposer d’une fonction d’enregistrement de paquets et capture en interne certains paquets via un mécanisme similaire à pcap_filter
• D’après les règles observées, les paquets capturés sont principalement des paquets UDP liés à la télémétrie satellite
• Le trafic capturé est stocké après chiffrement avec une clé matérielle du SoC
• À ce jour, aucune preuve de collecte de données portant atteinte à la vie privée des utilisateurs n’a été trouvée
• Lors de l’initialisation, si l’appareil est reconnu comme terminal utilisateur, 41 clés publiques SSH sont inscrites dans /root/.ssh/authorized_keys, et le port 22 reste toujours ouvert sur le réseau local
• La présence de nombreuses clés publiques d’origine inconnue dans un produit commercial mérite l’attention

Conclusion et perspectives

• À mesure que les technologies satellitaires se déploient dans divers secteurs industriels, les composants des systèmes d’Internet par satellite comme Starlink devraient devenir un terrain central pour les futures attaques et défenses de sécurité
• En sécurité spatiale, une seule erreur peut entraîner une perte définitive de communication avec la cible, ce qui impose une approche prudente

[GN⁺]

Commentaires Hacker News

• Lors de l’initialisation de l’appareil, il a été constaté que si le système est reconnu comme un terminal utilisateur, le script d’initialisation écrit automatiquement 41 clés publiques SSH dans le fichier /root/.ssh/authorized_keys, et que le port 22 reste également toujours ouvert sur le réseau local ; cela soulève la question du sens de 41 clés, et finalement de savoir qui n’a pas accès root à un terminal utilisateur « que vous possédez »
  • Probablement vous ; en y réfléchissant plus sérieusement, ce n’est pas très différent du fait qu’un routeur fourni par un FAI embarque un système d’administration à distance ; même si SpaceX n’avait pas accès au terminal utilisateur, l’entreprise pourrait surveiller le trafic depuis les satellites ou les stations au sol
  • Je me demande récemment qui serait la personne idéale pour vérifier si certaines de ces clés SSH sont traçables jusqu’à des personnes impliquées dans des opérations gouvernementales sensibles ; il y a aussi eu une bonne fuite récemment
  • Il est possible que les 41 clés correspondent simplement à la même instance de serveur dans 41 régions différentes ; Starlink étant un service mondial, il n’y a rien de particulièrement inquiétant à cela ; en revanche, si 41 instances partageaient une seule clé, ce serait plus préoccupant
  • Dans mon entreprise actuelle, nous ne déployons les clés SSH des développeurs que sur les firmwares DEV ou QA ; les images de production sont signées puis SSH y est complètement désactivé ; en production, nous utilisons un logiciel séparé pour le diagnostic à distance, lui aussi encadré par des droits d’accès et un processus d’approbation DevOps ; c’est pourquoi le choix de SpaceX m’étonne
  • Je suis un utilisateur unique et j’ai pourtant 25 lignes dans authorized_keys, avec un mélange de clés issues de plusieurs YubiKey de mon laptop, de mon iPad et de mon iPhone, ainsi que des clés Secure Enclave de mon Mac ; j’imagine que Starlink emploie au moins une ou deux personnes de plus pour l’administration système, donc même 100 clés publiques ne me sembleraient pas si étranges
  • En réalité, cela peut être un choix plus banal et plus sain du point de vue de la sécurité qu’on ne le pense ; il vaut mieux utiliser plusieurs clés séparées selon le numéro de série ou la période de fabrication que d’avoir des millions de terminaux tous configurés avec la même clé ou avec un très petit nombre de clés ; les clés privées peuvent n’être utilisées que pour administrer un petit sous-ensemble de terminaux, et la gestion des clés peut elle aussi être segmentée
  • Je suppose qu’un accès externe par clé n’est possible que lorsque ce terminal est aussi connecté à Internet sur le réseau local ; je me demande également comment une connexion SSH traverserait le réseau satellite, et je suis curieux de savoir comment Starlink structure son réseau, notamment avec le NAT
• Partage d’un lien vers un précédent article sur un sujet similaire : un démontage de terminal utilisateur Starlink
• Je pense qu’il serait amusant de publier les 41 clés publiques pour voir quel développeur utilise quoi
• Partage d’un lien vers les archives d’un billet de blog sur Starlink
• Demande à l’auteur de corriger la faute de frappe dans le titre ("ternimal")
  • Remarque amusée indiquant qu’il s’agit d’un exemple classique de problème de keming (espacement irrégulier entre les lettres)
• Le fait que tous les paquets soient traités en espace utilisateur semble surprenant ; avec un trafic à 1 Gbit/s (sur la base de paquets UDP de 100 octets), cela représente un million de paquets par seconde ; un CPU à 1 GHz ne dispose alors que de 1000 cycles par paquet ; c’est théoriquement possible, mais loin d’être simple, au point d’exiger qu’un ingénieur code directement en assembleur en exploitant toutes les astuces imaginables
  • D’après l’article, l’architecture de la pile réseau semble proche de DPDK, le point clé étant le traitement des paquets en contournant le noyau ; en pratique, seul le premier paquet serait traité par logiciel, puis une fois la session établie, le relais pourrait être pris par le matériel ; certains motifs pourraient toutefois continuer à être traités en logiciel ; j’ai déjà vu une approche similaire sur d’anciens routeurs/modems câble Intel Puma
  • Avec un forwarding de style DPDK, la réduction des copies de buffers peut au contraire rendre l’ensemble plus rapide ; Starlink opère plutôt entre 25 et 200 Mbit/s, et la taille moyenne des paquets étant 7 à 8 fois plus grande, on tourne plutôt autour de 36 000 paquets par seconde ; c’est une charge acceptable pour un CPU à 1 GHz
  • Je me demande pourquoi le traitement des paquets en espace utilisateur serait moins efficace que dans le noyau ; si les files matérielles sont mappées vers l’espace utilisateur, la distinction noyau/espace utilisateur perd de son importance
  • Dans le cas de Starlink, on utilise plutôt le MTU standard de 1500 octets que des paquets UDP de 100 octets
  • Traiter les paquets en espace utilisateur réduit les copies mémoire inutiles et peut être bien plus rapide
• Expression d’une curiosité sur la manière de commencer le reverse engineering de ce type d’équipement ; le reverse engineering est difficile, et la plupart des exemples sont anciens ou coûteux, donc peu accessibles
  • Il faut d’abord apprendre l’ingénierie matérielle ; sans comprendre le rôle ou les caractéristiques des composants, le reverse engineering lui-même devient difficile
  • Première étape : acheter le produit et le démonter ; deuxième étape : réfléchir à une façon de le percer après démontage ; troisième étape : essayer réellement ; quatrième étape : être abattu en constatant qu’on l’a cassé ; en général on entre par un port UART, mais Starlink semble ne pas en avoir, d’où des cas d’analyse passant par le dessoudage de la puce mémoire eMMC
• Question sur l’existence de références ou de solutions prêtes à l’emploi pour l’émulation de firmware connecté à des périphériques externes (GPS, etc.) dans un environnement d’émulation basé sur QEMU
  • Présentation du fork Android de QEMU comme exemple, puisqu’il émule divers matériels et interfaces GUI tels qu’OpenGL, le GPS, le GSM et des capteurs
• Souhait d’apprendre comment protéger un firmware contre le reverse engineering, et interrogation sur l’existence de ressources d’introduction aux techniques utilisées par SpaceX
  • La première étape consiste à mettre en place des mesures comme le chiffrement du firmware ; SpaceX ne semble pas particulièrement proactive sur ce point et paraît plutôt corriger au fur et à mesure des découvertes ; il y avait autrefois même des broches de debug
  • Beaucoup de produits que j’ai utilisés présentaient un faible niveau de finition côté firmware ; en dehors des besoins de sécurité, j’aimerais qu’on évite de tout verrouiller et qu’on consacre les ressources à des choses utiles à tous ; pour les power users, pouvoir modifier directement l’appareil est plutôt un avantage ; sauf risque d’intrusion vraiment grave, j’aimerais qu’on ne perde pas inutilement du temps sur ce genre de restrictions ; le fait de devoir bidouiller divers appareils pour les adapter à ses besoins est regrettable et parfois même déprimant
  • A minima, il faudrait chiffrer le système de fichiers racine en s’appuyant sur des secrets stockés dans une véritable puce de sécurité rendant le vol ou l’extraction difficiles ; pour aller plus loin, ARM TrustZone peut servir à isoler les opérations sensibles comme le bootloader, le déchiffrement ou la signature des images ; le simple fait que le système de fichiers puisse être dumpé facilement montre que SpaceX n’utilise pas de protections concrètes dans ce domaine ; seul le bootloader semble protégé, le reste restant exposé
• Étonnement à l’idée que cet équipement puisse éventuellement partager une base de code avec les fusées
  • Ce qui serait encore plus impressionnant serait plutôt un partage de base de code avec les satellites, voire avec un simulateur de satellite, puisqu’il faut envoyer diverses télémétries
  • En pratique, c’est basé sur OpenWRT