Adicionar marcador
#1
Anotação. Os satélites são um aspecto importante da nossa sociedade moderna e deram uma contribuição significativa para a maneira como vivemos hoje, principalmente por meio de telecomunicações modernas, posicionamento global e observação da Terra. Nos últimos anos, e especialmente com o advento da Nova Era Espacial, o número de implantações de satélites aumentou dramaticamente. Apesar de sua importância crítica, pouca pesquisa acadêmica foi feita sobre segurança de satélite e, em particular, segurança de software embarcado. Essa deficiência provavelmente se deve às suposições até então desatualizadas sobre como obter segurança por meio da obscuridade, o que na verdade impede pesquisas significativas sobre software de satélite.

Neste artigo, pela primeira vez, apresentamos uma classificação de ameaças ao firmware do satélite. Em seguida, realizamos uma análise de segurança experimental de três imagens reais de firmware de satélite. Baseamos nossa análise em um conjunto de modelos de invasores reais e encontramos várias vulnerabilidades críticas de segurança em todas as imagens de firmware analisadas. Os resultados de nossa avaliação piloto de segurança mostram que os satélites em órbita modernos sofrem de várias vulnerabilidades de segurança de software e muitas vezes carecem de mecanismos adequados de proteção de acesso. Eles também enfatizam a necessidade de superar suposições prevalecentes, mas desatualizadas. Para fundamentar nossas observações, também realizamos uma pesquisa com 19 projetistas de satélites profissionais,

1. Introdução

Satélites são dispositivos técnicos complexos que são colocados no espaço sideral para fins de pesquisa ou para fornecer serviços a aplicações terrestres usando a superfície terrestre. Enquanto o primeiro satélite, Sputnik, remonta a 1957, estamos no meio de um renascimento no voo espacial chamado de Nova Era Espacial [1]. Especialmente nos últimos anos, vimos um grande aumento no número de satélites na órbita da Terra. De acordo com o Escritório das Nações Unidas para Assuntos Espaciais Exteriores (UNOOSA), seu número quase dobrou de 4867 em 2019 para 9350 em 2022 [2]. A grande maioria desses satélites forma megaconstelações como a Starlink, que planeja lançar mais de 40.000 satélites nos próximos anos [3].

Pequenos satélites [4] estão no centro da nova era espacial, pois seu tamanho e uso generalizado de componentes comerciais prontos para uso (COTS) os tornam acessíveis até mesmo para pequenas organizações. Além disso, eles cobrem uma ampla gama de casos de uso, desde aplicações comerciais (como observação da Terra, comunicações entre máquinas e serviços de Internet) até aplicações de pesquisa, como testes de tecnologia, previsão do tempo e terremotos e até mesmo missões interplanetárias. . [5]–[8].

Embora sua aplicação varie muito, pequenos satélites geralmente consistem em equipamentos de rádio e placas de microcontroladores. Portanto - no sentido mais amplo - são sistemas de computador conectados a uma estação terrestre na Terra e, às vezes, a outros satélites. Como dependem de conexões sem fio para comando e controle e usam microcontroladores, são potencialmente tão vulneráveis ​​a ataques quanto qualquer outra plataforma de TI conectada na Terra.

No passado, essa questão não era muito relevante, pois o acesso às estações terrestres era caro e limitado às grandes operadoras de satélite. No entanto, nos últimos anos, a situação mudou radicalmente. Atualmente, as estações terrestres estão disponíveis até mesmo para indivíduos, e com o advento dos modelos Ground Station as a Service (GSaaS), como os oferecidos pela Amazon Web Services [9] e Microsoft Azure [10], a barreira de entrada é ainda menor. Vimos no campo da segurança de redes móveis como a suposição dos provedores de que o equipamento de rádio necessário para ataques seria muito caro e inacessível aos invasores acabou sendo refutada pelos avanços tecnológicos [11]. Da mesma forma, estações terrestres acessíveis criam uma nova superfície para ataque, onde os invasores podem se comunicar com satélites e explorar vulnerabilidades de software. Se eles conseguirem comprometer o firmware do satélite, eles podem obter acesso ao satélite e potencialmente assumir o controle total do sistema.

Apesar dos alertas precoces [12], pouco tem sido feito para resolver esse problema por vários motivos, conforme apontado por Falco [13]. Embora a falta de padrões de segurança para satélites e uma complexa cadeia de suprimentos compliquem as coisas, o principal motivo é a indisponibilidade de software de satélite. Historicamente, os desenvolvedores de satélites contam com a segurança por meio da obscuridade. Os desenvolvedores da rede Iridium até mencionaram que seu sistema seria muito complexo para os invasores [13]. No entanto, Driessen et al. mostrou que os invasores podem descriptografar com sucesso a transmissão de dados em uma rede [14]. Em particular, a indisponibilidade de satélites em órbita torna o firmware lfvg muito difícil (se não impossível) para os pesquisadores, dificultando o progresso nessa área. Por isso, os desenvolvedores de firmware de satélite atuam como guardiões e não fornecem objetos de pesquisa aos pesquisadores. Vale ressaltar que Pavur e Martinovic [15] assim como Falko [13] admitem que o tema ainda não é bem compreendido e concluem que há necessidade de cooperação entre o desenvolvimento de satélites e o setor de segurança. Além disso, tópicos bem conhecidos, como a segurança das comunicações por satélite, a segurança dos serviços de Internet via satélite e os cenários de ameaças para satélites têm atraído recentemente uma atenção crescente [16], [17]. No entanto, as discussões sobre satélites individuais geralmente carecem dos detalhes técnicos dos satélites e dos fundamentos reais devido à indisponibilidade de software de satélite. que o tema ainda não é bem compreendido e concluem que há necessidade de cooperação entre o desenvolvimento de satélites e o setor de segurança. Além disso, tópicos bem conhecidos, como a segurança das comunicações por satélite, a segurança dos serviços de Internet via satélite e os cenários de ameaças para satélites têm atraído recentemente uma atenção crescente [16], [17]. No entanto, as discussões sobre satélites individuais geralmente carecem dos detalhes técnicos dos satélites e dos fundamentos reais devido à indisponibilidade de software de satélite. que o tema ainda não é bem compreendido e concluem que há necessidade de cooperação entre o desenvolvimento de satélites e o setor de segurança. Além disso, tópicos bem conhecidos, como a segurança das comunicações por satélite, a segurança dos serviços de Internet via satélite e os cenários de ameaças para satélites têm atraído recentemente uma atenção crescente [16], [17]. No entanto, as discussões sobre satélites individuais geralmente carecem dos detalhes técnicos dos satélites e dos fundamentos reais devido à indisponibilidade de software de satélite. [17]. No entanto, as discussões sobre satélites individuais geralmente carecem dos detalhes técnicos dos satélites e dos fundamentos reais devido à indisponibilidade de software de satélite. [17]. No entanto, as discussões sobre satélites individuais geralmente carecem dos detalhes técnicos dos satélites e dos fundamentos reais devido à indisponibilidade de software de satélite.

