Desmontaje del terminal de usuario de Starlink

• El terminal de usuario de Starlink de SpaceX es el hardware clave para la conexión a internet satelital en órbita terrestre baja
• Al desmontar el terminal de usuario, se observa que los componentes principales son el frontend de radiofrecuencia (RF) y un SoC de diseño propio
• El análisis del firmware muestra que la mayor parte del software clave incluye procesamiento de red en espacio de usuario con bypass del kernel y algunas funciones criptográficas
• El chip de seguridad STSAFE-A110 actúa como una raíz de confianza adicional, además de proporcionar cifrado de datos e identificación única
• Este terminal incluye múltiples configuraciones de claves públicas SSH y una sospechosa herramienta de registro de paquetes, pero no se encontraron indicios de violación de la privacidad del usuario

---

Resumen general

• Starlink es un servicio de internet satelital de órbita terrestre baja ofrecido por SpaceX
• Los usuarios se conectan a satélites cercanos mediante el terminal, que a su vez se enlaza a internet a través de gateways terrestres
• Los satélites de nueva generación usan enlaces láser para comunicarse entre sí, lo que contribuye a mejorar la cobertura global y la eficiencia
• Incluso sin un gateway local, como en el caso de Ucrania, el terminal de Starlink puede acceder a internet usando gateways de países vecinos
• Este artículo repasa brevemente la investigación en profundidad de DARKNAVY sobre el terminal de usuario de Starlink

Análisis de hardware

• Un terminal de usuario de Starlink se compone de dos partes: el router y la antena (UTA)
• DARKNAVY compró en Singapur un terminal Standard Actuated (Rev3, GenV2) y desmontó la antena
• El desmontaje mostró que los chips del frontend RF (principalmente fabricados por STMicroelectronics) ocupaban una parte considerable de la tarjeta
• En el área de control principal se integra un SoC ST personalizado exclusivo de SpaceX (quad-core Cortex-A53), pero la información de su datasheet no es pública
• En Black Hat USA 2022, el Dr. Lennert Wouters de KU Leuven presentó un caso exitoso de hackeo del terminal de primera generación (GenV1), y posteriormente SpaceX deshabilitó la interfaz de depuración UART mediante una actualización de firmware
• Sin embargo, también hubo nuevos casos exitosos de evasión de seguridad por métodos adicionales

Extracción y análisis del firmware

• DARKNAVY volcó directamente el firmware desde el chip eMMC
• Como la placa Rev3 no tiene pines de depuración eMMC dedicados, se usó el método de retirar el eMMC y extraer los datos con un programador
• La mayor parte del firmware no estaba cifrada, por lo que quedaron expuestos la cadena de arranque (excepto BootROM), el kernel y parte del sistema de archivos
• Después del arranque del kernel, el entorno de ejecución se descomprime y se usa desde /sx/local/runtime
• bin contiene los ejecutables del software de Starlink, dat los archivos de configuración y revision_info la información de versión
• El programa de comunicación principal, user_terminal_frontend, está desarrollado en Go, mientras que la mayoría del resto son binarios estáticos de C++ sin símbolos
• La arquitectura del stack de red es similar a DPDK, donde los programas en espacio de usuario procesan los paquetes evitando el kernel
• El kernel de Linux se usa principalmente para controladores de hardware y gestión de procesos
• Parte del software incluye funciones diseñadas originalmente para satélites o gateways
• Al arrancar el dispositivo, este identifica su tipo a través de los periféricos de hardware y luego carga solo la lógica correspondiente

Emulación

• Para un análisis continuo, se construyó un entorno de emulación del firmware Rev3 basado en QEMU
• En este entorno se logró ejecutar y depurar algunos servicios expuestos, como httpd, WebSocket y gRPC
• Esto permitió rastrear el funcionamiento de los principales ejecutables y servicios

Chip de seguridad

• Además del SoC principal, existe un chip de seguridad STSAFE-A110, que afirma contar con certificación CC EAL5+
• Este chip puede adquirirse bajo NDA, y el programa stsafe_cli del firmware interactúa con él
• El análisis mostró que las funciones proporcionadas por el chip STSAFE incluyen asignación de UUID único del dispositivo, gestión del certificado de clave pública (stsafe_leaf.pem) y derivación de claves simétricas
• Este chip funciona como una raíz de confianza adicional separada del arranque seguro del SoC, en línea con los estándares modernos de diseño de seguridad embebida

