Neste artigo, falaremos não da própria AFL clássica, mas dos utilitários projetados para ela e suas modificações, que, a nosso ver, podem melhorar significativamente a qualidade da difusão. Se você quer saber como aumentar o AFL e como encontrar mais vulnerabilidades mais rapidamente - continue lendo!

O que é AFL e para que serve?

O AFL é um fuzzer guiado por cobertura ou baseado em feedback. Mais sobre esses conceitos podem ser encontrados em um artigo interessante, “Fuzzing: Art, Science, and Engineering” . Vamos resumir informações gerais sobre a AFL:

• Ele modifica o arquivo executável para descobrir como ele influencia a cobertura.
• Muda os dados de entrada para maximizar a cobertura.
• Repita a etapa anterior para descobrir onde o programa falha.
  • É altamente eficaz, o que é comprovado pela prática.
    • É muito fácil de usar.

Aqui está uma representação gráfica:



Se você não sabe o que é AFL, aqui está uma lista de recursos úteis para você começar:

1. A página oficial do projeto .
2. afl-training - uma breve introdução ao AFL.
3. afl-demo - uma demonstração simples de programas em C ++ com AFL.
4. afl-cve - uma coleção das vulnerabilidades encontradas na AFL (não é atualizada desde 2017).
5. Aqui você pode ler sobre as coisas que o AFL adiciona a um programa durante sua compilação.
6. Algumas dicas úteis sobre aplicativos de rede em difusão.

No momento em que este artigo estava sendo escrito, a versão mais recente do AFL era 2.52b . O fuzzer está em desenvolvimento ativo e, com o tempo, alguns desenvolvimentos secundários estão sendo incorporados ao ramo principal da AFL e se tornam irrelevantes. Hoje, podemos citar várias ferramentas acessórias úteis, listadas no capítulo a seguir.


Alguns usuários da AFL observaram que seu autor, Michal Zalewski, aparentemente havia abandonado o projeto desde a última modificação até 5 de novembro de 2017. Isso pode estar relacionado a ele deixar o Google e trabalhar em alguns novos projetos. Portanto, os usuários começaram a fazer novos patches para a última versão atual 2.52b.



Existem também variações e derivações diferentes do AFL, que permitem difundir Python, Go, Rust, OCaml, GCJ Java, syscalls do kernel ou até VMs inteiras.

Ferramentas acessórias

Neste capítulo, coletamos vários scripts e ferramentas para AFL e os dividimos em várias categorias:

Processamento de falha

• afl-utils - um conjunto de utilitários para processamento / análise automática de falhas e redução do número de casos de teste.
• afl-crash-analyzer - outro analisador de falhas para o AFL.
• fuzzer-utils - um conjunto de scripts para a análise dos resultados.
• atriage - uma ferramenta simples de triagem.
• afl-kit - afl-cmin em Python.
• AFLize - uma ferramenta que gera automaticamente compilações de pacotes debian adequados para AFL.
• afl-fid - um conjunto de ferramentas para trabalhar com dados de entrada.

Trabalhar com cobertura de código

• afl-cov - fornece dados humanos sobre cobertura.
• contagem-afl-chamadas - avaliação da proporção. O script conta o número de blocos de instrumentação no binário.
• afl-sancov - é como afl-cov, mas usa um desinfetante de ruídos.
• covnavi - um script para cobrir código e análise do Cisco Talos Group.
• LAF LLVM Passes - algo como uma coleção de patches para AFL que modificam o código para facilitar a localização de ramificações pelo difusor.

Alguns scripts para a minimização de casos de teste

• afl-pytmin - um invólucro para afl-tmin que tenta acelerar o processo de minimização do caso de teste usando muitos núcleos de CPU.
• afl-ddmin-mod - uma variação do afl-tmin com base no algoritmo ddmin.
• halfempty - é um utilitário rápido para minimizar os casos de teste do Tavis Ormandy com base na paralelização.

Execução distribuída