Neste artigo, fazemos três contribuições para a melhoria sistemática da segurança dos satélites. Primeiro, apresentamos uma visão geral das ameaças ao software de bordo do satélite. Essa revisão sistemática das superfícies de ataque nos permite entender melhor a natureza complexa dos satélites e categorizar as descobertas relacionadas à segurança em todo o documento.

Em segundo lugar, estamos conduzindo uma análise de segurança experimental e abrangente de três satélites reais em órbita para entender melhor a superfície de ataque e o estado atual da segurança de software nessa área específica. Estamos nos concentrando em satélites em órbita baixa da Terra (LEO), pois essa órbita é o foco principal da Nova Era Espacial. A classe mais comum de satélites são os nanossatélites, mais especificamente o CubeSat, que é um fator de forma padrão de cubos de 10 cm (chamados de Unidades ou U). Esses satélites normalmente pesam menos de 1,33 kg e são usados ​​em muitos projetos diferentes. Depois de muita persuasão, confiança, discussões e contratos, conseguimos acesso a várias imagens de firmware de satélite que pudemos analisar. Como resultado de nossa avaliação de segurança, encontramos seis tipos diferentes de vulnerabilidades de segurança em espaçonaves modernas lançadas recentemente, incluindo interfaces de telecomando não seguras. Todas as vulnerabilidades foram divulgadas de forma responsável aos fornecedores. Observe que a barreira de entrada para identificar essas vulnerabilidades era difícil devido à natureza sensível desses sistemas. Até onde sabemos, nosso trabalho é a primeira demonstração de exploração de vulnerabilidades de firmware de satélite, permitindo que invasores obtenham controle permanente sobre o satélite. que a barreira de entrada para identificar essas vulnerabilidades era difícil devido à natureza sensível desses sistemas. Até onde sabemos, nosso trabalho é a primeira demonstração de exploração de vulnerabilidades de firmware de satélite, permitindo que invasores obtenham controle permanente sobre o satélite. que a barreira de entrada para identificar essas vulnerabilidades era difícil devido à natureza

desses sistemas. Até onde sabemos, nosso trabalho é a primeira demonstração de exploração de vulnerabilidades de firmware de satélite, permitindo que invasores obtenham controle permanente sobre o satélite.

Em terceiro lugar, realizamos uma pesquisa com 19 engenheiros e desenvolvedores profissionais de satélites para ampliar o escopo de nosso estudo. No total, as respostas continham informações técnicas sobre 17 satélites e, no total, os participantes trabalharam com 132 satélites. Nossa pesquisa mostra que a obscuridade do protocolo é tão comum quanto a criptografia para proteção de acesso e que pequenas equipes de desenvolvedores tendem a desenvolver protocolos totalmente personalizados em vez de usar os existentes. Como observou um dos participantes da nossa pesquisa: “Focamos em fornecer um sistema funcional, não um sistema seguro”.

Em resumo, fazemos as seguintes contribuições principais:

- Uma taxonomia de ameaças e modelos de invasores associados contra firmware de satélite, que fornece uma visão geral sistemática e nos permite criar modelos de ameaças para satélites específicos.

- Análise de segurança sistemática de três imagens reais de firmware de satélite, que identificou 13 vulnerabilidades e se baseia em um modelo de ataque, levando em consideração os últimos desenvolvimentos técnicos (por exemplo, GSaaS).

- Pesquisa da comunidade de satélites para desafiar nossas descobertas técnicas e esclarecer as opiniões dos profissionais da comunidade espacial sobre segurança.

2. Contexto do satélite

Um satélite artificial (comumente abreviado como satélite) é um objeto colocado deliberadamente no espaço sideral que orbita outro corpo, como a Terra. Os satélites são projetados para operar no ambiente hostil do espaço, incluindo oscilações extremas de temperatura de cerca de 200°C ocorrendo mais de dez vezes ao dia, quase vácuo e radiação cósmica. No entanto, as implantações espaciais são frequentemente necessárias para fornecer serviços espaciais à Terra com aplicações gerais de satélite, incluindo comunicações, observação e exploração da Terra. Embora a maioria dos satélites seja implantada em LEO (250-2000 km), outras órbitas, como a órbita geoestacionária (GSO) (35.786 km), podem ser necessárias, dependendo da finalidade do satélite.

2.1. operações de satélite

As operações de satélite, como mostrado na Fig. 1 são desenvolvidos em torno de três componentes principais: um segmento de grupo que opera um serviço de satélite, um segmento espacial que consiste em todos os ativos espaciais e um segmento de usuário que recebe um serviço de satélite como o Sistema de Posicionamento Global (GPS) ou comunicações.

2.1.1. segmento terrestre. O segmento terrestre é o centro de todas as operações de satélite durante a vida útil do satélite. Um grupo de operadores se comunica com o satélite por meio de uma estação terrestre (GS) para enviar novas instruções ao satélite, denominada Telecommand (TC). Por sua vez, o satélite envia a telemetria (TM) de volta ao GS, fornecendo informações sobre o status do satélite, erros e outras métricas. O TC usa o protocolo espacial que descrevemos na seção 2.3. A seguir, nos referimos à combinação de dados TC e TM como tráfego TC/TM.

2.1.2. segmento espacial. O segmento espacial inclui todos os veículos espaciais envolvidos em operações com satélites, que podem ser satélites individuais ou uma constelação inteira. Esses satélites são inicialmente lançados em órbita por um veículo lançador e, em seguida, passam por uma fase de implantação orbital para estabelecer comunicações com o segmento terrestre. Durante a fase de operações nominais, que descreve as operações regulares do serviço, os satélites podem se comunicar entre si por meio de um link inter-satélite (ISL).

2.1.3. segmento de usuário.Um terminal, como um terminal de abertura muito pequena (VSAT) ou um receptor GPS no segmento do usuário, recebe o serviço fornecido pelo segmento espacial. Observe que alguns satélites, como satélites de observação da Terra, só se comunicam com seu segmento terrestre e não incluem o segmento do usuário.

2.2. arquitetura de satélite

Na fig. 2 mostra os componentes comumente encontrados em um satélite moderno, que são divididos em carga útil de satélite e barramento de satélite. A carga útil de um satélite consiste em equipamentos especializados, como uma câmera de alta resolução para observação da Terra ou equipamentos de rádio de alta potência para telecomunicações. O barramento de satélite inclui todos os componentes necessários para a operação e manutenção do satélite. Ele é projetado para funcionar independentemente da carga útil, mas, inversamente, a carga útil depende do barramento. Referimo-nos a isso como separação de barramento e carga útil. Portanto, em nossa análise de segurança, vamos nos concentrar no barramento de satélite, porque, ao contrário de muitos payloads, ele dá aos invasores controle total sobre o satélite.

