Desmontando o terminal de usuário do Starlink

• O terminal de usuário do Starlink da SpaceX é o hardware central da conexão de internet via satélite em órbita terrestre baixa
• Ao desmontar o terminal do usuário, os principais componentes são o front-end de radiofrequência (RF) e um SoC de projeto próprio
• A análise do firmware mostra que a maior parte do software principal inclui processamento de rede em espaço de usuário com bypass do kernel e algumas funções de criptografia
• O chip de segurança STSAFE-A110 atua como uma raiz adicional de autenticação, além de fornecer criptografia de dados e identificação única
• O terminal inclui várias configurações de chaves públicas SSH e uma ferramenta suspeita de registro de pacotes, mas não há indícios de violação da privacidade do usuário

---

Visão geral

• Starlink é um serviço de internet via satélite em órbita terrestre baixa oferecido pela SpaceX
• O usuário se conecta a satélites próximos por meio do terminal, que por sua vez se conecta à internet via gateways terrestres
• Satélites de nova geração usam links a laser para se comunicar entre si, o que contribui para melhorar a cobertura global e a eficiência
• Mesmo sem um gateway local, como no caso da Ucrânia, por exemplo, o terminal Starlink pode acessar a internet usando gateways de países vizinhos
• Este artigo aborda brevemente a investigação aprofundada do terminal de usuário do Starlink feita pela DARKNAVY

Análise de hardware

• Um terminal de usuário do Starlink é composto por duas partes: o roteador e a antena (UTA)
• A DARKNAVY comprou em Singapura um terminal Standard Actuated (Rev3, GenV2) e desmontou a antena
• A desmontagem mostrou que os chips de front-end RF (em sua maioria produzidos pela STMicroelectronics) ocupavam boa parte da placa
• Na área central de controle há um SoC ST customizado exclusivo da SpaceX (quad-core Cortex-A53), mas as informações do datasheet não são públicas
• Na Black Hat USA 2022, o Dr. Lennert Wouters, da KU Leuven, apresentou um caso bem-sucedido de hack do terminal de primeira geração (GenV1), e depois disso a SpaceX desativou a interface de depuração UART por meio de uma atualização de firmware
• Ainda assim, há registros de novas quebras de segurança bem-sucedidas por métodos adicionais

Extração e análise de firmware

• A DARKNAVY fez o dump do firmware diretamente do chip eMMC
• Como a placa Rev3 não tinha pinos dedicados de depuração eMMC, foi usado o método de remover o eMMC e extrair os dados com um programador
• A maior parte do firmware não está criptografada, revelando a boot chain (exceto o BootROM), o kernel e parte do sistema de arquivos
• Depois do boot do kernel, o ambiente de runtime é extraído e usado em /sx/local/runtime
• Em bin estão os executáveis do software do Starlink, em dat ficam os arquivos de configuração, e em revision_info estão as informações de versão
• O programa principal de comunicação, user_terminal_frontend, foi desenvolvido em Go, enquanto quase todo o restante consiste em binários estáticos em C++ sem símbolos
• A arquitetura da pilha de rede é semelhante ao DPDK, com programas em espaço de usuário processando os pacotes sem passar pelo kernel
• O kernel Linux é usado principalmente para drivers de hardware e gerenciamento de processos
• Parte do software inclui funções originalmente projetadas para uso em satélites ou gateways
• Na inicialização, o dispositivo identifica seu tipo pelos periféricos de hardware e carrega apenas a lógica correspondente

Emulação

• Para análise contínua, foi criado um ambiente de emulação de firmware Rev3 baseado em QEMU
• Nesse ambiente, foi possível executar e depurar parte dos serviços expostos externamente, como httpd, WebSocket e gRPC
• Isso permitiu rastrear o funcionamento dos principais executáveis e serviços

Chip de segurança

• Além do SoC principal, há um chip de segurança STSAFE-A110, que alega certificação CC EAL5+
• Esse chip pode ser comprado sob NDA, e o programa stsafe_cli do firmware interage com ele
• A análise mostrou que as funções fornecidas pelo chip STSAFE incluem atribuição de UUID único ao dispositivo, gerenciamento do certificado de chave pública (stsafe_leaf.pem) e derivação de chave simétrica
• Esse chip funciona como uma raiz de confiança adicional separada do secure boot do SoC, alinhando-se às práticas modernas de projeto de segurança embarcada