• disfuzz-afl - difusão distribuída para AFL.
• AFLDFF - Estrutura de difusão distribuída da AFL.
• afl-launch - uma ferramenta para a execução de muitas instâncias AFL.
• afl-mothership - gerenciamento e execução de muitos fuzzers AFL sincronizados na nuvem da AWS.
• afl-in-the-cloud - outro script para executar o AFL na AWS.
• VU_BSc_project - teste de difusão das bibliotecas de código aberto com libFuzzer e AFL.

Recentemente, foi publicado um artigo muito bom, intitulado “Dimensionando o AFL para uma máquina de 256 threads” .

Implantação, gerenciamento, monitoramento, relatórios

• afl-other-arch - é um conjunto de patches e scripts para adicionar facilmente suporte a várias arquiteturas não-x86 para AFL.
• afl-trivia - alguns pequenos scripts para simplificar o gerenciamento do AFL.
• afl-monitor - um script para monitorar o AFL.
• afl-manager - um servidor web em Python para gerenciar multi-afl.
• afl-tools - uma imagem de uma janela de encaixe com afl-latest, afl-dyninst e Triforce-afl.
• afl-remote - um servidor web para o gerenciamento remoto de instâncias AFL.

Modificações AFL

A AFL teve um impacto muito forte na comunidade de pesquisadores de vulnerabilidade e em confusão. Não é de surpreender que, depois de algum tempo, as pessoas começaram a fazer modificações inspiradas na AFL original. Vamos dar uma olhada neles. Em diferentes situações, cada uma dessas modificações tem seus próprios prós e contras em comparação com o AFL original.

Quase todos os mods podem ser encontrados em hub.docker.com

Para que?

• Aumentar a velocidade e / ou cobertura do código
  
  • Algoritmos
  • Meio ambiente
    
    • OS
    • Hardware
  
  
• Trabalhando sem código fonte
  
  • Emulação de código
  • Instrumentação de código
    
    • Estático
    • Dinâmico

Modos padrão da operação AFL

Antes de prosseguirmos com o exame de diferentes modificações e garfos da AFL, precisamos falar sobre dois modos importantes, que também foram modificações no passado, mas que foram incorporadas. Eles são Syzygy e Qemu.

Modo Syzygy - é o modo de trabalhar no instrument.exe

instrument.exe --mode=afl --input-image=test.exe --output-image=test.instr.exe 

O Syzygy permite reescrever estaticamente os binários do PE32 com o AFL, mas requer símbolos e um desenvolvedor adicional para conscientizar o kernel do WinAFL.

Modo Qemu - a maneira como funciona no QEMU pode ser vista em "Internos do fuzzer AFL - QEMU Instrumentation" . O suporte ao trabalho com binários com QEMU foi adicionado ao AFL upstream na Versão 1.31b. O modo AFL QEMU funciona com a funcionalidade adicional da instrumentação binária no mecanismo de tradução binária qemu tcg (um pequeno gerador de código). Para isso, o AFL possui um script de construção qemu, que extrai as fontes de uma certa versão do qemu (2.10.0), as coloca em vários pequenos patches e cria uma arquitetura definida. Em seguida, é criado um arquivo chamado afl-qemu-trace, que na verdade é um arquivo de emulação no modo de usuário de (emulação de apenas arquivos ELF executáveis) qemu-. Assim, é possível usar o fuzzing com feedback nos binários elf para muitas arquiteturas diferentes suportadas pelo qemu. Além disso, você obtém todas as ferramentas legais de AFL, desde o monitor com informações sobre a sessão atual até itens avançados, como afl-analyse. Mas você também recebe as limitações do qemu. Além disso, se um arquivo for construído com uma cadeia de ferramentas usando os recursos SoC de hardware, que iniciam o binário e não são suportados pelo qemu, a difusão será interrompida assim que houver uma instrução específica ou um MMIO específico for usado.

Aqui está outra bifurcação interessante do modo qemu, onde a velocidade foi aumentada 3-4 vezes com a instrumentação do código TCG e o desconto.

Forquilhas

A aparência dos garfos da AFL está antes de mais nada relacionada às alterações e melhorias dos algoritmos da AFL clássica.