2.2.1. Sistema de Controle e Processamento de Dados (CDHS).O ônibus é centrado em torno do CDHS, que controla o satélite e controla todas as funções da espaçonave. O CDHS usa um controlador on-board (OBC) que usa uma plataforma de computação, ou seja, microcontrolador e memória, semelhante aos dispositivos embarcados terrestres. O software executado neste sistema é chamado de software on-board (OBSW), que é o foco principal do nosso trabalho. Ele implementa um servidor de controle remoto, geralmente baseado em um sistema operacional de tempo real (RTOS), semelhante a aplicações terrestres de tempo real. A principal tarefa do OBSW é processar o tráfego TC/TM, fornecer armazenamento de dados, agendamento de comandos, executar ações autônomas e atualizar o código do programa. É importante observar que o OBSW, como qualquer software,

2.2.2. Módulo de comunicação (COM). A comunicação com o GS é fornecida por um módulo de comunicação (COM) que consiste em uma antena, um rádio e, às vezes, um computador para lidar com a decodificação, implementar protocolos e acessar a projeção. Além disso, COM é geralmente apenas para tráfego TC/TM, enquanto o tráfego de alta largura de banda, como downlink de dados de carga útil, geralmente é tratado por um rádio mais potente. Como o COM está diretamente conectado ao CDHS para processar o tráfego TC/TM, ele também é um importante ponto de entrada para invasores, criando uma superfície de ataque significativa. Além disso, a implementação do protocolo em COM pode ser relevante para a segurança, pois pode ser a primeira linha de defesa.

2.2.3. Sistema de Determinação e Controle de Atitude (ADCS). Os satélites usam o ADCS para determinar e ajustar sua posição para que possam apontar suas antenas para a Terra e os painéis solares para o Sol. Além disso, o ADCS executa um spin-up autônomo para interromper a rotação angular do satélite após ele sair do veículo de lançamento, o que é necessário para estabelecer a comunicação inicial. Além disso, o satélite também pode usar o motor para criar um sistema de controle de atitude e órbita (AOCS) para pequenas mudanças de órbita, o que é especialmente importante por razões de segurança. O AOCS transforma satélites em sistemas ciberfísicos porque eles podem afetar seu ambiente físico colidindo com outro objeto, o que pode levar a uma reação em cadeia orbital destrutiva (consulte a Seção 3.1.1).

2.2.4. Fonte de alimentação (EPS).Um sistema de energia elétrica (EPS) é a fonte de energia de um satélite, normalmente gerada por painéis solares e armazenada em baterias para fornecer energia na ausência de luz, como ao orbitar a Terra. Além disso, é muito importante que a bateria nunca seja totalmente descarregada, pois o satélite não pode ser reiniciado neste caso. Portanto, o gerenciamento de energia é fundamental para a capacidade de sobrevivência, pois a descarga profunda da bateria é de interesse dos invasores para desligar permanentemente um satélite.

2.2.5. Carga útil.Embora uma carga útil implemente principalmente hardware específico da missão, ela geralmente também implanta um Sistema de processamento de dados de carga útil (PDHS), que opera de maneira semelhante ao CDHS. O PDHS pode receber tráfego de controle de um módulo de comunicação de carga útil (PLCOM), que pode ser qualquer receptor de carga útil, ou executar tarefas gerais de processamento do hardware de carga útil. Devido ao alto grau de personalização da carga útil, os termos exatos para PDHS e PLCOM podem diferir em outras descrições de satélite.

2.3. Protocolos de comunicação por satélite

O tráfego de satélite TC/TM é transportado por um protocolo de comunicação por satélite, que chamamos de protocolo espacial na Figura 1. A principal organização de publicação desses protocolos espaciais é o Comitê Consultivo de Sistemas de Dados Espaciais (CCSDS), um consórcio de várias agências espaciais que negociam padrões. Em última análise, o CCSDS fornece muitos padrões de protocolo para comunicação com todos os componentes e partes envolvidas na operação de uma espaçonave [18]. Esses padrões cobrem todas as camadas do modelo OSI, e geralmente existem diversas variantes para cada camada [19]. Os protocolos mencionados neste artigo são o Space Data Link Security (SDLS) para a camada de enlace, que também implementa uma extensão de segurança [20], e o Space Packet Protocol (SPP) para a camada de rede. Observação, que a coleção CCSDS é mais como uma coleção de todos os protocolos de rede comumente usados ​​na Internet do que um protocolo específico. A seguir, nos referiremos ao conjunto de protocolos CCSDS como o protocolo CCSDS.

3. Ameaças de firmware de satélite

Agora oferecemos uma taxonomia de ameaças de firmware de satélite na exibição de 3 níveis mostrada na Figura 3. A figura resume nossas visões sobre ameaças de firmware de satélite para fornecer uma visão geral compacta e funcional. Trabalhos anteriores de Falco e Boschetti [21] apresentaram uma ampla classificação de ameaças comuns a satélites, incluindo riscos cibertécnicos ambientais, físicos e digitais. Os últimos servem como alvos de ataque de alto nível, então nosso trabalho se integra bem com sua taxonomia. Observe que o trabalho deles é uma classificação mais abstrata e de alto nível, enquanto o nosso se concentra em ameaças técnicas detalhadas ao firmware do satélite.

3.1. Taxonomia de Ameaças

Nossa taxonomia apresentada na fig. 3 inclui três camadas, que descrevemos usando uma abordagem de cima para baixo. No nível mais alto, o nível de controle, encontramos os objetivos finais do atacante. Para alcançá-los, um invasor deve ter como alvo algum componente, que é um componente auxiliar funcional (consulte a Seção 2.2) no nível do componente. Para se comunicar com um bean, um invasor deve primeiro obter acesso a uma das interfaces que residem na camada de interface e gerenciar a interação entre os beans e entidades externas, como GS.

Com linhas sólidas descrevemos a hierarquia dos elementos (ou seja, o barramento faz parte do satélite e o SRS faz parte do barramento, veja a Fig. 3), e com um conjunto de setas pontilhadas descrevemos os caminhos de ataque (ou seja, o atacante deve obter acesso ao COM antes de emitir um telecomando no CDHS). Usamos cores correspondentes às diferentes camadas da Figura 3.

