0xricksanchez/fisy-fuzzEsta é a estrutura completa de fuzzing de sistema de arquivos que apresentei na conferência Hack in the Box 2020 Lockdown Edition em abril.
Este é o framework completo de fuzzing de sistema de arquivos que apresentei na conferência Hack in the Box 2020 Lockdown Edition em Abril.
O objetivo deste framework é descobrir bugs de segurança no kernel em sistemas UNIX com forte foco em sistemas BSD. Foi desenvolvido e amplamente testado contra FreeBSD, OpenBSD e NetBSD, mas já possui algum suporte menor para sistemas baseados em Linux. Conseguimos descobrir com sucesso mais de 100 bugs únicos de kernel para sistemas de arquivos baseados em UFS e EXT, enquanto também obtivemos muitos insights sobre a adição recente do ZFS.
O makeFS2.py pode ser usado como um utilitário independente para gerar diferentes sistemas de arquivos válidos.
O uso é explicado em detalhes no repositório do material da conferência
O framework foi testado apenas no Ubuntu 18.04.
Ele depende de KVM, QEMU e libvirt.
O Requirements.sh configura todas as dependências necessárias.
O framework pode ser totalmente funcional na versão mais recente do Ubuntu 20.04.
Outros sistemas host não baseados em apt devem ser facilmente suportados e requerem apenas pequenas alterações no Requirements.sh.
Depois de cumprir os requisitos, você pode continuar com as etapas de configuração!
Consulte o SETUP.md. Se alguma etapa não estiver clara, entre em contato!
Iniciar o fuzzer requer apenas a execução de: python3 run.py.
Dependendo da sua configuração, você pode precisar de privilégios sudo.
Quando tudo iniciar com sucesso, você pode anexar à sessão tmux de fuzzing através de:
(sudo) tmux attach-session -t fsfuzzer
O framework pode ser configurado com o script src/config/fuzzing_config.py:
# [especificações das tarefas de fuzzing]
# Lista de dicionários especificando cada instância de fuzzing
fuzzer = [
{
"name": "fuzz1", # Algum nome para contabilidade interna
"fs_creator_vm": "genBox", # Nome conforme especificado no libvirt para a VM que gerencia a geração do sistema de arquivos, pode ser o mesmo em todas as instâncias
"fuzzing_vm": "fuzzBox_0", # Nome conforme especificado no libvirt para a VM que gerencia a geração do sistema de arquivos
"mutation_engine": "radamsa, 0", # Mecanismo de mutação a ser usado e tamanho da mutação (radamsa não aceita argumento de tamanho)
"target_fs": "ufs2", # Sistema de arquivos alvo
"target_size": 15, # Tamanho máximo do sistema de arquivos em Megabyte
"populate_with_files": 10, # Quantidade de arquivos que serão gerados
"max_file_size": 1024, # Tamanho máximo do arquivo em bytes para cada arquivo gerado
"enable_dyn_scaling": False, # O escalonamento dinâmico aumentará o tamanho do sistema de arquivos periodicamente
},
]
# [credenciais]
# Credenciais para o usuário root nas VMs
# Espera-se que sejam as mesmas em todas as instâncias, mas não necessariamente root
user = "root"
pw = "root"
Os mecanismos de mutação disponíveis são:
O escalonamento dinâmico foi implementado inicialmente para testar se o tamanho de um sistema de arquivos afeta as possíveis falhas. Não consegui identificar um valor de gatilho para o tamanho do sistema de arquivos onde as falhas mudam, então esta flag pode permanecer desabilitada. Isso também evita sofrer uma queda de desempenho em execuções mais longas, pois sistemas de arquivos maiores levam mais tempo para sofrer mutação.
Os parâmetros de configuração restantes devem ser autoexplicativos.
O vídeo abaixo mostra uma demonstração rápida onde duas instâncias de fuzzing, ambas visando FreeBSD, com um sistema UFS2 mutado por radamsa e um sistema EXT com bytes aleatórios invertidos. O sistema de arquivos UFS mutado leva diretamente a uma falha, demonstrando a rapidez com que é possível causar uma falha no kernel.
Com esta configuração, consegui encontrar mais de 100 bugs únicos de kernel no FreeBSD, NetBSD e OpenBSD para sistemas de arquivos baseados em UFS e EXT. Entre essas falhas, tive várias muito interessantes:
A maioria das falhas foram DoS do kernel. Além disso, a maioria das falhas encontradas ainda não foram corrigidas até hoje (Maio de 2020). Então vá em frente e encontre bugs de kernel em implementações de sistemas de arquivos :).
Tudo isso foi construído com 'desenvolvimento orientado pela confiança', o que significa que cresceu rápido demais e ficou grande demais a partir de uma simples ideia de PoC. Portanto, também não há testes e muito provavelmente alguns bugs. Peço desculpas se você se deparar com falhas (que não sejam relacionadas a kernel panic), mas fique à vontade para fazer um PR ou me contatar e corrigirei as coisas o mais rápido possível!
Twitter: @0xricksanchez