Desmontagem do terminal de usuário da Starlink

 (darknavy.org)
1 pontos por GN⁺ 2025-05-11 | 1 comentários | Compartilhar no WhatsApp
  • A DARKNAVY desmontou a antena do Starlink Standard Actuated comprado em Singapura e fez uma análise preliminar de hardware, firmware, chip de segurança e possibilidades de emulação
  • A maior parte da PCB da antena é ocupada pelo front-end de RF da STMicroelectronics, enquanto a unidade de controle principal fica concentrada em um lado da placa, exibindo uma estrutura semelhante à de dispositivos IoT comuns
  • O firmware Rev3 foi despejado removendo a eMMC, e a maior parte estava sem criptografia, permitindo verificar parte da cadeia de boot, o kernel, partes do sistema de arquivos e a configuração de runtime
  • O software extraído inclui funcionalidades que parecem ser destinadas não apenas ao terminal de usuário, mas também a satélites e gateways terrestres; na inicialização, a estrutura parece identificar o tipo de dispositivo por meio de periféricos de hardware
  • O Ethernet Data Recorder registra pacotes relacionados à telemetria de satélites e os criptografa com uma chave de hardware, mas 41 chaves públicas SSH são registradas automaticamente na UTA, e a porta 22 fica sempre aberta na rede local

Terminal de usuário da Starlink e escopo da análise

  • A Starlink é um serviço de internet por satélites de órbita baixa da SpaceX; os usuários se conectam a satélites em órbita próxima à Terra por meio de um terminal de usuário e acessam a internet passando por gateways terrestres
  • As novas gerações de satélites vêm incorporando gradualmente links a laser, permitindo que alguns satélites se comuniquem diretamente entre si
    • Isso reduz a dependência de estações terrestres, aumenta a eficiência de transmissão e melhora a cobertura global
    • Mesmo no front ucraniano, onde não há estações terrestres locais, terminais de usuário da Starlink podem se conectar indiretamente a gateways de países vizinhos por meio de links entre satélites
  • A investigação da DARKNAVY se concentra não no terminal de usuário da Starlink como um todo, mas no componente de antena, a User Terminal Antenna, UTA
    • O equipamento analisado é um Starlink Standard Actuated comprado em Singapura
    • Também é chamado de Rev3 ou GenV2

Resultados da desmontagem de hardware

  • Um terminal de usuário Starlink completo é composto por duas partes: roteador e antena
  • A PCB da UTA desmontada tinha quase o mesmo tamanho da carcaça externa
    • A maior parte da placa é ocupada por chips de front-end de RF fabricados pela STMicroelectronics
    • Os componentes principais de controle ficam reunidos principalmente em um lado da PCB
  • Excluindo a antena de RF, o projeto geral da área central da UTA é bastante semelhante ao de um dispositivo IoT comum
  • O SoC principal é um Cortex-A53 quad-core feito sob medida pela ST para a SpaceX
    • Atualmente, o hardware e o datasheet desse chip são confidenciais e não estão disponíveis publicamente
  • Na Black Hat USA 2022, o Dr. Lennert Wouters, da KU Leuven, demonstrou um ataque de injeção de falhas em uma antena Starlink de primeira geração, GenV1, obtendo um root shell no dispositivo
    • Depois disso, a SpaceX desativou a interface de debug UART da PCB por meio de uma atualização de firmware, aumentando a resistência a ataques de falha
    • Wouters aprimorou sua abordagem e conseguiu invadir novamente

Extração do firmware e estrutura do software

  • Para analisar a UTA em mais profundidade, a DARKNAVY fez um dump direto do firmware a partir do chip eMMC
    • A placa Rev3 não tinha pinos de debug eMMC claramente identificáveis
    • Foi necessário remover o chip eMMC da PCB e lê-lo com um programador
  • A maior parte do firmware extraído estava sem criptografia
    • Cadeia de boot, exceto a BootROM
    • Kernel
    • Áreas não criptografadas do sistema de arquivos
  • Após a inicialização do kernel, a maior parte do ambiente de runtime é lida da eMMC e descompactada no diretório /sx/local/runtime
  • Na estrutura de runtime, bin contém os executáveis necessários para a pilha de software da Starlink, dat armazena arquivos de configuração, e revision_info registra as versões atuais de software e hardware
  • O user_terminal_frontend, que trata a comunicação externa com o usuário, foi escrito em Go, enquanto a maioria dos outros programas são executáveis C++ compilados estaticamente e sem símbolos
  • Em uma análise inicial baseada em pesquisas anteriores, a arquitetura da pilha de rede é, em certa medida, semelhante ao DPDK
    • Principalmente programas C++ em espaço de usuário processam pacotes de rede contornando o kernel
    • O kernel Linux tem sobretudo o papel de fornecer drivers básicos de hardware e gerenciamento de processos
  • O software principal extraído da UTA também inclui funcionalidades que parecem pertencer a satélites ou gateways terrestres
    • Pela engenharia reversa inicial, o sistema identifica o tipo de dispositivo durante a inicialização com base em periféricos de hardware
    • Em seguida, carrega e executa a lógica adequada a esse tipo de dispositivo