3.1.1. Camada de controle.Modelamos alvos de atacantes de alto nível contra um satélite com base nos riscos cibertécnicos digitais mais recentes identificados por Falco e Boschetti [21]. Em seguida, definimos os alvos intermediários que o invasor precisa alcançar para atingir seu alvo final e distinguimos entre dois componentes de destino: o barramento e a carga útil. Lembre-se de que o barramento gerencia a carga útil, o que permite atingir a meta de carga útil do barramento, mas não vice-versa. Essa separação de barramento e carga útil é comumente encontrada em satélites, devido a questões de segurança, para evitar a propagação de falhas de hardware da carga útil. A seguir, examinaremos mais de perto os objetivos do invasor e como eles se relacionam com a separação entre barramento e carga útil.

Negação de serviço/controle. A negação de serviço (DoS) é o vetor de ataque mais comum contra satélites atualmente [22] e ameaça a disponibilidade de satélites. Isso pode ser alcançado tanto no barramento quanto na carga útil que implanta equipamentos para servir o satélite. Pelo contrário, a falha de controle só pode ser alcançada através do barramento.

Interação maliciosa com dados. Os invasores podem querer extrair ou modificar dados de satélite direcionados ao barramento ou carga útil. A interação com dados de controle diz respeito a dados críticos e segredos de proteção de acesso ao barramento, o que requer que o barramento seja comprometido. Por outro lado, os dados de carga útil podem ser acessados ​​de dentro da carga útil, como dados de câmera ou outros experimentos de carga útil.

Assumir o controle. Por fim, os invasores podem querer assumir o controle total do satélite. Normalmente, os TCs oferecidos pelo barramento não são suficientes para realizar ações arbitrárias, mas fornecem um conjunto de interações pré-definidas, tornando-se necessário encontrar uma vulnerabilidade que permita a execução de códigos arbitrários no barramento.

A tomada do controle não é apenas problemática para os proprietários de satélites, mas também pode ter consequências devastadoras para todo o ecossistema espacial. Se o satélite ativar os propulsores, os invasores podem tentar causar a síndrome de Kessler, um efeito no qual detritos de um satélite colidem com outros satélites, destruindo-os e emitindo mais detritos, resultando em uma reação em cadeia. Esses detritos poderiam potencialmente tornar o espaço inacessível por décadas, como mostrado em simulações [23], [24]. Essas possíveis consequências de um único hack de satélite bem-sucedido são amplamente ignoradas pela comunidade de segurança, embora possam impactar bastante as viagens espaciais como as conhecemos.

3.1.2. Camada de componentes.A camada de componentes consiste nos componentes de satélite genéricos correspondentes (consulte a seção 2.2), o link de barramento para carga útil e o Untrusted Data Handling System (UDHS). Na prática, esses componentes podem ser componentes de hardware separados ou combinados em uma única imagem de firmware. Aqui nós os separamos por função.

A seguir, discutiremos cada componente, suas tarefas e ameaças a ele. Classificamos as ameaças em três pilares de segurança bem conhecidos: honestidade (1), disponibilidade (3) e confidencialidade (4). Além disso, consideramos a Estabilidade (2) como uma subcategoria de Integridade para descrever ameaças que existem nativamente no satélite, mas comprometem a integridade operacional do satélite se estiverem disponíveis para invasores.

COM/PLCOM.COM recebe TCs de entrada através de um canal remoto (por exemplo, rádio), enquanto PLCOM recebe dados de carga útil ou TCs destinados à carga útil. Como estamos considerando apenas ataques ao firmware do satélite, resumiremos as ameaças contra (PL)COM como burlar o controle de acesso. Isso inclui ameaças gerais de RF, como ataques man-in-the-middle, e ameaças criptográficas, como canais laterais temporais, que foram exploradas em detalhes em artigos anteriores [25], [26]. Também inclui ameaças direcionadas ao microcódigo que demodula ou decodifica o TC.
CDS.O CDHS processa TCs de entrada executando uma função apropriada no firmware do satélite que executa ação direta ou programada no satélite (consulte a seção 2.2). Deve atender aos seguintes requisitos:

(1) Integridade. Os TCs vulneráveis ​​podem permitir que um invasor obtenha acesso a dados pessoais, intercepte o fluxo de controle ou vaze informações. Ele também inclui todas as vulnerabilidades de corrupção de memória de processamento de TC, como estouros de buffer, vulnerabilidades de string de formato ou vulnerabilidades de uso após a liberação [27].

(2) Estabilidade: Alguns TCs perigosos excessivamente permissivos podem permitir que um invasor capture o controle de acesso ao satélite, mecanismo de atualização de firmware, fluxo de controle ou dados críticos simplesmente liberando o TC correspondente. Esses TCs geralmente existem para fins de depuração. TCs que fornecem dispositivos arbitrários para gravar na memória (por exemplo, para depuração) ou alterações arbitrárias nos segredos de controle de acesso não devem ser implementados, enquanto o acesso à imagem do firmware deve exigir uma camada adicional de verificação (por exemplo, imagens assinadas), que é geralmente recomendado e é chamado de defesa em profundidade [28].

(3) Disponibilidade: o processamento do TC deve estar sempre disponível para ações urgentes, como correções de curso. Resumimos todas as ameaças à disponibilidade do CDHS como ameaças de supressão de TC, pois suprimem a capacidade do satélite de processar TC.

(4) Confidencialidade: os TCs podem permitir que um invasor revele segredos, como os relacionados ao controle de acesso e, assim, comprometer todo o satélite se esse vazamento permitir maior acesso. Resumimos os vazamentos de dados de controle como uma ameaça à privacidade do CDHS.

Comunicação entre barramento e carga útil.O canal Bus-Payload fornece uma ponte para a carga interagir com o barramento. Isso é necessário porque a carga útil pode precisar acessar os recursos de monitoramento e controle do barramento para controlar a carga útil. Esses recursos variam de acordo com a missão e a carga útil, mas podem incluir opções para alternar a energia dos componentes da carga útil. Portanto, o link fornece uma superfície semelhante à API entre diferentes níveis de confiança.

(1) Integridade: O link não implanta seus próprios TCs, mas usa os do CDHS por meio de interfaces de TCs. Essas interfaces do tipo API podem ser vulneráveis, assim como os TCs vulneráveis, que classificamos como interfaces TC vulneráveis.

(2) Estabilidade. As interfaces TC críticas podem comprometer o barramento ao oferecer deliberadamente funcionalidade de comando excessivamente permissiva para uma carga útil (potencialmente comprometida). Os TCs críticos incluem gerenciamento de energia irrestrito ou ajuste de posição de satélite para impossibilitar a comunicação por rádio. Os comandos emitidos pelo payload devem afetar apenas o hardware do payload e devem ser reversíveis em qualquer ponto do barramento. A diferença entre TCs críticos e perigosos é que os TCs críticos oferecem funcionalidades que devem ser exclusivas do barramento, enquanto os TCs perigosos não devem existir (mesmo no barramento) ou devem exigir autenticação/validação adicional.