Easter egg: Elon está te observando?

• Durante a análise, foi identificado o programa Ethernet Data Recorder, o que levantou dúvidas sobre a possibilidade de um backdoor
• Esse programa aparentemente tem função de registro de pacotes e captura determinados pacotes internamente por um mecanismo semelhante ao pcap_filter
• Pelas regras observadas, nota-se que os alvos da captura são principalmente pacotes UDP relacionados à telemetria de satélite
• O tráfego capturado é armazenado de forma criptografada com a chave de hardware do SoC
• Até o momento, não foi encontrada evidência de coleta de dados privados dos usuários
• Durante a inicialização, quando o dispositivo é reconhecido como terminal de usuário, 41 chaves públicas SSH são gravadas em /root/.ssh/authorized_keys, e a porta 22 fica sempre aberta na rede local
• Chama a atenção o fato de um produto comercial vir com várias chaves públicas desconhecidas cadastradas

Conclusão e perspectivas

• À medida que a tecnologia de satélites passa a ser aplicada em diversos setores da indústria, os componentes de sistemas de internet via satélite como o Starlink tendem a se tornar um dos principais campos de batalha entre ataque e defesa em segurança no futuro
• Pelas características da segurança espacial, um único erro pode levar à perda permanente de comunicação com o alvo, o que exige uma abordagem cuidadosa

[GN⁺]

Comentários do Hacker News

• Ao inicializar o dispositivo, foi descoberto que, se o sistema o reconhece como um terminal de usuário, o script de inicialização grava automaticamente 41 chaves públicas SSH no arquivo /root/.ssh/authorized_keys, e a porta 22 também fica sempre aberta na rede local; isso levanta a dúvida sobre qual é o sentido de ter 41 chaves e, no fim, quem seria a pessoa sem acesso root ao terminal de usuário “que é seu”
  • Provavelmente você; pensando mais seriamente, isso não é tão diferente de ter um sistema de gerenciamento remoto em um roteador fornecido pelo ISP; mesmo que a SpaceX não tenha acesso ao terminal do usuário, ela ainda pode monitorar o tráfego pelo satélite ou pela estação terrestre
  • Fiquei pensando quem seria a melhor pessoa para verificar se há chaves SSH rastreáveis ligadas a gente envolvida em trabalhos governamentais especiais; também houve alguns vazamentos recentes interessantes
  • As 41 chaves podem simplesmente corresponder à mesma instância de servidor em 41 regiões; como o Starlink é um serviço global, isso não parece algo tão preocupante; eu ficaria mais preocupado se 41 instâncias compartilhassem uma única chave
  • Na empresa em que trabalho hoje, só distribuímos chaves SSH de desenvolvedores em firmware de DEV ou QA; as imagens de produção são assinadas e o SSH fica totalmente desativado; para diagnóstico remoto em produção usamos software separado, também controlado por permissões de acesso e processos de aprovação de DevOps, então a escolha da SpaceX me parece estranha
  • Mesmo sendo um único usuário, tenho 25 linhas no authorized_keys, misturando várias YubiKeys do laptop, chaves do iPad e do iPhone, chaves do Secure Enclave do Mac etc.; imagino que o Starlink tenha pelo menos mais 1 ou 2 administradores de sistema, então 100 chaves públicas nem parece um número tão estranho
  • Na verdade, isso pode ser mais normal do que parece e até uma boa escolha de segurança; em vez de milhões de terminais usarem todos a mesma chave ou poucas chaves, é melhor usar várias chaves separadas por número de série ou época de fabricação; as chaves privadas seriam usadas só para gerenciar um pequeno subconjunto de terminais, e o gerenciamento das chaves também pode ser segmentado
  • Imagino que o acesso externo por chave a esse terminal só seja possível quando ele também tiver conectividade de internet pela rede local; também tenho curiosidade sobre como o SSH passaria pela rede de satélite e como o Starlink organiza sua estrutura de rede, incluindo NAT
• Compartilha um link para um post anterior sobre um tema parecido, de desmontagem de terminal de usuário do Starlink
• Acha que seria divertido publicar as 41 chaves públicas e descobrir qual desenvolvedor usa cada uma
• Compartilha um link para um arquivo de posts de blog relacionados ao Starlink
• Pede ao autor para corrigir o erro de digitação no título ("ternimal")
  • Comenta com humor que isso é um caso clássico de problema de keming (espaçamento desequilibrado entre letras)
