Desmontaje del terminal de usuario de Starlink

 (darknavy.org)
1 puntos por GN⁺ 2025-05-11 | 1 comentarios | Compartir por WhatsApp
  • DARKNAVY desmontó la antena del Starlink Standard Actuated comprado en Singapur y realizó un análisis preliminar del hardware, firmware, chip de seguridad y posibilidades de emulación
  • La mayor parte del PCB de la antena está ocupada por el front-end RF de STMicroelectronics, y la sección principal de control está concentrada en un lado de la placa, mostrando una estructura similar a la de un dispositivo IoT común
  • El firmware Rev3 se volcó retirando el eMMC, y como en su mayor parte estaba sin cifrar, fue posible revisar parte de la cadena de arranque, el kernel, parte del sistema de archivos y la configuración en tiempo de ejecución
  • El software extraído incluye funciones que parecen corresponder no solo al terminal de usuario, sino también a satélites y gateways terrestres, y parece identificar el tipo de dispositivo al arrancar mediante los periféricos de hardware
  • Ethernet Data Recorder registra paquetes relacionados con la telemetría satelital y los cifra con claves de hardware, pero en la UTA se registran automáticamente 41 claves públicas SSH y el puerto 22 permanece siempre abierto en la red local

Terminal de usuario de Starlink y alcance del análisis

  • Starlink es el servicio de internet satelital en órbita baja de SpaceX, donde los usuarios se conectan a satélites en órbita terrestre baja mediante un terminal de usuario y luego acceden a internet a través de gateways terrestres
  • Las generaciones más nuevas de satélites incorporan gradualmente enlaces láser, lo que permite que algunos satélites se comuniquen directamente entre sí
    • Esto reduce la dependencia de estaciones terrestres, mejora la eficiencia de transmisión y amplía la cobertura global
    • Incluso en el frente de guerra de Ucrania, donde no hay estaciones terrestres locales, los terminales de usuario de Starlink pueden conectarse indirectamente a gateways de países vecinos a través de enlaces entre satélites
  • La investigación de DARKNAVY no se centra en todo el terminal de usuario de Starlink, sino en el componente de antena User Terminal Antenna, UTA
    • El equipo analizado fue un Starlink Standard Actuated comprado en Singapur
    • También se le conoce como Rev3 o GenV2

Resultados del desmontaje de hardware

  • Un terminal de usuario completo de Starlink está compuesto por dos partes: el router y la antena
  • El PCB de la UTA desmontada tenía casi el mismo tamaño que la carcasa exterior
    • La mayor parte de la placa está ocupada por los chips front-end RF fabricados por STMicroelectronics
    • Los componentes principales de control están agrupados principalmente en un lado del PCB
  • Excepto por la antena RF, el diseño general del área central de la UTA es bastante similar al de un dispositivo IoT típico
  • El SoC principal es un Cortex-A53 de cuatro núcleos personalizado por ST para SpaceX
    • Actualmente, el hardware y la hoja de datos de este chip son confidenciales y no están disponibles públicamente
  • En Black Hat USA 2022, el Dr. Lennert Wouters de KU Leuven mostró cómo obtener una root shell del dispositivo realizando un ataque por inyección de fallas contra la antena Starlink de primera generación GenV1
    • Después de eso, SpaceX deshabilitó mediante una actualización de firmware la interfaz de depuración UART del PCB para reforzar la resistencia frente a ataques por fallas
    • Wouters mejoró su enfoque y logró volver a comprometer el sistema

Extracción del firmware y estructura del software

  • Para analizar la UTA con mayor profundidad, DARKNAVY hizo un volcado directo del firmware desde el chip eMMC
    • La placa Rev3 no tenía pines de depuración eMMC claramente identificables
    • Fue necesario retirar el chip eMMC del PCB y leerlo con un programador
  • La mayor parte del firmware extraído estaba sin cifrar
    • La cadena de arranque, excepto el BootROM
    • El kernel
    • Las áreas no cifradas del sistema de archivos
  • Tras iniciar el kernel, gran parte del entorno de ejecución se lee desde el eMMC y se despliega en el directorio /sx/local/runtime
  • Dentro de la estructura de runtime, bin contiene los ejecutables necesarios para el stack de software de Starlink, dat almacena archivos de configuración y revision_info registra las versiones actuales de software y hardware
  • user_terminal_frontend, que maneja la comunicación con usuarios externos, está escrito en Go, mientras que la mayoría del resto de los programas son ejecutables C++ compilados estáticamente y sin símbolos
  • En un análisis inicial basado en investigaciones previas, la arquitectura del stack de red parece ser hasta cierto punto similar a DPDK
    • Principalmente, programas C++ en espacio de usuario procesan paquetes de red evitando pasar por el kernel
    • El kernel de Linux cumple sobre todo el rol de proporcionar controladores básicos de hardware y gestión de procesos
  • El software principal extraído de la UTA también incluye funciones que parecen pertenecer a satélites o gateways terrestres
    • Según la ingeniería inversa inicial, durante el arranque el sistema identifica el tipo de dispositivo en función de los periféricos de hardware
    • Luego carga y ejecuta la lógica correspondiente a ese tipo de dispositivo