(3) Disponibilidade: Se houver mais de um PDHS ou UDHS, nenhum deles deve negar a disponibilidade do outro canal. Assim, definimos a supressão de link como uma ameaça à comunicação entre componentes de carga conectados.

(4) Confidencialidade: um link é comprometido se os componentes de carga útil puderem recuperar informações exclusivas de outros componentes de carga útil. Nós os resumimos como vazamentos de dados de carga útil.

PDHS.O PDHS é um sistema de processamento de dados de carga útil e, dependendo das tarefas, atua como um sistema de gerenciamento de carga útil com pacotes de PLCOM. Assim, o sistema exerce controle direto sobre as funções de carga útil ou participa do processamento de dados não confiáveis ​​do segmento do usuário (consulte a seção 2.1). Em geral, como o PDHS pode implantar qualquer tarefa de computação, especialmente ao lidar com tráfego de carga de usuário não confiável, o cenário de ameaças muda para ameaças gerais de segurança do sistema, deixando as seguintes categorias deliberadamente vagas.

(1) Integridade: Generalizamos todas as ameaças clássicas de vulnerabilidade de software, como TC vulnerável, como processamento de dados vulnerável.

(2) Estabilidade. Isso só é relevante se o PDHS manusear o tráfego de comando da mesma forma que o CDHS manuseia a carga útil. Nesse caso, definimos uma categoria de ameaça de carga útil perigosa semelhante a TCs perigosos.

(3) Disponibilidade: a disponibilidade do PDHS é comprometida se a capacidade de processar pacotes de entrada for negada, resultando em uma negação de serviço de carga útil. Portanto, chamamos isso de negação de serviço de carga útil.

(4) Privacidade: Definimos o vazamento de informações gerais como uma ameaça à privacidade do PDHS.

UDHS. O UDHS executa código de usuário de carga útil não confiável diretamente no satélite. Como o código não é confiável, ele deve ser isolado das operações normais de carga útil no PDHS. Este componente não faz parte da arquitetura geral do satélite (ver seção 2.2), mas dada a tendência de alugar capacidades de satélite e considerações para a criação de serviços orbitais de computação em nuvem [29], [30] é hora de considerar este componente. Na prática, descobrimos que esse componente foi implantado em nossos estudos de caso na seção 5.2.

PDHS e UDHS têm uma relação especial em nossa taxonomia. Primeiro, o UDHS pode fazer parte do PDHS (ou seja, o PDHS é executado em um sistema operacional em que um único processo isolado executa código não confiável) em que o processamento de dados de carga útil também é executado no mesmo ambiente. Em segundo lugar, o PDHS pode fazer parte do UDHS, ou seja, o UDHS implanta um aplicativo (não confiável) que processa dados dos componentes de recebimento. Do ponto de vista de um invasor, um aplicativo de análise implantado pelo UDHS age como um PDHS. Chamamos isso de PDHS no wrapper UDHS UDHS-PDHS. Em termos de caminho de ataque, o UDHS-PDHS ainda está isolado, o que o distingue do PDHS convencional, mas também enfrenta as mesmas ameaças que o PDHS. Destacamos um exemplo desse mecanismo na seção 5.2.

(1) Integridade + (2) Estabilidade: A integridade do UDHS fica comprometida se o isolamento do ambiente for atacado, o que chamamos de ameaças Escape to PDHS.

(3) Acessibilidade: Não consideramos ameaças à acessibilidade do UDHS, pois apenas o UDHS-PDHS tem uma obrigação de acessibilidade.

(4) Privacidade: A extração de informações de um ambiente de host isolado ameaça a privacidade do UDHS, que resumimos como ataques de canal lateral.

3.1.3. camada de interface.As interfaces formam o terceiro e último nível de nossa taxonomia. Sempre que um componente interage com outro componente ou uma fonte externa, uma interface é utilizada entre eles. Distinguimos entre dois tipos de interfaces: interfaces externas que interagem entre um componente e um elemento externo. Cada interface tem apenas um pai, por exemplo, o pai de COM Rx é COM. No entanto, um componente pode ter várias interfaces, por exemplo, o CDHS pode ter dois coletores TC diferentes para COM e canal de carga útil do barramento. Na fig. Na Figura 3, omitimos as setas entre interfaces e componentes para simplificar, mas cada interface tem uma linha hierárquica que leva ao pai e uma seta de caminho de ataque pontilhada da interface ao componente.

receptor externo.As interfaces externas recebem dados de fora do satélite (por exemplo, rádios ou receptores ópticos). Omitimos a consideração de ameaças porque, em nosso modelo, essas interfaces implementam apenas operações de hardware puro sem software e só podem ser expostas a ameaças eletromagnéticas e de radiofrequência. Se o satélite usar firmware, ou seja, na forma de microcódigo, para realizar a demodulação do sinal, consideramos essa parte do COM, pois a operação pode potencialmente ignorar o controle de acesso. Portanto, consideramos apenas essa interface para modelar nossos invasores, conforme detalhado na Seção 4. Além disso, consideramos apenas receptores de dados estruturados que qualquer componente analisa. Por exemplo,

Coletor de dados. As interfaces internas gerenciam a interação entre dois componentes. Chamamos essas interfaces de coletores de dados porque elas recuperam dados internamente de um único componente e os fornecem a seus pais. Como eles só recebem tráfego de componentes e o encaminham para seus pais, eles enfrentam apenas (1) ameaças de integridade e (3) de disponibilidade. É impossível distinguir entre estabilidade e integridade, e um canal de apoio é necessário para violar a confidencialidade.

(1) Integridade + (2) Estabilidade: um invasor pode querer manipular os dados existentes introduzindo novos dados ou alterando os dados existentes. Assim, a injeção e modificação de dados representam uma ameaça à integridade dos coletores de dados. Por exemplo, a interface TC Fetcher é comprometida se um invasor conseguir injetar um TC adicional, mesmo que apenas um tenha sido enviado.

(3) Disponibilidade: um invasor pode comprometer a capacidade de uma interface de encaminhar todos os pacotes de dados recebidos para seu pai. Como a memória geralmente é limitada, essas interfaces geralmente usam um buffer de anel que substitui os pacotes antigos por novos. Por estouro de buffer e rotação contínua de pacotes ainda não processados, a interface fica comprometida (ameaça de estouro de dados). Além disso, a capacidade de encaminhamento do coletor de dados pode ser bloqueada de alguma forma (além de sobrecarga), o que chamamos de ameaça de supressão de encaminhamento.

3.2. Obtendo informações sobre satélites