• Surpreende o fato de todos os pacotes serem processados em userspace; com tráfego de 1 Gbps (assumindo UDP de 100 bytes), isso dá um milhão de pacotes por segundo; uma CPU de 1 GHz só teria 1000 ciclos por pacote; em teoria é possível, mas não é fácil, seria um nível em que o engenheiro teria de recorrer a assembly escrito à mão e todo tipo de truque
  • Segundo o artigo, a arquitetura da pilha de rede parece semelhante à do DPDK, e o ponto central é o processamento de pacotes com bypass do kernel; na prática, talvez só o primeiro pacote seja tratado em software e, depois que a sessão é estabelecida, o fluxo possa ser entregue ao hardware; alguns padrões talvez continuem sendo tratados em software; já vi algo parecido em antigos roteadores/modems a cabo da linha Intel Puma
  • No encaminhamento estilo DPDK, há menos cópia de buffer, então pode até ser mais rápido; o Starlink opera na faixa de 25 a 200 Mbps, e o tamanho médio dos pacotes é 7 a 8 vezes maior, então isso daria algo em torno de 36 mil pacotes por segundo; para uma CPU de 1 GHz, é uma carga administrável
  • Fico me perguntando por que processar pacotes em userspace seria menos eficiente do que no kernel; se as filas de hardware forem mapeadas para o userspace, a divisão entre kernel e userspace deixa de importar muito
  • No caso do Starlink, usa-se MTU normal de 1500 bytes, não pacotes UDP de 100 bytes
  • Processar pacotes em userspace reduz cópias de memória desnecessárias e pode ser muito mais rápido
• Expressa curiosidade sobre como começar a fazer engenharia reversa em equipamentos assim; engenharia reversa é difícil, e a maioria dos exemplos é antiga ou cara demais para servir de referência prática
  • Primeiro é preciso aprender engenharia de hardware; sem entender a função e as características dos componentes, a própria engenharia reversa já fica difícil
  • O primeiro passo é comprar o produto e desmontá-lo; o segundo é pensar em uma forma de invadi-lo depois da desmontagem; o terceiro é realmente tentar; o quarto é se frustrar porque ele quebrou; normalmente a entrada é por uma porta UART, mas como o Starlink aparentemente não tem, houve um caso em que removeram o chip de memória eMMC para análise
• Pergunta se existem materiais de referência ou soluções prontas para emulação de firmware em ambiente baseado em QEMU conectado a dispositivos externos, como GPS
  • Cita como exemplo o fork do QEMU do Android, que emula vários tipos de hardware e interfaces de GUI, como OpenGL, GPS, GSM e sensores
• Quer aprender formas de proteger firmware contra engenharia reversa e pergunta se há material introdutório sobre as técnicas usadas pela SpaceX
  • O passo 1 seria adotar medidas como criptografia do firmware; a SpaceX também não parece agir de forma muito proativa, mas sim corrigir os problemas à medida que são descobertos; antigamente até havia pinos de debug
  • Muitos dos inúmeros produtos que usei tinham firmware pouco maduro; fora motivos de segurança, peço que não bloqueiem isso sem necessidade e usem os recursos em algo que ajude todo mundo; para power users, poder modificar diretamente o dispositivo pode até ser uma vantagem; a menos que haja um risco realmente grave de comprometimento, preferia que não gastassem tempo à toa; é triste, e às vezes deprimente, que a realidade nos obrigue a hackear vários dispositivos para adaptá-los às nossas necessidades
  • No mínimo, o sistema de arquivos root deveria ser criptografado usando segredos de um chip de segurança real, difícil de roubar ou extrair; para elevar ainda mais o nível, seria possível usar ARM TrustZone para isolar bootloader, descriptografia, assinatura de imagem e outras tarefas sensíveis; o simples fato de o sistema de arquivos poder ser dumpado facilmente já indica que a SpaceX não usa proteções efetivas na prática; só o bootloader estaria protegido, enquanto o resto fica exposto
• Acha curioso se esse equipamento usa a mesma base de código de um foguete
  • Na verdade, a parte ainda mais legal seria compartilhar a base de código com os satélites, ou talvez com um simulador de satélite, já que precisa enviar vários tipos de telemetria
  • Na prática, ele é baseado em OpenWRT