• pe-afl - Uma modificação para arquivos PE de difusão que não têm código-fonte no sistema operacional Windows. Para sua operação, o fuzzer analisa um programa de destino com o IDA Pro e gera as informações para a seguinte instrumentação estática. Uma versão instrumentada é então confundida com AFL.
• afl-cygwin - é uma tentativa de portar o AFL clássico para Windows com Cygwin. Infelizmente, tem muitos erros, é muito lento e o desenvolvimento de foi abandonado.
• AFLFast (estende o AFL com Power Schedules) - um dos primeiros garfos do AFL. Ele adicionou heurísticas, que permitem percorrer mais caminhos em um curto período de tempo.
• FairFuzz - uma extensão para AFL, que tem como alvo ramificações raras.
• AFLGo - é uma extensão do AFL destinada a obter determinadas partes do código em vez da cobertura completa do programa. Pode ser usado para testar patches ou fragmentos de código adicionados recentemente.
• PerfFuzz - uma extensão para AFL, que procura casos de teste que podem desacelerar significativamente o programa.
• Pythia - é uma extensão da AFL que visa prever o quão difícil é encontrar novos caminhos.
• Angora - é um dos mais recentes fuzzers, escrito sobre ferrugem. Utiliza novas estratégias para mutação e aumento da cobertura.
• Neuzz - mexendo com redes neurais.
• UnTracer-AFL - integração do AFl com o UnTracer para rastreamento eficaz.
• Qsym - Mecanismo prático de execução concólica sob medida para difusão híbrida. Essencialmente, é um mecanismo de execução simbólico (os componentes básicos são executados como um plug-in para o intel pin) que, juntamente com o AFL, executam difusão híbrida. Este é um estágio na evolução da difusão baseada em feedback e exige uma discussão separada. Sua principal vantagem é que é possível executar uma execução concólica relativamente rápida. Isso ocorre devido à execução nativa de comandos sem representação intermediária de código, capturas instantâneas e algumas heurísticas. Ele usa o antigo pino da Intel (devido a problemas de suporte entre a libz3 e outros DBTs) e atualmente pode trabalhar com as arquiteturas elf x86 e x86_64.
• Superion - Greybox fuzzer, cuja vantagem óbvia é que, juntamente com um programa instrumentado, ele também obtém a especificação dos dados de entrada usando a gramática ANTLR e depois realiza mutações com a ajuda dessa gramática.
• AFLSmart - Outro fuzzer do Graybox. Como entrada, ele obtém a especificação dos dados de entrada no formato usado pelo difusor Peach.

Existem muitos trabalhos de pesquisa dedicados à implementação das novas abordagens e técnicas de difusão em que o AFL é modificado. Apenas white papers estão disponíveis, então nem nos importamos em mencioná-los. Você pode pesquisá-los no Google, se quiser. Por exemplo, alguns dos mais recentes são CollAFL: Path Sensitive Fuzzing , EnFuzz , "Abordagem eficiente para intérpretes de fuzzing" , ML para AFL.

Modificações baseadas no Qemu

• TriforceAFL - AFL / QEMU fuzzing com emulação total de um sistema. Um garfo do nccgroup. Permite difundir todo o sistema operacional no modo qemu. Isso é realizado com uma instrução especial (aflCall (0f 24)), que foi adicionada na CPU QEMU x64. Infelizmente, não é mais suportado; a última versão do AFL é 2.06b.
• TriforceLinuxSyscallFuzzer - a confusão de chamadas do sistema Linux.
• afl-qai - um pequeno projeto de demonstração com QEMU Augmented Instrumentation (qai).

Uma modificação baseada no KLEE

kleefl - para gerar casos de teste por meio de execução simbólica (muito lento em grandes programas).

Uma modificação baseada no Unicorn