Nossa taxonomia na Fig. 3 destaca não apenas as ameaças, mas também os caminhos de ataque e todos os componentes de computação encontrados no satélite. Portanto, nossa taxonomia é funcional e nos permite derivar modelos específicos de satélite que enumeram todas as árvores de ataque possíveis e a superfície de ataque completa. Em seguida, descreveremos primeiro como derivar o modelo de satélite, que também usamos para todos os três estudos de caso (consulte a Seção 5). Em seguida, explicamos como todas as árvores de ataque e superfícies de ataque podem ser extraídas desse modelo.

3.2.1. Obtenção de um modelo de satélite. Antes que um modelo específico de satélite (subseqüentemente abreviado como modelo) possa ser derivado de nossa taxonomia específica de satélite, nós
Enfatizamos que uma compreensão suficiente dos componentes internos do satélite (seja por meio de documentação ou engenharia reversa) é um pré-requisito essencial. O modelo pode então ser derivado em duas etapas: Primeiro, combinamos os componentes com os componentes reais do satélite. Em segundo lugar, mapeamos as interfaces entre esses componentes para modelar a interação real dos componentes do satélite.

Em particular, ao combinar componentes, cada componente na camada de componente pode ser duplicado ou removido para atender aos requisitos específicos do satélite. Por exemplo, se o satélite não tiver PDHS ou UDHS, ambos (mais o Bus-Payload Link) podem ser removidos, deixando apenas COM e CDHS. Se o satélite tiver vários componentes PLCOM, duplicamos o componente PLCOM enquanto mantemos a linha de hierarquia e a seta do caminho de ataque para cada COM individual. Vale ressaltar que você não pode criar novos componentes, apenas duplicar componentes de taxonomia existentes.

Em seguida, as interfaces são mapeadas para os componentes. Cada componente tem inicialmente sua própria interface (veja a Figura 3). No entanto, como cada interface pode ter apenas um pai, mas vários filhos, várias interfaces podem ser compartilhadas como interfaces de host para um único componente. Por exemplo, o CDHS pode usar o mesmo coletor de TC para várias COMs, ou seja, com COMs de espera ativa.

3.2.2. Extração da árvore de ataque e superfície.Após a obtenção desse modelo, as setas tracejadas do caminho de ataque formam um grafo direcionado. Na Seção 4, discutimos nossos atacantes de acordo com nossas interfaces, onde cada atacante está conectado a uma interface, criando essas interfaces conectadas ao atacante. A combinação de todas as interfaces conectadas a um invasor forma uma superfície de ataque. Seguindo todos os caminhos possíveis desde a interface conectada ao atacante até o elemento do plano de controle, podemos extrair todos os caminhos de ataque possíveis, onde cada caminho é um subgrafo da nossa árvore de ataque.

Em nossos estudos de caso, usamos essa exibição de árvore de ataque porque fornece uma visão mais intuitiva dos aspectos de segurança de um determinado satélite.

4. Modelo de Atacante

Usando nossa taxonomia de ameaças contra firmware de satélite, formulamos quatro modelos de ataque considerando tanto o conhecimento do atacante quanto o nível de acesso.

4.1. Conhecimento do adversário

Na primeira etapa, abordamos uma suposição predominante, mas desatualizada, que precisa ser revisada.

Segurança através do desconhecido.Durante décadas, a comunidade de satélites e os desenvolvedores atuaram como guardiões no assunto de segurança de satélites [15]. Ao manter o software e os componentes dos satélites trancados a sete chaves, eles criaram uma "barreira de obscuridade" que impedia qualquer pesquisa significativa sobre o assunto. Consequentemente, não houve oportunidade para as comunidades de fora estudarem os componentes internos do satélite e possíveis problemas de segurança.

Isso mudou nos últimos anos, à medida que o desenvolvimento espacial mudou para componentes COTS [15], [31], projetos de satélites abertos [7], [32] e bibliotecas de código aberto [33]. Esses fatores foram multiplicados pelo crescimento explosivo no número de satélites [4] e o aumento inerente no tamanho da comunidade. Consequentemente, o número de pessoas que têm conhecimento de satélites está crescendo constantemente. Em geral, argumentamos que a transformação da eficácia da proteção devido à discrição em ativos espaciais está ocorrendo lentamente.

Suposição revisada.Como resultado, devemos assumir que os invasores possuem informações detalhadas sobre o satélite alvo, incluindo documentação detalhada e acesso a imagens de firmware. Além disso, vários satélites de código aberto já permitem que invasores estudem satélites [34]–[36]. Portanto, assumimos que os invasores possuem informações detalhadas sobre os satélites, incluindo seu firmware, com exceção de segredos criptográficos.

4.2. Nível de acesso do invasor

Também corrigimos um equívoco comum sobre o nível de acesso do invasor ao segmento espacial.

O mito da inacessibilidade.Até recentemente, acreditava-se que os satélites sempre associados a GS exorbitantemente caros. Como resultado, apenas alguns atores poderiam atacar o satélite (semelhante à suposição para redes móveis muitos anos atrás). Esta suposição teve um grande impacto na adaptação das funções de segurança em satélites [15]. No entanto, os preços do GS caíram significativamente nos últimos anos. Hoje é possível construir um GS totalmente funcional por menos de $ 10.000 [37], e existem comunidades de código aberto dedicadas ao desenvolvimento de GS [38]. Além disso, provedores de GSaaS, como Amazon Web Services ou Microsoft Azure, alugam GS para o usuário [9], [10] ou permitem que proprietários de GS monetizem capacidade não utilizada de GS alugando-a temporariamente para usuários finais. Como resultado, você nem precisa ter seu próprio equipamento GS para interagir com os satélites. Além disso, os transceptores para determinados serviços de satélite tornaram-se tão pequenos e baratos que podem ser encontrados em eletrônicos de consumo, como o iPhone 14 [39]. Além disso, existem atualmente muitas constelações de satélites LEO no espaço com capacidade de comunicação entre satélites. Ao mesmo tempo, o número de pequenos satélites de pesquisa em órbita baixa está crescendo. Já existem no espaço vários satélites com capacidades de comunicação significativas, que se destinam mesmo a terceiros [32]. atualmente existem muitas constelações de satélites LEO no espaço com capacidade de comunicação entre satélites. Ao mesmo tempo, o número de pequenos satélites de pesquisa em órbita baixa está crescendo. Já existem no espaço vários satélites com capacidades de comunicação significativas, que se destinam mesmo a terceiros [32]. atualmente existem muitas constelações de satélites LEO no espaço com capacidade de comunicação entre satélites. Ao mesmo tempo, o número de pequenos satélites de pesquisa em órbita baixa está crescendo. Já existem no espaço vários satélites com capacidades de comunicação significativas, que se destinam mesmo a terceiros [32].

Suposição revisada. Assim, acreditamos que houve uma mudança de paradigma na suposição de que os satélites não estão disponíveis, o que é especialmente perceptível para os satélites LEO. Portanto, separamos os invasores em invasores externos, usuários de carga útil, hosts de serviço de carga útil e operadores com base em sua associação com o satélite.