Emulación basada en QEMU

  • Para facilitar el análisis continuo de la UTA, DARKNAVY construyó un entorno de emulación basado en QEMU para el firmware Rev3
  • En este entorno logró ejecutar y depurar parte del software que interactúa con entidades externas
    • httpd
    • WebSocket
    • servicios gRPC

Chip de seguridad STSAFE-A110

  • Además del SoC principal, la UTA incorpora un chip de seguridad dedicado, el STSAFE-A110
    • Este chip afirma contar con una certificación de seguridad CC EAL5+
    • A diferencia del SoC personalizado, puede adquirirse legalmente bajo NDA
  • En el firmware de la UTA, un programa en espacio de usuario llamado stsafe_cli gestiona la interacción con este chip
  • Según los resultados de la ingeniería inversa, STSAFE parece proporcionar principalmente las siguientes funciones
    • El identificador único de cada dispositivo, UUID
    • La gestión del certificado de clave pública stsafe_leaf.pem, que se presume usado para la autenticación de comunicaciones satelitales
    • La derivación de claves de cifrado simétrico para la transmisión de datos del usuario
  • Este chip actúa como una raíz adicional de confianza independiente del mecanismo de secure boot del SoC, alineándose con prácticas modernas de diseño de seguridad embebida

Ethernet Data Recorder y claves SSH

  • Durante el análisis se encontró un programa llamado Ethernet Data Recorder, que por su nombre y función podría parecer un backdoor para capturar datos del usuario
  • Sin embargo, una revisión más detallada mostró que este programa registra ciertos paquetes de red mediante un mecanismo similar a pcap_filter
    • Entre los ejemplos de reglas de captura se incluyen la condición udp and dst port 10017 y hosts destino multicast específicos
    • Con base en otras pistas dentro del firmware, estos paquetes están relacionados con la telemetría satelital
  • Todo el tráfico capturado se cifra usando claves de hardware fusionadas en el SoC
  • Con la información disponible hasta ahora, es difícil concluir que esta función recolecte datos privados de los usuarios
  • Durante la inicialización del dispositivo, si el sistema se identifica como terminal de usuario, un script de arranque escribe automáticamente 41 claves públicas SSH en /root/.ssh/authorized_keys
    • El puerto 22 de la UTA permanece siempre abierto en la red local
    • Llama la atención que un producto para usuarios tenga tantas claves de acceso desconocidas

Contexto de seguridad en los sistemas de internet satelital

  • A medida que la tecnología satelital sigue avanzando y se aplica en distintas industrias, cada componente de Starlink y de otros sistemas de internet satelital podría convertirse en un área importante para futuras operaciones ofensivas y defensivas
  • En la seguridad espacial, desarrolladores y hackers deben enfrentarse no solo al ámbito digital, sino también a las limitaciones de la física espacial
    • Un solo error de manipulación puede hacer que se pierda permanentemente el contacto con el objetivo