Emulação baseada em QEMU

  • A DARKNAVY criou um ambiente de emulação baseado em QEMU para o firmware Rev3, a fim de facilitar a análise contínua da UTA
  • Nesse ambiente, conseguiu executar e depurar alguns softwares que interagem com entidades externas
    • httpd
    • WebSocket
    • serviços gRPC

Chip de segurança STSAFE-A110

  • Além do SoC principal, a UTA traz um chip de segurança dedicado, o STSAFE-A110
    • Esse chip declara classificação de segurança CC EAL5+
    • Diferentemente do SoC customizado, ele pode ser comprado legalmente sob NDA
  • No firmware da UTA, um programa em espaço de usuário chamado stsafe_cli lida com a interação com esse chip
  • Pela engenharia reversa, o STSAFE parece fornecer principalmente as seguintes funções
    • Identificador único de cada dispositivo, UUID
    • Gerenciamento do certificado de chave pública stsafe_leaf.pem, supostamente usado para autenticação de comunicação via satélite
    • Derivação de chaves de criptografia simétrica para transmissão de dados do usuário
  • Esse chip atua como uma root of trust adicional, independente do mecanismo de secure boot do SoC, alinhando-se a práticas modernas de projeto de segurança embarcada

Ethernet Data Recorder e chaves SSH

  • Durante a análise, foi encontrado um programa chamado Ethernet Data Recorder; considerando apenas o nome e a função, ele poderia ser suspeito de ser um backdoor para captura de dados de usuário
  • Uma verificação detalhada mostrou que esse programa registra determinados pacotes de rede por meio de um mecanismo semelhante a pcap_filter
    • Exemplos de regras de captura incluem a condição udp and dst port 10017 e determinados hosts de destino multicast
    • Com base em outras pistas no firmware, esses pacotes estão relacionados à telemetria de satélites
  • Todo o tráfego capturado é criptografado usando uma chave de hardware fundida no SoC
  • Com as informações disponíveis atualmente, é difícil afirmar que esse recurso coleta dados de privacidade do usuário
  • Quando, durante a inicialização do dispositivo, o sistema se identifica como um terminal de usuário, o script de inicialização grava automaticamente 41 chaves públicas SSH em /root/.ssh/authorized_keys
    • A porta 22 da UTA fica sempre aberta na rede local
    • É notável que um produto de usuário contenha tantas chaves de login desconhecidas

Contexto de segurança dos sistemas de internet via satélite

  • À medida que a tecnologia de satélites continua evoluindo e sendo aplicada a diversos setores, cada componente da Starlink e de outros sistemas de internet via satélite pode se tornar uma área importante para futuras operações de ataque e defesa
  • Em segurança espacial, desenvolvedores e hackers precisam lidar não apenas com o domínio digital, mas também com as restrições da física espacial
    • Uma única operação incorreta pode fazer com que se perca permanentemente o contato com o alvo

Referências

Leituras relacionadas

