otsmr/blackbox-fuzzingFuzzing de Dispositivos IoT Usando o Roteador TL-WR902AC como Exemplo
Esta é a versão em HTML do meu trabalho acadêmico, que pode ser baixado como PDF aqui.
O fuzzing tornou-se "uma das maneiras mais eficazes" de encontrar bugs em software. Com esta ou alegações semelhantes, muitos artigos atuais relacionados a fuzzing começam [google-scholar]. O principal objetivo do nosso último trabalho acadêmico sobre o tópico "Internet of Vulnerable Things" era encontrar um bug relacionado a memória e então escrever um exploit para essa vulnerabilidade. Conseguimos encontrar uma vulnerabilidade ao fazer engenharia reversa do firmware, mas nenhum bug relacionado a memória foi encontrado. Encontrar um buffer overflow ao fazer engenharia reversa de um binário manualmente não é apenas demorado, mas também exige muita experiência. Ao mesmo tempo, o fuzzing visa ser a "maneira mais eficaz" de encontrar tais vulnerabilidades relacionadas a memória. O Google, por exemplo, introduziu o OSS-Fuzz, que faz fuzzing contínuo de software de código aberto e já encontrou mais de 10.000 vulnerabilidades em 1.000 projetos [oss-fuzz].
O objetivo deste trabalho acadêmico é novamente encontrar uma vulnerabilidade relacionada a memória, mas desta vez usando fuzzing. A vulnerabilidade alvo deve ser explorável pela rede sem conhecimento das credenciais de administrador. Este trabalho descreve a maneira de alcançar esse objetivo. Para isso, o trabalho está separado em duas partes. A primeira parte foca em como encontrar um alvo promissor, quais ferramentas podem ser usadas e do que um bom alvo de fuzzing deve consistir. A segunda parte descreve então como desenvolver e depurar um harness capaz de fazer fuzzing em uma função específica de um binário. Em seguida, o harness desenvolvido é usado pelo AFL++ para fazer fuzzing na função alvo. A seguir, uma breve contextualização é apresentada e qual é o estado da arte atual quando se trata de fuzzing de dispositivos IoT.
Todos os arquivos criados no contexto deste trabalho acadêmico também são publicados integralmente no GitHub e podem ser acessados usando a seguinte URL: otsmr/blackbox-fuzzing.
Fazer fuzzing em dispositivos IoT não é tão fácil quanto fazer fuzzing em um projeto de código aberto. Frequentemente, o código-fonte é proprietário, o que torna o fuzzing de caixa cinza, que instrumenta o código-fonte para o melhor desempenho de fuzzing, impossível [afl-persistent]. Além disso, a arquitetura de CPU muitas vezes não é suportada nativamente pelos fuzzers, o que exige um emulador como QEMU [qemu], que também diminui a velocidade do fuzzing [afl-persistent]. Outro problema são os periféricos de hardware, que dificultam o desenvolvimento de uma abordagem geral. O artigo "Embedded Fuzzing: A Review of Challenges, Tools, and Solutions" [embedded-fuzzing] fornece uma visão geral de diferentes estratégias de fuzzing, como o fuzzing embarcado baseado em hardware. A maioria dessas estratégias precisa do código-fonte do programa alvo, como quando se porta o código-fonte do fuzzer, como o AFL, para dispositivos IoT baseados em ARM, a fim de executar o fuzzer no hardware IoT. Executar o fuzzer no hardware do dispositivo também apresenta problemas de desempenho, pois eles geralmente têm CPUs de baixo nível, que são mais lentas do que CPUs normais de desktop. Outra abordagem apresentada neste artigo é o fuzzing embarcado baseado em emulação. Em que um único programa alvo é executado em um emulador para realizar fuzzing guiado por cobertura ou o sistema completo.
Um harness descreve uma sequência de chamadas de API que processam as entradas fornecidas pelo fuzzer. Ao contrário de uma aplicação normal, que muitas vezes não precisa de um harness, uma biblioteca que implementa funções reutilizáveis deve ser chamada com os parâmetros corretos e também na sequência certa, para que o estado entre múltiplas chamadas de funções compartilhadas possa ser chamado. Submeter a biblioteca a fuzzing aleatório sem construir a máquina de estados provavelmente não terá sucesso e, em contraste, criará muitos crashes falso-positivos quando as dependências da biblioteca não forem aplicadas. Isso pode acontecer quando, por exemplo, uma verificação de tamanho de buffer é ignorada pelo fuzzer, resultando em um buffer overflow espúrio.
Neste trabalho, aplicações normais serão submetidas a fuzzing, mas por causa das dependências de hardware do uso de sockets e multi-threading, precisamos criar um harness para elas também. O harness é carregado no contexto do binário e pode chamar funções internas do programa alvo, como mostrado no Código 10.
O termo "corpus" descreve amostras de entrada válidas ou casos de teste e serve como referência fundamental para gerar novos dados de entrada durante o processo de fuzzing. No Código 10, isso seria, por exemplo, uma requisição HTTP. Os fuzzers então utilizam esse corpus para criar casos de teste mutados ou diversificados, auxiliando na detecção de vulnerabilidades de software por meio da exploração de vários cenários de entrada.
A parte que mais consome tempo do fuzzing de caixa preta é encontrar uma potencial
função vulnerável no firmware. O primeiro passo é encontrar
binários interessantes que, por exemplo, são acessíveis pela rede,
usam funções inseguras ou não possuem recursos de segurança como stack
canary habilitado, que é uma proteção contra buffer overflow. Nosso último trabalho
([iovt]) já descreveu como extrair o firmware
do roteador alvo e como encontrar um binário potencialmente perigoso.
Para isso, foi usada a ferramenta EMBA [emba]. O EMBA classifica todos
os binários encontrados no firmware pela quantidade de funções inseguras, como
strcpy, acesso à rede e proteção de segurança como stack canary ou
o NX-Bit, que se tornam interessantes ao explorar um buffer overflow,
que pode ser encontrado no Código 1.
Código 1: Resultado do EMBAs para usos inseguros da função strcpy.
```