"Hack" tem uma variedade de definições, desde a leitura de dados privados de um sistema não crítico, a interrupção ou confusão do modo aviônico, o controle do avião e o bloqueio dos pilotos. Isso complica a discussão sobre a probabilidade de os aviões serem "hackeados".
Em geral, o consenso recente parece ser que, sob algumas definições de "hack", isso certamente é possível, mesmo sem conhecimento interno. Há alguma relatórios de hacks bem-sucedidos por aí, embora como os detalhes sejam confidenciais, é difícil dizer o que os pesquisadores realizaram ou o método de ataque deles. Tanto pesquisadores quanto fabricantes de aviões parecem concordar que, mesmo com conhecimento interno ou acesso prolongado ao avião, seria extremamente difícil, mas não impossível, assumir o controle de um avião por mais de alguns segundos.
As orientações políticas atuais da FAA podem ser encontradas em PS-AIR-21.16-02. Ouvi dizer que a FAA acabará reconhecendo o DO-326 como um meio de conformidade.
Vou fornecer algumas informações sobre medidas de segurança e integridade que são padrão no setor e dificultam a aviônica de hackers. Em particular, os aviônicos de hackers são um tipo de hackers de dispositivos embarcados críticos para a segurança, e não de servidores ou computadores pessoais. Os dispositivos embarcados críticos para a segurança têm uma superfície de ataque muito menor e muitos outros métodos de mitigação, conforme descrito abaixo.
Modelo de ameaça e diferenças em relação aos computadores
As ameaças que você enfrenta nos aviões são muito diferentes dos servidores e laptops. Os computadores pessoais estão propensos a vírus porque usam muitas técnicas perigosamente flexíveis. Eles executam código arbitrário. Eles possuem um software que se reconfigura. Eles recebem texto e até comandos de fontes não verificadas. A maioria delas não é verdadeira para aviônicos, por isso é difícil especificar um modelo de ameaça.
Especialmente para os sistemas mais críticos, como monitores e pilotos automáticos, os tipos de dados são rigorosos, as mensagens são agendadas, o tempo de processamento é limitado e as sequências raramente são usadas. Para realizar a maioria das tarefas, você precisaria quebrar esses protocolos. Isso é semelhante a outros tipos de programação incorporada, nos quais o software é tão inflexível que a superfície de ataque é pequena.
Algumas coisas que definitivamente ajudam os atacantes aqui incluem acesso físico ao processo de atualização de software, poder trabalhar com o avião por vários dias, conhecimento interno, equipamento simples de RF ou capacidade de seqüestrar comunicações via satélite para o avião. Se o atacante tiver alguns deles, a ameaça é muito mais séria.
Disponibilidade
É possível mexer com a disponibilidade de sistemas de aeronaves? Sim, se você pode manipular os sinais certos. Você pode, por exemplo, fazer o computador de controle de vôo achar que um sensor está com defeito. Você pode disparar muitos sensores com sinais de rádio poderosos o suficiente. Além disso, a maioria dos computadores de vôo usa processadores prontos para uso com muitos comportamentos estranhos e, especialmente, se uma exploração permite executar código de montagem arbitrário, você pode explorar alguns deles para deixar o sistema aviônico offline.
No entanto, a disponibilidade não é uma preocupação tão grande quanto a integridade dos aviônicos. A maioria das pessoas não fica acordada à noite se preocupando com o fato de o piloto ter que voar à mão por causa de um hacker. A maioria das pessoas está realmente preocupada com o fato de um hacker assumir o controle total do avião.
Particionamento
Diferentes funções, especialmente as de diferentes níveis de segurança, são reguladas por uma a outra. Historicamente, as aeronaves tinham hardware dedicado para cada componente, como um computador para o piloto automático, outro computador para o sistema de alerta, outro computador para o processamento de dados. Atualmente, grande parte desse software é executado em computadores LRU compartilhados (isso é chamado de arquitetura IMA). Mas, apesar do compartilhamento de hardware, os processos de software são estritamente isolados um do outro e supõe-se que nenhuma falha do processador, condições de erro, estouros, etc. possam ser transferidos de um processo para outro, especialmente um processo de nível superior. Sim, os sinais passam entre partições, mas todos os sinais que passam de um nível de segurança mais baixo para um nível mais alto são justificados individualmente para garantir que não causem problemas de segurança.
Para que uma exploração tenha efeito catastrófico, ela teria que contorná-la, quer pelo 1) trabalhando diretamente com o hardware e processos de nível A 2), encontrando uma suposição ruim sobre o impacto de um sinal de nível inferior.
Consulte DO-297 e DO-178C para obter mais informações sobre esse particionamento.
ensaio
Muitos hacks em computadores pessoais ocorrem devido a testes inadequados que permitem exceções e falhas no sistema. O software de nível A é testado de maneira muito mais abrangente do que a maioria dos aplicativos ou software de PC. Cada linha é testada quanto à cobertura de MC-DC (não exaustiva, mas todas as decisões devem ser exercidas como Verdadeira e Falsa). A cobertura estrutural também é avaliada para garantir que interações não intencionais não ocorram. Se ocorrerem falhas, o RTOS é projetado para cuidar dessas falhas de forma previsível e confiável.
Atualizações de software
Ok, digamos que você não encontre uma maneira de executar código arbitrário, você pode atrapalhar o processo de atualização de software? Isso inicialmente parece viável, especialmente devido à nova tendência de atualização do firmware aviônico nas redes. Existem várias questões aqui.
- A maioria das aeronaves não está diretamente conectada à Internet para atualizações de aviônicos. Eles estão conectados a uma rede local que obtém o software mais recente da web. Portanto, você teria que ter acesso à rede local para atualizações e também obter acesso aos aviões usando essa rede. Essa camada extra fornece alguma atenuação.
- A maioria das atualizações de software usa uma verificação de integridade de alta fidelidade, para a qual você precisaria de uma colisão de hash incrivelmente difícil. Alguns processos de atualização não têm verificações de alta fidelidade, mas se for esse o caso, eles devem qualificar às autoridades que seu processo de atualização é estável e à prova de erros. Portanto, sua única opção seria forjar o CRC também para a atualização e / ou encontrar uma exploração em um processo de carregamento qualificado.
- As atualizações baseadas em rede também acompanham os números de versão e podem acompanhar as verificações de integridade do software. Portanto, você não pode forçar exatamente uma atualização da versão 13 para uma v. 13.1 hackeada sem que alguém perceba.
- Atualmente ataques à cadeia de suprimentos estão se tornando cada vez mais frequentes. Embora eu tenha certeza de que um ataque à cadeia de suprimentos possa ser viável, regulamentos como a qualificação da ferramenta DO-330 e o controle de configuração do DO-178 protegem contra alterações inadvertidas durante a criação de software há anos. As versões testadas e revisadas do código estão sob controle cuidadoso e comparadas com as versões finais, os ambientes de criação de software são bloqueados e qualificados e as listas de bibliotecas incluídas são documentadas e aprovadas. Você precisaria encontrar um ponto cego nesses processos para atacar a cadeia de suprimentos de software.
- As atualizações de software (não as atualizações de banco de dados de navegação) são realizadas com pouca frequência, talvez a cada três anos, mitigando bastante a oportunidade de hackear uma carga de software. Existem bloqueios para impedir a recarga do software quando não desejado. Essa infrequência também leva a um maior escrutínio de todo o processo.
Para obter mais análises das medidas de segurança para impedir o upload de software ou bancos de dados corrompidos, sugiro que você consulte os padrões para esse processo: DO-200A, capítulo 5 do pedido FAA 8110.49 e FAA AC 20-153.
Desconexão manual e automática
Normalmente, o piloto automático e outro software são gerenciados por outro sistema que possui intertravamentos e desengata a lógica. Eles possuem padrões de segurança e testes escritos para garantir que eles funcionem de maneira confiável, tornando difícil encontrar uma exploração aqui sem, por exemplo, já ser capaz de executar código arbitrário.
Mesmo que esse software de desativação não funcione, os pilotos têm disjuntores e podem desativar todo o sistema aviônico, depois pilotar o avião manualmente. Veja a resposta da BigHomie para uma discussão sobre como é possível invadir isso.
Em teoria, isso deve funcionar, mas em certas situações o avião pode ser colocado em uma situação insegura antes que o piloto possa recuperar o controle. Seria difícil recuperar um arremesso repentino na abordagem, mesmo se você puder desativar manualmente o piloto automático.
Nota: Não sou especialista em aviônicos ou segurança de dispositivos incorporados. Hackear tende a pensar fora da caixa, então, deixe-me saber se alguma coisa que assumo aqui é imprecisa ou se sinto falta de alguma coisa.