afl-unicorn - permite difundir fragmentos de código emulando-o no Unicorn Engine . Usamos com sucesso essa variação de AFL em nossa prática, nas áreas do código de um determinado RTOS, que foi executado no SOC, portanto, não podemos usar o modo QEMU. O uso dessa modificação é justificado no caso em que não podemos ter fontes (não podemos construir um binário independente para a análise do analisador) e o programa não recebe dados de entrada diretamente (por exemplo, dados é criptografado ou é uma amostra de sinal como em um binário CGC), então podemos reverter e encontrar as supostas funções-locais, onde os dados são obtidos em um formato conveniente para o fuzzer. Esta é a modificação mais geral / universal do AFL, ou seja, permite difundir qualquer coisa. É independente da arquitetura, fontes, formato dos dados de entrada e formato binário (o exemplo mais impressionante de bare-metal - apenas fragmentos de código da memória do controlador). O pesquisador primeiro examina esse binário e escreve um fuzzer, que emula o estado na entrada do procedimento do analisador. Obviamente, ao contrário da AFL, isso requer um certo exame de binário. Para firmware bare-metal, como Wi-FI ou banda base, há algumas desvantagens que você precisa ter em mente:

1. Temos que localizar a verificação da soma de controle.
2. Lembre-se de que o estado do difusor é um estado de memória que foi salvo no despejo de memória, o que pode impedir que o difusor chegue a determinados caminhos.
3. Não há saneamento de chamadas para a memória dinâmica, mas isso pode ser realizado manualmente e dependerá do RTOS (precisa ser pesquisado).
4. A interação Intertask RTOS não é emulada, o que também pode impedir a localização de certos caminhos.

Um exemplo de como trabalhar com esta modificação "afl-unicorn: Código binário arbitrário confuso" e "afl-unicorn: parte 2 - confundindo o 'imperdoável'" .

Antes de prosseguirmos com as modificações baseadas nas estruturas da instrumentação binária dinâmica (DBI), não devemos esquecer que a velocidade mais alta dessas estruturas é mostrada pelo DynamoRIO, Dynlnst e, finalmente, PIN.

Modificações baseadas em PIN

• aflpin - AFL com instrumentação PIN da Intel.
• afl_pin_mode - outra instrumentação AFL realizada através do PIN da Intel.
• afl-pin - AFL com PINtool.
• NaFl - Um clone (do núcleo básico) do fuzzer AFL.
• PinAFL - o autor desta ferramenta tentou portar o AFL para o Windows para a difusão de binários já compilados. Parece que foi feito da noite para o dia apenas por diversão; o projeto nunca foi além. O repositório não possui fontes, apenas binários compilados e instruções de inicialização. Não sabemos em qual versão do AFL ela se baseia e ela suporta apenas aplicativos de 32 bits.

Como você pode ver, existem muitas modificações diferentes, mas elas não são muito úteis na vida real.

Modificações baseadas em Dyninst

afl-dyninst - American Fuzzy Lop + Dyninst == AFL balckbox difusa. O recurso desta versão é que primeiro um programa pesquisado (sem o código-fonte) é instrumentado estaticamente (instrumentação binária estática, reescrita binária estática) com Duninst e, em seguida, é confundido com o AFL clássico que pensa que o programa é construído com afl- gcc / afl-g ++ / afl-as;) Como resultado, ele permite trabalhar com uma produtividade muito boa sem o código fonte - costumava estar na velocidade de 0,25x em comparação com uma compilação nativa. Possui uma vantagem significativa em comparação ao QEMU: permite a instrumentação de bibliotecas vinculadas dinâmicas, enquanto o QEMU pode apenas instrumentar o arquivo executável básico vinculado estaticamente às bibliotecas. Infelizmente, agora é relevante apenas para Linux. Para suporte do Windows, são necessárias alterações no próprio Dyninst, o que está sendo feito .

Há ainda outro garfo com velocidade aprimorada e certos recursos (o suporte das arquiteturas AARCH64 e PPC).

Modificações baseadas no DynamoRIO