4.3. Modelos de invasores

Em seguida, descrevemos os modelos de invasores com nossas suposições revisadas. Além disso, conectamos cada invasor a uma interface de nossa taxonomia apresentada na Seção 3.1.3.

4.3.1. Intrusos externos. Um atacante externo, como mostrado na Fig. 4a pode usar um GS personalizado ou um satélite personalizado para interagir com o satélite alvo. Assim, invasores externos podem enviar tráfego arbitrário para qualquer interface que receba tráfego externo, bem como receber qualquer resposta. Portanto, em nossa taxonomia, invasores externos podem interagir com cada interface do Rx externo. Podemos distinguir entre dois tipos de invasores externos.

Ataque do usuário em uma estação terrestre.A comunicação com o GS é o principal canal de controle do satélite. Mesmo que esse canal seja protegido por mecanismos de controle de acesso, um invasor pode ignorar o controle de acesso, que identificamos como uma grande ameaça aos componentes COM (consulte a Seção 3.1.2). Para tanto, propomos um GS de ataque customizado que pode se comunicar com o satélite alvo através de qualquer GS diferente daquele utilizado pelas operadoras de satélite, pois pode conter segredos de controle de acesso. Assumimos também que os invasores possuem o conhecimento necessário para estabelecer um link de rádio, ou seja, frequências, modulações e posição orbital, exceto pelos segredos mencionados.

ataque ISL.Além do acesso do usuário ao GS, assumimos que um invasor externo tem acesso aos satélites do usuário para se comunicar com as interfaces de recepção externas por meio de conexões ISL (consulte a Seção 2.1).

4.3.2. Cargas maliciosas.Os usuários de carga útil são sujeitos de um segmento de usuário (consulte a seção 2.1) e destinam-se a interagir com o satélite por meio da carga útil do satélite. Os invasores do serviço de carga útil exploram um serviço predefinido oferecido pelo satélite, geralmente usando uma pequena antena fornecida pelo provedor de serviços do satélite, conforme mostrado na Figura 4b. Além disso, o tráfego emitido pelo invasor deve ser processado a bordo do satélite, ou seja, analisando-o e recebido na interface do Payload Data (PD) Fetcher. Além disso, resumimos os invasores que comprometeram com sucesso a carga útil, por exemplo, via PDHS, como atacantes de carga útil. Eles interagem com o barramento usando a interface Link TC Fetcher, que lhes permite potencialmente propagar um ataque da carga útil para o barramento.

4.3.3. Host de serviço de carga maliciosa. Esses hosts têm a capacidade de hospedar um serviço personalizado na carga útil, ou seja, carregando código não confiável. O serviço não confiável deste usuário está sendo executado em UDHS. Portanto, um invasor tem acesso ao UDHS para baixar, atualizar ou modificar o serviço usando a interface Untrusted Data Collector (UD), conforme mostrado na Figura 4c.

4.3.4. Operadores.Os operadores controlam a operação do satélite e exercem controle total sobre o satélite emitindo comandos por meio da interface TC Fetcher. Embora não consideremos ataques de operadores totalmente privilegiados, argumentamos que os operadores são frequentemente divididos em operadores totalmente privilegiados e semiprivilegiados. Isso pode se aplicar a qualquer grupo suficientemente grande de operadores onde as responsabilidades e os direitos de acesso são segregados. Esse cenário é mais provável pelo modelo de satélite como serviço (SataaS), no qual o acesso via satélite é alugado para terceiros não confiáveis. Nesses cenários, as partes não confiáveis ​​podem interagir de maneira limitada, como habilitar ou desabilitar a carga útil, causando problemas de escalonamento de privilégios.

Insider semi-privilegiado.A posição semiprivilegiada, mostrada na Figura 4d, permite que os invasores se comuniquem usando TCs não críticos, como solicitar telemetria ou controlar sistemas de carga útil não essenciais. Portanto, esse invasor interage com o satélite enquanto está em um espaço limitado, por exemplo, usando restrições de download terrestre. Embora a mensagem do invasor seja recebida pelo mecanismo de controle de acesso do satélite, o invasor não tem acesso direto aos segredos criptográficos.

5. Estudos de Caso

Demonstramos a aplicabilidade no mundo real de nossa taxonomia e modelos de ataque por meio de uma análise detalhada de três satélites diferentes. Para cada um deles, primeiro realizamos uma análise técnica dos componentes do satélite, que usamos para construir um modelo de ameaça específico do satélite usando nossa taxonomia, conforme descrito na Seção 3. A Tabela 1 fornece uma visão geral dos satélites analisados, incluindo dados importantes . Em seguida, analisamos a segurança do firmware do satélite e a Tabela 2 resume os principais resultados. Descobrimos que todos os satélites são afetados e encontramos várias vulnerabilidades com sucesso. Em dois casos, testamos experimentalmente a possibilidade de explorar as vulnerabilidades identificadas e conseguimos a execução de código arbitrário no CDHS, dando ao invasor controle total sobre o satélite, que,

Concluímos que a barreira de entrada para pesquisa de segurança é alta porque existem vários desafios únicos.

Análise. À primeira vista, pode parecer interessante começar com o estudo de um grande satélite no GSO. No entanto, a complexidade desses grandes satélites os torna extremamente difíceis de estudar e dificulta a compreensão dos detalhes de segurança. Portanto, vamos nos concentrar primeiro no satélite ESTCube-1 desenvolvido pela universidade, para o qual assumimos que a complexidade do satélite é administrável.

Como segundo exemplo, procurávamos um satélite mais complexo e encontramos o exemplo perfeito no OPS-SAT. Não só a Agência Espacial Europeia (ESA) está envolvida num desenvolvimento que já contribui para o conhecimento de uma grande agência espacial, como o satélite é uma plataforma de pesquisa aberta, que conduz a um interessante modelo de ataque.

Por fim, focamos em um satélite ainda maior e mais complexo. O Flying Laptop é um ótimo exemplo aqui, pois sua configuração de computação baseada em FPGA funciona de maneira semelhante a satélites ainda mais sofisticados.

Âmbito de análise.Em nossa análise, vamos nos concentrar no OBSW no CDHS, pois os invasores podem usar esse módulo para assumir o controle total do satélite. No OBSW, focamos no link de dados TC/TM, pois é a principal superfície de ataque. Portanto, analisamos a análise dos pacotes recebidos e monitoramos o processamento dos TCs antes de executá-los e a execução real dos TCs. Também analisamos o impacto dos TCs visíveis e procuramos vulnerabilidades neles. Observe que todos os recursos e vulnerabilidades nos estudos de caso a seguir são explorados ativamente no satélite, a menos que indiquemos o contrário.

