Fuzzing 101 básico

• Fuzzing-101 é um curso criado para que pessoas que estão aprendendo fuzzing pela primeira vez pratiquem o processo de encontrar vulnerabilidades em alvos de software reais
• O curso é composto por 10 alvos reais e 10 exercícios, cobrindo Xpdf, libexif, TCPdump, LibTIFF, Libxml2, GIMP, VLC media player, Adobe Reader, 7-Zip e Google Chrome/V8
• Cada exercício tem como objetivo reproduzir ou descobrir um CVE, usando vulnerabilidades como CVE-2019-13288, CVE-2016-2334 e CVE-2019-5847, junto com AFL++, ASan, LCOV, WinAFL e Fuzzilli
• O requisito para acompanhar é um sistema Linux com conexão à internet; recomenda-se conhecimento básico de Linux, e todos os exercícios foram testados no Ubuntu 20.04.2 LTS
• Fuzzing é uma técnica automatizada de teste que injeta entradas aleatórias ou modificadas em um programa e monitora exceções ou crashes, e este curso toma como objeto de estudo o funcionamento básico de fuzzers evolutivos guiados por cobertura

---

Objetivo e público do curso

• Fuzzing-101 é um curso para quem quer aprender fuzzing de forma profissional, mas não sabe por onde começar
• O curso é composto por 10 alvos reais e 10 exercícios
• O público-alvo é:
  • quem quer aprender os fundamentos de fuzzing
  • quem quer aprender como encontrar vulnerabilidades em projetos de software reais

Estrutura dos exercícios

• Cada exercício apresenta o software específico, o CVE a ser encontrado, o tempo estimado e os principais tópicos

Exercício	Alvo	CVE a encontrar	Tempo estimado	Tópicos principais
Exercise 1	Xpdf	CVE-2019-13288	120 min	Afl-clang-fast, Afl-fuzz, GDB
Exercise 2	libexif	CVE-2009-3895, CVE-2012-2836	6 horas	Afl-clang-lto, fuzzing de bibliotecas, Eclipse IDE
Exercise 3	TCPdump	CVE-2017-13028	4 horas	ASan, Sanitizers
Exercise 4	LibTIFF	CVE-2016-9297	3 horas	cobertura de código, LCOV
Exercise 5	Libxml2	CVE-2017-9048	3 horas	dicionário, paralelização básica, fuzzing de argumentos de linha de comando
Exercise 6	GIMP	CVE-2016-4994, bug bônus	7 horas	fuzzing persistente, fuzzing de aplicações interativas
Exercise 7	VLC media player	CVE-2019-14776	6 horas	instrumentação parcial, harness de fuzzing
Exercise 8	Adobe Reader	nenhum	8 horas	fuzzing de aplicações de código fechado, instrumentação com QEMU
Exercise 9	7-Zip	CVE-2016-2334	8 horas	WinAFL, fuzzing de aplicações Windows
Exercise 10	Google Chrome / V8	CVE-2019-5847	8 horas	Fuzzilli, fuzzing de motores JavaScript

Ambiente de execução e ferramentas

• O necessário é um sistema Linux com conexão à internet
• Uma imagem VMware para uso nos exercícios é fornecida
• Conhecimento básico de uso de Linux é fortemente recomendado
• Todos os exercícios foram testados no Ubuntu 20.04.2 LTS
• O curso usa AFL++
  • O AFL++ é apresentado como um fork mais novo e superior do AFL de Michał “lcamtuf” Zalewski

Conceitos básicos de fuzzing

• Teste de fuzz (fuzz testing), ou fuzzing, é uma técnica automatizada de teste de software que insere entradas aleatórias ou modificadas em um programa e monitora exceções ou crashes
• Como exemplos de fuzzers bem-sucedidos em aplicações reais, são apresentados AFL, libFuzzer e HonggFuzz
• Essas três ferramentas são exemplos de fuzzers evolutivos guiados por cobertura

Fuzzers evolutivos guiados por cobertura

• A abordagem evolutiva (evolutionary) é um método meta-heurístico inspirado em algoritmos evolutivos
  • O conjunto inicial de entradas, ou seeds, evolui e é transformado com o tempo
  • Como exemplo de critério de seleção, usa-se a cobertura
• Um fuzzer guiado por cobertura (coverage-guided) coleta e compara dados de cobertura de código por entrada para aumentar a chance de encontrar novos crashes
  • A coleta de cobertura normalmente é feita por meio de instrumentação
  • São selecionadas entradas que levam a novos caminhos de execução

Histórico de alterações

• 2022-02-14: alguns erros de digitação em wget no Exercise 5 foram corrigidos
• 2021-11-25: o Exercise 3 foi atualizado com algumas correções

[GN⁺]

Opiniões no Hacker News

• Uma anedota sobre fuzzing: https://threadreaderapp.com/thread/1799457232607985698
  É uma ótima leitura se você quiser desperdiçar uns 11 minutos

  • O Google mostra um artigo da CNET de 2007, provavelmente porque a eEye “espalhou press releases para todo lado”: https://www.cnet.com/news/privacy/flaw-found-in-office-2007/
    Não entendo bem essa cultura de competir para encontrar bugs em produtos de outras empresas e depois se gabar por ter encontrado um justamente no Microsoft Publisher, enquanto diminui a Microsoft
    Talvez todos sejamos sortudos se houver empresas nas quais passar a semana inteira virando noites testando nosso produto seja o “processo padrão”
  • O estilo de escrita certamente deixa tudo mais divertido
    Fui ver quem era o autor e talvez seja alguém que eu conhecia do IRC; “Mantis” e “infosec” batem certinho

• O interessante é que isso é claramente diferente da abordagem do Go
  Em Go, dá para executar fuzzing de forma simples, como se estivesse rodando testes, então é muito fácil mirar partes específicas de uma aplicação ou biblioteca
  Com isso, muitas dessas técnicas acabam se tornando desnecessárias
  Tenho curiosidade sobre técnicas para orientar melhor o fuzzing, mas, por enquanto, parece que o melhor é fornecer um corpus de sementes e torcer para dar certo

  • Algumas ferramentas de fuzzing, como o libFuzzer, usam a representação intermediária do LLVM para criar métricas de cobertura de código e realimentá-las no algoritmo de fuzzing, aumentando a cobertura dos testes
  • Já propus a ideia de usar aprendizado por reforço para orientar a cobertura como tema de doutorado, mas acabei não seguindo por esse caminho e não sei se funcionaria

• Fiquei surpreso que o Heartbleed não esteja na lista. É bem fácil de reproduzir

  • Acho que ficou de fora porque todos estes tutoriais usam arquivos locais ou dados locais e não tratam de fuzzing baseado em rede