1 comentários

 
GN⁺ 2025-05-11
Comentários no Hacker News

  • Se, na inicialização, ele se identifica como terminal de usuário e então adiciona automaticamente 41 chaves públicas SSH em /root/.ssh/authorized_keys, fico mais curioso para saber quem não tem acesso root ao “meu” terminal de usuário

    • Provavelmente o próprio usuário
      Falando mais seriamente, não sei se isso é tão diferente de ter um sistema de gerenciamento remoto em um roteador fornecido pelo ISP. Mesmo que a SpaceX não consiga acessar diretamente o terminal do usuário, ainda pode capturar tráfego pelo satélite ou pela estação terrestre
    • Fico pensando quem seria a pessoa mais adequada para tentar relacionar algumas dessas chaves com indivíduos envolvidos recentemente em trabalhos governamentais sensíveis. Também houve alguns vazamentos interessantes
    • Talvez 41 não seja necessariamente motivo de preocupação. Pode ser que existam instâncias de servidor em 41 regiões, cada uma com sua própria chave, e como o Starlink é um serviço global isso seria natural
      Na verdade, seria mais preocupante se 41 instâncias compartilhassem a mesma chave
    • No meu authorized_keys, como usuário individual, já tenho 25 linhas. Tenho YubiKey diferente para cada notebook, além das chaves do iPad e do iPhone, e a chave do Secure Enclave do Mac
      O Starlink provavelmente tem bem mais do que 1 ou 2 administradores de sistema, então até algo como 100 chaves públicas me parece razoável
    • Essa escolha realmente não faz muito sentido para mim. No meu trabalho atual, as chaves SSH dos desenvolvedores só são distribuídas para dispositivos com firmware DEV ou QA; as imagens de produção são assinadas e o SSH fica totalmente desativado
      Para diagnosticar problemas de engenharia em dispositivos de produção, existe um software separado de acesso remoto e até dá para abrir um REPL, mas isso é bloqueado por controle de acesso e aprovações de DevOps

  • Discussão anterior de um envio semelhante: Teardown of the SpaceX Starlink User Terminal https://news.ycombinator.com/item?id=25277171 (2 de dezembro de 2020 — 158 pontos, 138 comentários)

  • Se você publicar as 41 chaves públicas, provavelmente daria para descobrir quais desenvolvedores as usam

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

  • Surpreende que todos os pacotes sejam processados no espaço do usuário
    Se você processar tráfego de 1 Gbps com pacotes UDP de 100 bytes, precisará lidar com 1 milhão de pacotes por segundo. Em uma CPU de 1 GHz, isso dá só 1000 ciclos por pacote
    É possível, mas não parece nada fácil, a menos que os engenheiros gostem de escrever assembly na mão e pensar em todo tipo de truque com tabelas de consulta

    • Normalmente o software processa os pacotes iniciais e, quando o endpoint é estabelecido, os fluxos seguintes passam para o hardware. Alguns padrões específicos também podem sempre ser tratados em software
      O software pode ser um kernel modificado ou algum tipo de bypass de kernel no estilo XDP. É uma suposição baseada na minha experiência periférica com DPDK ou algo parecido em roteadores/gateways de modem a cabo Intel Puma
    • Para encaminhamento, uma abordagem no estilo DPDK pode ser mais rápida por reduzir cópias de buffer
      O Starlink fica na faixa de 25 a 200 Mbps, e os pacotes médios também são 7 a 8 vezes maiores, então no máximo seriam cerca de 36.000 pacotes por segundo, algo bem administrável mesmo em 1 GHz
    • Não entendo por que isso teria que ser menos eficiente do que processar pacotes no kernel. Existem formas de mapear filas de hardware para o espaço do usuário, e o texto também diz que o sistema tem uma arquitetura semelhante ao DPDK
      Nesse ponto, não vejo por que seria importante se o código de polling está dentro do kernel ou não
    • 100 bytes? O Starlink usa um MTU de 1500 bytes normal
    • Processar no espaço do usuário pode ser muito mais rápido porque evita um memcpy extra

  • Seria bom corrigirem o erro de digitação no título. No momento está “Ternimal”

    • Um caso clássico de keming

  • Fico curioso sobre como alguém começa a fazer esse tipo de coisa. Engenharia reversa é difícil, e normalmente eu penso em mexer em equipamento como algo reservado a coisas realmente caras ou antigas, que já não estão mais em desenvolvimento. Embora existam exceções

    • Primeiro, compra-se a coisa. Segundo, desmonta-se. Terceiro, pensa-se em um método de invasão. Quarto, tenta-se de verdade. Quinto, quebra-se tudo e xinga-se
      Normalmente existe uma UART, mas aparentemente o terminal Starlink não tinha, então essa pessoa removeu o chip de memória eMMC. É basicamente como um cartão microSD soldado
    • Acho que antes é preciso aprender um pouco de engenharia de hardware. Se você não souber o que os componentes fazem e como lidar com eles, engenharia reversa fica difícil

  • Está escrito que “DARKNAVY built a basic QEMU-based emulation environment for the Rev3 firmware”, e fiquei curioso se existem materiais ou soluções já prontas para emular firmware que se conecta a dispositivos externos como GPS

  • Tenho interesse em saber como proteger um produto contra engenharia reversa de firmware. Será que existe algum material apresentando as técnicas usadas pela SpaceX?

    • O passo 1 seria algo como firmware criptografado, mas parece que a SpaceX não fez nada ou só reage depois. Havia até pinos de depuração até alguém divulgar um ataque usando esses pinos
    • No mínimo, seria preciso criptografar o rootfs com algum segredo difícil de extrair de um elemento seguro. Indo além, daria para usar algo como o TrustZone da ARM para esconder tarefas sensíveis como bootloader, descriptografia e assinatura de imagem
      Pelo fato de terem conseguido simplesmente fazer dump do sistema de arquivos, parece que a SpaceX não aplicou muita proteção além do bootloader mencionado no texto
    • Como alguém que já usou muitos bons produtos com firmware ruim, eu sinceramente preferiria que não fizessem isso, a menos que exista uma justificativa forte, realista e bem analisada
      Melhor usar esses recursos em algo que beneficie todo mundo e torne o produto melhor. Para usuários avançados, a possibilidade teórica de modificar o produto — até de maneiras que o fabricante nunca imaginou — pode ser uma grande vantagem
      Pelo menos, é assim que vejo como usuário técnico final. Estou realmente cansado, e um pouco deprimido, de ter que hackear dispositivos para conseguir usar direito uma lâmpada, um alimentador de gatos e agora até uma máquina de remo
    • Se estiver usando Linux, isso provavelmente pode acabar em violação da GPL

  • Se isso for baseado em uma base de código compartilhada com os foguetes, seria incrível, não?

    • Falando de forma ainda mais incrível, provavelmente seria uma base de código compartilhada com os satélites. Ou talvez com um simulador de satélite; de qualquer forma, é algo que precisa enviar telemetria remotamente
    • Não, é baseado em OpenWRT