Material de referencia

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-05-11
Opiniones en Hacker News

  • Que durante la inicialización, si se identifica como terminal de usuario, agregue automáticamente 41 claves públicas SSH a /root/.ssh/authorized_keys hace que me dé más curiosidad saber quién no tiene acceso root a “mi” terminal de usuario

    • Probablemente el propio usuario.
      Viéndolo un poco más en serio, no parece tan distinto de que un router provisto por el ISP tenga un sistema de administración remota. Aunque SpaceX no pudiera acceder directamente al terminal de usuario, igual podría capturar tráfico desde el satélite o las estaciones terrestres
    • Me pregunto quién estaría en mejor posición para vincular algunas de estas claves con personas que recientemente participaron en tareas gubernamentales especiales. También hubo algunas filtraciones buenas
    • Que sean 41 no necesariamente es algo preocupante. Podrían ser instancias de servidores en 41 regiones, cada una con su propia clave, y Starlink es un servicio global, así que sería natural.
      Más bien me preocuparía si 41 instancias compartieran una sola clave
    • Mi authorized_keys, siendo un usuario individual, también tiene 25 líneas. Tengo YubiKey distintas para cada laptop, claves del iPad y del iPhone, y una clave de Secure Enclave de la Mac.
      Starlink seguramente tiene más que 1 o 2 administradores de sistemas, así que unas 100 claves públicas me parecerían razonables
    • Esta decisión realmente me cuesta entenderla. En mi trabajo actual, las claves SSH de los desarrolladores se despliegan solo en dispositivos con firmware DEV o QA, las imágenes de producción están firmadas y SSH está completamente desactivado.
      Para diagnosticar problemas de ingeniería en dispositivos de producción tenemos software separado de acceso remoto y se puede abrir un REPL, pero está bloqueado por controles de acceso y aprobaciones de DevOps

  • Discusión anterior de un envío similar: Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 (2 de diciembre de 2020 — 158 puntos, 138 comentarios)

  • Si publican las 41 claves públicas, probablemente se podría identificar qué desarrolladores las usan

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

  • Me sorprende que todos los paquetes se procesen en espacio de usuario.
    Si se maneja tráfico de 1 Gbps con paquetes UDP de 100 bytes, hay que procesar 1 millón de paquetes por segundo. Con una CPU de 1 GHz, eso deja apenas 1000 ciclos por paquete.
    Es posible, pero no es fácil, salvo que a los ingenieros les guste escribir assembly a mano y pensar en todo tipo de técnicas con tablas de consulta

    • Normalmente el software procesa los paquetes iniciales y, una vez establecido el endpoint, los flujos posteriores pasan al hardware. Ciertos patrones también se procesan siempre en software.
      El software podría ser un kernel parcheado o un bypass de kernel al estilo XDP. Es una suposición basada en mi experiencia tocando de manera periférica DPDK o algo similar en routers/gateways con módem de cable Intel Puma
    • Para el reenvío, un enfoque tipo DPDK puede ser más rápido porque reduce las copias de buffers.
      Starlink está entre unos 25 y 200 Mbps, y el paquete promedio también es 7 u 8 veces más grande, así que como mucho son alrededor de 36.000 paquetes por segundo, algo bastante manejable incluso a 1 GHz
    • No veo por qué tendría que ser menos eficiente que procesar paquetes en el kernel. Hay formas de mapear colas de hardware al espacio de usuario, y el artículo dice que el sistema tiene una estructura similar a DPDK.
      Llegado ese punto, no veo por qué importa que el código de polling esté dentro del kernel
    • ¿100 bytes? Starlink usa el MTU típico de 1500 bytes
    • Procesarlo en espacio de usuario permite evitar un memcpy adicional, así que es mucho más rápido

  • Estaría bueno corregir el typo del título. Ahora dice “Ternimal”

    • Es un caso clásico de keming

  • Me pregunto cómo se empieza con algo así. La ingeniería inversa es difícil, y creo que jugar con hardware casi siempre termina siendo realmente caro o con equipos tan viejos que ya no se desarrollan. Aunque seguramente hay excepciones

    • Primero, compras el aparato. Segundo, lo desarmas. Tercero, piensas cómo infiltrarte. Cuarto, lo intentas de verdad. Quinto, lo rompes y maldices.
      Normalmente hay UART, pero parece que el terminal de Starlink no tiene UART, así que esta persona en su lugar retiró el chip de memoria eMMC. En la práctica es como una tarjeta microSD soldada
    • Creo que primero hay que aprender algo de ingeniería de hardware. Si no sabes qué hacen los componentes y cómo manipularlos, la ingeniería inversa es difícil

  • Dice “DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware”, y me pregunto si hay material o soluciones ya preparadas para emular firmware que se conecta a dispositivos externos como GPS

  • Me interesa saber cómo habría que proteger firmware en productos para evitar la ingeniería inversa. ¿Habrá material que presente las técnicas que usó SpaceX?

    • El primer paso sería algo como firmware cifrado, pero SpaceX parece no hacer nada o solo reaccionar después. Incluso tenía pines de depuración hasta que alguien publicó un ataque usando esos pines
    • Como mínimo habría que cifrar el rootfs con un secreto difícil de extraer de un elemento seguro. Un paso más sería usar algo como TrustZone de ARM para ocultar operaciones sensibles como el bootloader, el descifrado y la firma de imágenes.
      El hecho de que se pudiera volcar el sistema de archivos sin más sugiere que SpaceX no aplicó mucha protección aparte del bootloader mencionado en el artículo
    • Como alguien que ha usado muchos productos buenos con firmware malo, por favor no hagan eso salvo que haya una razón sólida, realista y suficientemente analizada.
      Creo que es mejor usar los recursos en algo que beneficie a todos y mejore el producto. Para usuarios avanzados, la posibilidad teórica de modificar el producto —incluso de formas que el fabricante nunca imaginó— puede ser una gran ventaja.
      Desde el punto de vista de un usuario final técnico, se ve así: estoy realmente cansado, y un poco deprimido, de tener que hackear dispositivos para poder usar correctamente luces, comederos para gatos y ahora hasta máquinas de remo
    • Si están usando Linux, probablemente podría derivar en una violación de la GPL

  • Sería genial si esto estuviera basado en una base de código compartida con los cohetes, ¿no?

    • Dicho de forma más genial, quizás sea una base de código compartida con los satélites. O tal vez sea un simulador de satélite; en cualquier caso, es algo que tiene que enviar telemetría
    • No, está basado en OpenWRT