Método de análise.Usamos IDA Pro e Ghidra como ferramentas durante nossa análise. Nossa análise inicial foi manual e envolveu principalmente engenharia reversa de binários de firmware enquanto analisamos o fluxo de dados de sistemas COM para processamento de telecontrole. Assim, verificamos e examinamos manualmente o código em busca de problemas de segurança. Também procuramos referências a funções de corrupção de memória, como memcpy e strcat. Por fim, usamos fuzzing com reconhecimento de cobertura re-hospedando o firmware para ESTCube-1 usando Fuzzware de Scharnowski et al. [40].

Divulgação acordada.Comunicamos nossas descobertas aos desenvolvedores de satélite relevantes e ao GomSpace, o desenvolvedor do SDK espacial, de maneira responsável e coordenada, e oferecemos nossa assistência para resolver os problemas. A equipe do ESTCube-1 já confirmou que corrigirá os problemas no próximo ESTCube-2. As equipes OPS-SAT, Flying Laptop e GomSpace confirmaram que receberam nossos relatórios, mas não divulgaram nenhum detalhe nem responderam a nenhuma de nossas perguntas subsequentes.

Corrigindo vulnerabilidades de satélite.Estimar o tempo necessário para corrigir vulnerabilidades geralmente não é uma tarefa fácil, pois depende da complexidade do problema subjacente. Além disso, os satélites enfrentam o desafio único de baixar o firmware corrigido. A equipe do ESTCube-1 nos disse que o download da imagem do firmware geralmente leva de alguns dias a uma semana, dependendo do GS e da qualidade do link. Isso se deve à baixa largura de banda dos componentes UHF/VHF (ou seja, 9600 bps) e à largura de banda geral.

5.1. ESTCube-1

O ESTCube-1 foi o primeiro satélite da Estônia. Foi desenvolvido pela Universidade de Tartau em cooperação com o Centro Aeroespacial Alemão (DLR). O satélite 1U CubeSat em LEO foi desativado em 2015 enquanto permanecia em órbita. O principal objetivo do satélite era demonstrar um novo método de propulsão chamado vela solar elétrica [42]. A tarefa secundária do satélite era observar a Terra no espectro visível. O satélite de segunda geração será lançado em janeiro de 2023 e compartilha a maioria dos componentes de software com o ESTCube-1. Assim, apenas componentes específicos para a nova missão estão sendo desenvolvidos do zero, o que significa que os seguintes resultados provavelmente também afetarão o ESTCube-2.

5.1.1. Análise técnica. Na fig. A Figura 5 mostra uma visão geral do ESTCube-1, que implementa dois componentes personalizados de carga útil [7]. O design do satélite é bastante simples, pois todos os componentes são controlados diretamente pelo CDHS sem um PDHS dedicado. O CDHS usa um OBC ARM STM32F103VF redundante com OBSW baseado em FreeRTOS.

O tráfego TC/TM manipulado pelo CDHS é recebido por COM que contém múltiplas antenas. Uma antena de frequência ultra alta (UHF) é usada para tráfego TC/TM com GS e a outra antena escuta frequências muito altas (VHF) para o sinal de reinicialização de emergência. Além disso, há uma antena de banda S para transmitir dados de imagem da câmera. Notavelmente, o design COM não fornece proteção de acesso ou mecanismos de criptografia.

Protocolo de intercomunicação. Os componentes ESTCube-1 usam um protocolo especial de intercomunicação (ICP) para se comunicar com CDHS e GS. O protocolo não usa nenhuma medida de segurança, como criptografia ou autenticação, e foi projetado para ser simples. Ele usa um esquema de endereçamento simples no qual cada componente, incluindo o GS, possui um identificador (por exemplo, GS = 5 e CDHS = 2). Na análise de pacotes em CDHS, a carga ICP é usada como um pacote TC e enviada ao agendador de comandos, que por fim executa o comando. Em última análise, o protocolo é uma solução mínima para enviar pacotes ordenados em uma pequena rede mesh de componentes.

5.1.2. Modelo de Ameaça. Na fig. A Figura 6 mostra o modelo de ameaça derivado de nossa taxonomia (consulte a seção 3), incluindo as vulnerabilidades que identificamos. Como a carga útil do satélite não oferece PDHS ou receptores externos para dados estruturados, o modelo de ameaça inclui apenas um barramento. Uma antena de banda S não está incluída, pois é usada apenas para transmissão. A superfície de ataque do ESTCube-1 é definida por meio de interfaces. Portanto, apenas invasores externos com GS personalizado contra COM Rx e operadores semiprivilegiados conectados ao TC Fetcher importam (consulte a Seção 4.3).

Configuração experimental. Reconstruímos (partes do) satélite em nosso laboratório para testar nossos resultados experimentalmente. Nós recriamos o hardware CDHS do satélite usando o mesmo microcontrolador STM32 em uma placa de breakout com um depurador J-Link. Além disso, conectamos o satélite aos atuadores que representam as funções de controle de carga útil. Esta instalação executa o OBSW inalterado no mesmo hardware. Além disso, conectamos o alto-falante à porta normalmente ocupada pelo Solar Sail (consulte a seção 5.1.1). Criar um exploit que reproduz som prova que podemos controlar esta (ou qualquer outra) porta.

5.1.3. Análise de segurança.Resumimos nossas principais conclusões. Acesso desprotegido ao telecontrole. O problema mais notável com o ESTCube-1 é a falta de criptografia e autenticação TC, resultando em um desvio de controle de acesso trivial (consulte a Seção 3) no COM. Durante a operação ativa do satélite, invasores externos com GS personalizado podem emitir comandos arbitrários para o satélite.

Infelizmente, não parece ser uma correção trivial, pois o protocolo ICP usado deve ser estendido para fornecer comunicações criptograficamente seguras. Isso destaca o problema de usar protocolos personalizados para aplicativos críticos de segurança. Mesmo supondo que a proteção de acesso esteja em vigor, este seria o único ponto de falha devido ao perigoso TC discutido posteriormente.

Veículos inseguros por design. Mesmo sem proteção de acesso, o satélite deve ser projetado de forma que os TCs não perturbem a estabilidade do satélite sem verificação adicional, conforme especificado na seção 3. Aqui, dois TCs específicos permitem leituras e gravações de memória arbitrárias. Em um nível técnico, o invasor controla todos os parâmetros passados ​​para memcpy por meio de argumentos de comando, portanto, esses dois TCs são TCs perigosos. Qualquer pessoa com seu próprio GS pode usá-lo para executar código remotamente e assumir o controle do satélite.

Notavelmente, a capacidade de executar código arbitrário permitiria que um invasor gravasse permanentemente atualizações de firmware na memória flash, tornando a captura irreversível. Com exceção dos sistemas operacionais modernos, como Linux ou Windows, que implementam prote&