Huevo de Pascua: ¿Elon te está vigilando?

• Durante el análisis se identificó un programa llamado Ethernet Data Recorder, lo que generó dudas sobre una posible puerta trasera
• Este programa parece tener funciones de registro de paquetes y captura determinados paquetes mediante un mecanismo similar a pcap_filter
• Al revisar las reglas, se puede ver que los objetivos de captura son principalmente paquetes UDP relacionados con telemetría satelital
• El tráfico capturado se almacena cifrado con una clave de hardware del SoC
• Hasta el momento no se ha encontrado evidencia de recopilación de datos de privacidad del usuario
• Durante el proceso de inicialización, si el dispositivo es reconocido como terminal de usuario, se escriben 41 claves públicas SSH en /root/.ssh/authorized_keys, y el puerto 22 permanece siempre abierto en la red local
• Llama la atención que un producto comercial tenga registradas múltiples claves públicas de origen desconocido

Conclusión y perspectivas

• A medida que la tecnología satelital se aplica a diversos sectores industriales, se espera que los componentes de sistemas de internet satelital como Starlink se conviertan en un campo de batalla clave para futuros ataques y defensas de seguridad
• Debido a la naturaleza de la seguridad espacial, un solo error puede provocar una pérdida permanente de comunicación con el objetivo, por lo que se requiere un enfoque cuidadoso

[GN⁺]

Comentarios en Hacker News

• Al inicializar el dispositivo, descubrieron que si el sistema lo reconoce como una terminal de usuario, el script de arranque escribe automáticamente 41 claves públicas SSH en el archivo /root/.ssh/authorized_keys, y además el puerto 22 siempre queda abierto en la red local. Eso hace preguntarse qué sentido tiene usar tantas claves y, al final, quién no tiene acceso root a una terminal de usuario que "te pertenece".
  • Probablemente tú. Pensándolo más en serio, no es tan distinto a que un ISP tenga un sistema de administración remota en el router que te da. Incluso si SpaceX no tuviera acceso a la terminal de usuario, igual podría monitorear el tráfico desde el satélite o la estación terrestre.
  • Últimamente da curiosidad quién sería la persona ideal para revisar si esas claves SSH son rastreables y están relacionadas con gente vinculada a tareas especiales de gobierno; además, recientemente hubo algunas filtraciones interesantes.
  • Las 41 claves podrían ser simplemente 41 instancias del mismo servidor en distintas regiones. Starlink es un servicio global, así que no parece algo especialmente preocupante. Me preocuparía más si esas 41 instancias compartieran una sola clave.
  • En la empresa donde trabajo actualmente solo distribuimos claves SSH de desarrolladores en firmware DEV o QA. Las imágenes de producción se firman y SSH queda completamente desactivado. Para diagnósticos remotos en producción usamos software aparte, también controlado con permisos de acceso y procesos de aprobación de DevOps, así que sorprende la decisión de SpaceX.
  • Yo, siendo una sola persona, ya tengo 25 líneas en authorized_keys: una mezcla de varias yubikey de mi laptop, claves del iPad y del iPhone, y claves del Secure Enclave de la Mac. Me imagino que Starlink debe tener al menos 1 o 2 administradores de sistemas más, así que 100 claves públicas tampoco suena tan raro.
  • De hecho, esto podría ser más normal y mejor para la seguridad de lo que parece. Es preferible usar varias claves separadas por número de serie o fecha de fabricación, en lugar de que millones de terminales usen todas la misma clave o unas cuantas. La clave privada podría usarse solo para administrar un pequeño subconjunto de dispositivos, y la gestión de claves también puede dividirse.
  • Supongo que solo sería posible acceder desde fuera con una clave cuando esta terminal también tenga conectividad a Internet en la red local. También da curiosidad cómo pasaría SSH por la red satelital y qué tipo de estructura de red, como NAT, usa Starlink.
• Comparten un enlace a una publicación anterior sobre un tema similar: el desarme de una terminal de usuario de Starlink.
• Piensan que sería divertido publicar las 41 claves públicas para ver qué desarrollador usa cada una.
• Comparten un enlace al archivo de publicaciones de blog relacionadas con Starlink.
• Le piden al autor que corrija el error tipográfico del título ("ternimal").
  • Mencionan con ingenio que es un caso clásico de un problema de keming.