• drAFL - AFl + DynamoRIO - difundindo sem fontes no Linux.
• afl-dr - outra implementação baseada no DynamoRIO que muito bem descreveu no Habr .
• afl-dynamorio - uma modificação por vanhauser-thc. Aqui está o que ele diz sobre isso: "execute o AFL com o DynamoRIO quando o afl-dyninst normal estiver travando o modo binário e qemu -Q não é uma opção". Ele suporta ARM e AARCH64. Em relação à produtividade: o DynamoRIO é cerca de 10 vezes mais lento que o Qemu, 25 vezes mais lento que o dyninst, mas cerca de 10 vezes mais rápido que o Pintool.
• WinAFL - o mais famoso garfo AFL do Windows. (DynamoRIO, também modo syzygy). Era apenas uma questão de tempo para que esse mod aparecesse, porque muitos queriam experimentar o AFL no Windows e aplicá-lo a aplicativos sem fontes. Atualmente, essa ferramenta está sendo ativamente aprimorada e, independentemente de uma base de códigos relativamente desatualizada da AFL (2.43b quando este artigo foi escrito), ajudou a encontrar várias vulnerabilidades (CVE-2016-7212, CVE-2017-0073, CVE- 2017-0190, CVE-2017-11816). Os especialistas da equipe do Projeto Zero do Google e da equipe de vulnerabilidades e mitigações do MSRC estão trabalhando neste projeto, para que possamos esperar um maior desenvolvimento. Em vez de instrumentação de tempo de compilação, os desenvolvedores usaram instrumentação dinâmica (baseada no DynamoRIO), que diminuiu significativamente a execução do software analisado, mas a sobrecarga resultante (duplicada) é comparável à da AFL clássica no modo binário. Eles também resolveram o problema do lançamento rápido do processo, chamando-o de modo persistente de difusão; eles escolhem a função para difundir (pelo deslocamento dentro do arquivo ou pelo nome da função presente na tabela de exportação) e instrumentam-na para que possa ser chamada no ciclo, iniciando várias amostras de dados de entrada sem reiniciar o processo. Um artigo foi publicado recentemente, descrevendo como os autores encontraram cerca de 50 vulnerabilidades em cerca de 50 dias usando o WinAFL. E logo antes de ser publicado, o modo Intel PT havia sido adicionado ao WinAFL; detalhes podem ser encontrados aqui .

Um leitor avançado pode perceber que há modificações em todas as estruturas populares de instrumentação, exceto Frida . A única menção ao uso de Frida com AFL foi encontrada em "Chizpurfle: um Android Fuzzer Gray-Box Android para personalizações de serviços de fornecedores" . Uma versão do AFL com Frida é realmente útil porque o Frida suporta várias arquiteturas RISC.

Muitos pesquisadores também estão ansiosos pelo lançamento do framework DBI Scopio pelo criador do Capstone, Unicorn e Keystone. Com base nessa estrutura, os autores já criaram um fuzzer (Darko) e, de acordo com eles, o utilizam com sucesso para difundir dispositivos incorporados. Mais sobre isso pode ser encontrado em "Indo fundo: localizando 0 dias em sistemas embarcados com difusão guiada por cobertura de código" .

Modificações, com base nos recursos de hardware do processador

Quando se trata de modificações de AFL com o suporte dos recursos de hardware do processador, em primeiro lugar, ele permite o código do kernel com distorção e, em segundo lugar - permite a distorção muito mais rápida dos aplicativos sem o código-fonte.

E, é claro, falando sobre os recursos de hardware do processador, estamos principalmente interessados ​​no Intel PT (Processor Tracing). Está disponível a partir da 6ª geração de processadores (aproximadamente, desde 2015). Portanto, para poder usar os fuzzers listados abaixo, você precisa de um processador compatível com o Intel PT.

• WinAFL-IntelPT - uma modificação WinAFL de terceiros que usa o Intel PT em vez do DynamoRIO.
• kAFL - é um projeto acadêmico que visa solucionar o problema orientado pela cobertura para a difusão independente do SO do kernel. O problema está resolvendo usando um hypervisor e o Intel PT. Mais informações sobre isso podem ser encontradas no white paper "kAFL: Feedback assistido por hardware confundido com os kernels do SO" .

Conclusão

Como você pode ver, a área de modificações da AFL está evoluindo ativamente. Ainda assim, há espaço para experimentos e soluções criativas; você pode criar uma nova modificação útil e interessante.

Obrigado por nos ler e boa sorte com a difusão!

Co-autor: Nikita Knyzhov presler

PS Graças à equipe do centro de pesquisa, sem a qual este artigo seria impossível.