• Sorprende que todos los paquetes se procesen en espacio de usuario. Con tráfico de 1 Gbps, asumiendo UDP de 100 bytes, eso sería un millón de paquetes por segundo. Un CPU de 1 GHz solo tendría 1000 ciclos por paquete. En teoría es posible, pero no es fácil; sería el tipo de situación donde un ingeniero tendría que recurrir a assembly escrito a mano y todo tipo de trucos.
  • Según el paper, la estructura del stack de red parece similar a DPDK, y la clave está en el procesamiento de paquetes con bypass del kernel. En la práctica, quizá solo el paquete inicial se procese en software y, una vez establecida la sesión, se pase al hardware. Algunos patrones podrían seguir manejándose en software. Ya habían visto algo similar en routers con módem por cable de la vieja familia Intel Puma.
  • En el caso de forwarding estilo DPDK, al reducir copias de buffer incluso podría ser más rápido. Starlink se mueve en el rango de 25-200 Mbps, y como el tamaño promedio de los paquetes es 7 u 8 veces mayor, eso da alrededor de 36 mil paquetes por segundo. Para un CPU de 1 GHz es una carga manejable.
  • Se preguntan por qué procesar paquetes en userspace tendría que ser menos eficiente que hacerlo en el kernel. Si las colas de hardware se mapean al espacio de usuario, la distinción kernel-userspace deja de importar tanto.
  • En el caso de Starlink, se usa un MTU normal de 1500 bytes más que paquetes UDP de 100 bytes.
  • Procesar paquetes en userspace reduce copias de memoria innecesarias y puede ser mucho más rápido.
• Expresan curiosidad sobre cómo empezar a hacer ingeniería inversa de este tipo de equipos. La ingeniería inversa es difícil, y muchos ejemplos disponibles son antiguos o caros, así que no es fácil practicar.
  • Primero hay que aprender algo de ingeniería de hardware. Si no entiendes para qué sirve cada componente o cuáles son sus características, la ingeniería inversa en sí se vuelve difícil.
  • Lo primero es comprar el producto y desarmarlo. Lo segundo es pensar cómo abrirle camino después de desarmarlo. Lo tercero es intentarlo de verdad. Lo cuarto es frustrarte al descubrir que lo rompiste. Normalmente se entra por un puerto UART, pero parece que Starlink no lo tiene, así que en este caso analizaron el chip de memoria eMMC después de retirarlo.
• Preguntan si existe material de referencia o alguna solución lista para emular firmware que se conecta a dispositivos externos, como GPS, en un entorno de emulación basado en QEMU.
  • Como ejemplo, comentan que el fork de QEMU de Android emula distintos tipos de hardware e interfaces GUI, incluyendo OpenGL, GPS, GSM y sensores.
• Quieren aprender cómo proteger firmware contra la ingeniería inversa y se preguntan si hay material introductorio sobre las técnicas que usa SpaceX.
  • El primer paso serían medidas como cifrar el firmware. SpaceX tampoco parece ser especialmente proactivo; más bien da la impresión de que van parchando cosas a medida que se descubren. Antes incluso había pines de depuración.
  • Muchos productos que han usado tienen un firmware bastante mediocre. Salvo por motivos reales de seguridad, piden que no se bloquee todo innecesariamente y que los recursos se usen en cosas que beneficien a todos. Para usuarios avanzados, poder modificar directamente el dispositivo incluso puede ser una ventaja. Si no hay un riesgo de intrusión realmente serio, preferirían que no se pierda tiempo en eso. Resulta triste, e incluso a veces deprimente, tener que hackear tantos dispositivos para adaptarlos a necesidades reales.
  • Como mínimo, lo básico sería cifrar el sistema de archivos root usando secretos almacenados en un chip de seguridad real, difícil de robar o extraer. Si se quiere subir más el nivel, se puede usar ARM TrustZone para aislar tareas sensibles como el bootloader, el descifrado o la firma de imágenes. El simple hecho de poder volcar el sistema de archivos con tanta facilidad significa que SpaceX no está usando protecciones efectivas en la práctica: solo el bootloader estaría protegido y todo lo demás queda expuesto.
• A alguien le parece curioso si este equipo usará la misma base de código que un cohete.
  • Lo que les parecería todavía más genial es que compartiera base de código con los satélites, o al menos con un simulador de satélites, ya que tiene que enviar toda clase de telemetría.
  • En realidad está basado en OpenWRT.