litefuzz

Um fuzzer multi-plataforma para cutucar binários de espaço de usuário, clientes e servidores.

Ele encontrou bugs em mais de 50 aplicativos e bibliotecas de grandes empresas e código aberto.

Configuração simples para começar a fuzzar no Linux, Mac e Windows.

litefuzz

Este é um alvo local simples que o AFL++ é perfeitamente capaz de lidar e foi dado apenas como um exemplo rápido. A Litefuzz foi projetada para fazer muito mais em termos de fuzzing de rede e GUI, como você verá ao se aprofundar. ## por quê Sim, outro fuzzer e um que não acompanha muito bem as tendências e convenções atuais. Compensações foram feitas para atender a certos requisitos. Esses requisitos são: um fuzzer que funcione por padrão em múltiplas plataformas, que fuzze tanto alvos locais quanto de rede e que seja muito fácil de usar. Não estou tentando convencer ninguém de nada, mas vamos fornecer algum contexto. Alguns alvos exigem muito esforço para integrar fuzzers como AFL à cadeia de construção. Isso não é um problema, pois este fuzzer não requer instrumentação, sacrificando a cobertura precisa obtida pela instrumentação em prol da facilidade e portabilidade. O AFL também não suporta fuzzing de rede nativamente, e embora existam projetos baseados nele que o façam, eles estão longe de serem diretos de usar e geralmente exigem mais modificações de código e harnesses para funcionar (história semelhante com [Libfuzzer](https://llvm.org/docs/LibFuzzer.html)). Ele não faz fuzzing paralelo, nem suporta algo como as melhorias de velocidade impressionantes que o [modo persistente](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) pode fornecer, portanto não consegue escalar nem perto de fuzzers com tais capacidades. Novamente, este não é um fuzzer de última geração. Mas não requer código-fonte, configurar uma build adequadamente ou certos recursos do SO. Ele pode até fuzzer algumas GUIs de clientes de rede e aplicativos interativos. Ele vive "da terra" de várias maneiras e muitos dos recursos, como mutadores e minimização, foram escritos do zero. Ele foi projetado para "simplesmente funcionar" e esforço foi investido na automação da configuração e instalação das poucas dependências que precisa. Este fuzzer foi escrito para servir a um propósito, para fornecer valor em muitos cenários e ambientes de alvos diferentes e, mais importante, pelo que todos os fuzzers devem ser julgados: a capacidade de encontrar bugs. E **ele encontra** [bugs](https://github.com/sec-tools/beta/blob/main/README.md#trophies). Ele não presume que exista código-fonte do alvo, então pode cobrir software fechado razoavelmente bem. Pode ser executado como parte de automação com pouca modificação, mas é voltado para ser divertido de usar para pesquisadores de vulnerabilidades. No entanto, é mais útil pensar nele como um projeto de P&D, em vez de um produto completo. Além disso, não há configuração complicada onde ele esteja ligeiramente quebrado de fábrica ou precise de mais trabalho para funcionar em sistemas operacionais modernos. Foi testado e funciona no Ubuntu Linux, Mac e Windows e vem com scripts totalmente funcionais que fazem quase tudo para você, a fim de configurar um ambiente pronto para fuzzing. **Assim que o script de configuração for concluído, leva apenas alguns minutos para começar a fuzzear uma tonelada de alvos diferentes.** ## como funciona **O Litefuzz suporta três modos diferentes: local, cliente e servidor.** Local significa almejar binários locais, que no Linux/Mac são lançados via subprocesso com suporte automático de triagem via GDB e LLDB respectivamente em crashes e via [WinAppDbg](https://github.com/MarioVilas/winappdbg) no Windows. Os crashes são gravados em um diretório local de crashes e classificados por tipo de falha, como AVs de leitura/escrita ou SIGABRT/SIGSEGV, juntamente com os hashes dos arquivos. Todos os crashes únicos são triados enquanto fuzzeia e esses dados, juntamente com a saída do alvo (conforme disponível), também são capturados e colocados como artefatos no mesmo diretório. Também é possível reproduzir crashes com `--replay` e fornecendo o arquivo que causou o crash. No modo cliente `local`, o diretório de entrada deve conter uma saudação, resposta ou outros dados do servidor que um cliente esperaria ao se conectar a um servidor. Atualmente, apenas um "disparo" é implementado para fuzzing de rede, sem suporte a sessões complexas. O cliente é lançado via linha de comando e depurado da mesma forma que no fuzzing de arquivos. Um listener é configurado para suportar este cenário; sim, é lento e uma tarefa quase manual, mas funciona. Se um crash for detectado, ele é reproduzido no gdb para obter os detalhes da triagem. No modo cliente `remote`, isso funciona da mesma forma, exceto que não há depuração/triagem de crash local. No modo servidor *local*, é semelhante ao modo cliente local, e para o modo servidor `remote`, ele apenas se conecta a um alvo específico e envia dados de cliente mutados que o usuário especifica como entradas, mas apenas uma triagem simples do tipo "ainda conseguimos conectar? Se não, provavelmente crashou no último" é fornecida. Existem algumas funções de mutação escritas do zero que, em sua maioria, fazem mutações aleatórias com uma seleção aleatória de entradas especificadas pela flag `-i`. Para fuzzing de arquivos, basta selecionar o modo local e passar a linha de comando do alvo com FUZZ denotando onde o aplicativo espera o nome do arquivo para analisar, ex.: `tcpdump -r FUZZ`, juntamente com um diretório de entrada de "bons arquivos" para mutar. Para fuzzing de clientes de rede, é semelhante ao fuzzing local, mas também forneça detalhes da conexão via `-a`. E se você quiser fuzzear servidores, faça o modo servidor e forneça um `protocolo://endereço:porta` assim como para clientes. Ele fuzzeia tão rápido quanto o alvo consegue consumir os dados e sair, como é o caso da maioria dos aplicativos CLI, ou pelo tempo que você determinar antes que a execução local ou a conexão de rede expirem, o que pode ser muito mais lento. Sem truques fancy de exec ou kernel aqui. Mas, claro, se você escrever um harness que analise a entrada e saia rapidamente, cobrindo uma parte específica do alvo, isso também ajuda. Mas nesse ponto, se você consegue chegar tão perto do alvo, provavelmente é melhor usar o [modo persistente](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) ou recursos semelhantes que outros fuzzers podem oferecer. Resumindo... ### o que ele faz - funciona no linux, windows e mac e suporta py2/py3 - fuzzza binários CLI/GUI que leem de arquivos/stdin - fuzzza clientes e servidores de rede, de código aberto ou proprietário, disponíveis para depuração local ou remota - diffs, minimização, reprodução, classificação e autotriagem de crashes - outras coisas como suporte a TLS, fuzzing de binários Go e alguns extras para Mac - muta a entrada com vários mutadores internos + pyradamsa (Linux) ### o que ele não faz - instrumentação nativa - escalar com trabalhos simultâneos - fuzzing de sessão complexa - monitoramento remoto de cliente e servidor (apenas verificações básicas, ex.: conectar) ## suporte Testado principalmente no **Ubuntu Linux 20.04** (22.04 e 21.04 testados levemente), **Windows 10** e **Mac OS 11** (12 testado levemente). O fuzzer e os scripts de configuração podem funcionar também em versões um pouco mais antigas ou novas desses sistemas operacionais, mas a maioria da pesquisa, teste e desenvolvimento ocorreu nesses ambientes. O Python3 é suportado e foi feito um esforço para tornar o código compatível também com Python2, pois é necessário para fuzzing no Windows via [WinAppDbg](https://github.com/MarioVilas/winappdbg). Os testes de plataforma ocorreram principalmente em hardware Intel, mas as coisas parecem funcionar na maioria das vezes também na plataforma M1 da Apple (exceções notáveis: no Linux, o plugin exploitable para GDB provavelmente não é suportado, nem o Pyradamsa). Também existem scripts de configuração em setup/ para automatizar a maioria ou todas as tarefas e instalação de dependências. Ele geralmente consegue fuzzear binários nativos em cada plataforma, que geralmente são compilados em C/C++, mas também captura crashes para binários Go (experimental). ### versões python Python3 é suportado para Linux e Mac, enquanto Python2 é necessário para Windows. Por que Py3 no Linux e Mac? Pyautogui, Pyradamsa (apenas Linux), melhor suporte a sockets no Mac. Por que Py2 no Windows? Winappdbg requer Py2. ### linux GDB para depuração e [exploitable](https://github.com/jfoote/exploitable) para triagem de crashes. Se for OSS, você pode construir e instrumentar o alvo com [sanitizers](https://fuzzing-project.org/tutorial2.html) e tal, caso contrário, existem alguns [depuradores de memória](https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Heap_corruption) que podemos carregar em tempo de execução. Esta instalação, juntamente com as dependências python e outras coisas úteis, foi automatizada com [setup/linux.sh](https://github.com/sec-tools/litefuzz/blob/main/setup/linux.sh). O SO recomendado é Ubuntu 20.04, pois foi onde a maioria dos testes ocorreu. ### mac Em vez do gdb, usamos lldb para depuração no OS X, pois está incluído nas ferramentas de linha de comando do XCode. Ser administrador ou estar no grupo de desenvolvedores deve permitir usar o lldb, mas esse comportamento pode diferir entre ambientes e versões, e você pode precisar executá-lo com privilégios sudo se tudo mais falhar. A única coisa que você precisará fazer manualmente é desativar o SIP (no recovery, via cmd+R ou usando truques do vmware fusion). Caso contrário, a autotriagem falhará ao fuzzear no SO do Tim Apple. Quase toda a configuração foi automatizada com o script [setup/mac.sh](https://github.com/sec-tools/litefuzz/blob/main/setup/mac.sh), então você pode simplesmente executá-lo para um início rápido. ### windows [WinAppDbg](https://github.com/MarioVilas/winappdbg) é usado para depuração no Windows, com a pequena ressalva de que o fuzzing de stdin não é suportado. Assim como as configurações automatizadas para os outros sistemas operacionais, o chocolatey ajuda a automatizar a instalação de pacotes no Windows. Execute [setup/windows.bat](https://github.com/sec-tools/litefuzz/blob/main/setup/windows.bat) no diretório raiz do litefuzz como Administrador para automatizar as instalações. Ele instalará ferramentas de depuração e outras dependências para fazer as coisas funcionarem sem problemas. ### alvos Esta é uma lista dos tipos de alvos que foram testados e são geralmente suportados. * Aplicativos CLI/GUI locais que analisam formatos de arquivo ou stdin - suporte de depuração * Cliente de rede CLI/GUI local que analisa respostas do servidor - suporte de depuração para CLIs - suporte de depuração limitado para GUIs * Servidor de rede CLI local que analisa requisições de clientes - suporte de depuração (ressalva: deve ser possível executar como executável autônomo, caso contrário pode ser tratado como *remoto*) * Servidor de rede GUI local que analisa requisições de clientes - teoricamente suportado, não testado * Cliente de rede CLI/GUI remoto que analisa respostas do servidor - sem suporte de depuração * Servidor de rede CLI/GUI remoto que analisa requisições de clientes - sem suporte de depuração - exceção no Mac usando os recursos `attach` ou `reportcrash` Novamente, o fuzzer pode executar e suportar aplicativos, clientes e servidores locais no Linux, Mac e Windows e, claro, pode fuzzear coisas remotas independentemente da plataforma do alvo. ### triagem * Aplicativos CLI/GUI locais que analisam formatos de arquivo ou stdin - executar app, capturar sinais, reproduzir executando-o novamente dentro de um depurador com o crash * Cliente de rede CLI/GUI local que analisa respostas do servidor - executar app, capturar sinais, reproduzir executando-o novamente dentro de um depurador com o crash * Servidor de rede GUI/CLI local que analisa requisições de clientes - executar app no depurador, capturar sinais, reproduzir executando-o novamente dentro de um depurador com o crash * Cliente de rede CLI/GUI remoto que analisa respostas do servidor - sem visibilidade, coletar crashes do lado remoto - pode escrever scripts de suporte manualmente para auxiliar na triagem * Servidor de rede CLI/GUI remoto que analisa requisições de clientes - sem visibilidade, coletar crashes do lado remoto - pode escrever scripts de suporte manualmente para auxiliar na triagem - exceção no Mac são as opções `attach` e `reportcrash`, que podem ser usadas para habilitar algumas capacidades de triagem ## começando A maior parte da configuração entre plataformas foi automatizada com os scripts no diretório [setup](https://github.com/sec-tools/litefuzz/blob/main/README.md#setup). Basta executá-los a partir da raiz do litefuzz e isso deve economizar muito tempo e ajudar a habilitar parte do que é necessário para implantações automatizadas. É útil usar uma VM para configurar um SO limpo e ambiente de fuzzing, pois, entre outras coisas, seus recursos de snapshot são úteis. Veja [INSTALL.md](https://github.com/sec-tools/litefuzz/blob/main/INSTALL.md) para detalhes. **Após a instalação, consulte o exemplo de fuzzing do latex2rtf na seção inicial para uma execução rápida ou mergulhe em todas as opções de linha de comando e mais exemplos detalhados neste README.** ### docker Você pode executar o litefuzz usando Docker com o `Dockerfile` sem instalar dependências localmente. Isso é especialmente útil para testes rápidos ou se você quiser evitar instalar dependências no seu sistema. O Dockerfile funciona tanto: - **De dentro do repositório** - Usa arquivos locais (mais rápido, inclui alterações locais) - **Autônomo** - Pode ser construído a partir de qualquer diretório (clona do GitHub)```bash # Build the Docker image (from any directory with Dockerfile) docker build -t litefuzz:latest . # Run litefuzz docker run --rm litefuzz:latest python3 litefuzz.py --help

Isto executará o pytest para `test_litefuzz.py` no diretório principal e fornecerá resultados de APROVADO/REPROVADO assim que a execução do teste terminar. #### testes de aplicativos com travamentos Alguns exemplos de aplicativos com bugs para testar as capacidades de travamento e triagem nas diferentes plataformas podem ser encontrados na pasta `test`. - (a) desreferência de ponteiro nulo - (b) divisão por zero - (c) estouro de heap - (d-gui) bug de string de formato em uma GUI - (e) estouro de buffer no cliente - (f) estouro de buffer no servidor Eles são construídos automaticamente durante a configuração e você pode executá-los na linha de comando, em um depurador ou usá-los para testar como alvos de fuzzing. **Se estiver executando na linha de comando do Windows, verifique `Event Viewer -> Windows Logs -> Application` para ver os travamentos.** ## opções Há uma infinidade de opções e recursos diferentes para aproveitar vários cenários de alvo. A seguir, uma breve explicação e alguns exemplos para ajudar a entender como usá-los. ### diretório de travamentos `-o` permite especificar um diretório de travamentos diferente do padrão, que é o diretório crashes/ no caminho local. Pode-se usar isso para gerenciar pastas de travamentos para várias execuções de fuzzing simultâneas para diferentes aplicativos ao mesmo tempo. ### modo de isolamento `-u` isola o aplicativo alvo do processo normal de fuzzing, ex. executando ou enviando pacotes repetidamente e verificando travamentos. Em vez disso, este modo foi criado para aplicativos cliente interativos, ex. Postman, onde você pode usar scripts dentro do aplicativo para repetir conexões para fuzzing de cliente. O alvo é executado dentro de um depurador, o fuzzer é pausado para dar tempo ao usuário de clicar em alguns botões ou definir a configuração do alvo para fazê-lo executar automaticamente, o usuário retoma e agora você está fazendo fuzzing de clientes de rede interativos. `litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -z` O modo de isolamento + atualização pode ser usado para clientes interativos, ex. executar FileZilla em um depurador, mas continuar pressionando F5 para fazê-lo reconectar ao servidor a cada nova iteração. Além disso, servidores locais de CLI/GUI são apenas iniciados e executados uma vez dentro de um depurador para tornar o processo um pouco mais eficiente. `--key` também permite enviar teclas enquanto faz fuzzing em alvos interativos, como fazer fuzzing na análise das respostas do servidor FTP pelo FileZilla, enviando "atualizar conexão" com F5. `litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp/filezilla -u -pp --key "F5" -n 100 -z glibc` nota: o modo de isolamento foi testado apenas em Linux e não é suportado no Windows. ### tempo limite `-x segs` permite especificar um tempo limite. Na prática, isso é mais como "aproximadamente quanto tempo entre iterações" para alvos CLI e um tempo limite real para GUIs. ### mutadores `--mutator N` especifica qual mutador usar para fuzzing. Se a opção não for fornecida, uma escolha aleatória da lista de mutadores disponíveis é selecionada para cada iteração de fuzzing. Esses mutadores foram escritos do zero (com exceção do Radamsa, é claro). E embora tenham sido extensivamente testados e tenham se saído muito bem durante milhões de iterações, eles podem ter bugs sutis de vez em quando, mas geralmente isso não deve afetar a funcionalidade.``` FLIP_MUTATOR = 1 HIGHLOW_MUTATOR = 2 INSERT_MUTATOR = 3 REMOVE_MUTATOR = 4 CARVE_MUTATOR = 5 OVERWRITE_MUTATOR = 6 RADAMSA_MUTATOR = 7

### pausa Pressione ctrl+c para pausar o processo de fuzzing. Se quiser retomar, escolha `y` ou `n` para parar. Este recurso funciona bem em várias plataformas, mas pode ser menos confiável ao fuzzing aplicações GUI. ### reutilizando crashes para encontrar variantes `-e` ativa o modo de reutilização. Isso significa que, se algum crash for encontrado durante a execução do fuzzing, ele será usado como entrada para uma segunda rodada de fuzzing, o que pode ajudar a descobrir ainda mais bugs. Combine com `-z` para bugs `-ez`! Da-duph. O exemplo a seguir está fuzzing o antiword com 100.000 iterações e, em seguida, inicia outra execução com a mesma contagem de iterações e opções para reutilizar os crashes como entrada e tentar extrair ainda mais bugs. `litefuzz -l -c "antiword FUZZ" -i docs -n 100000 -ez` (ou pode-se copiar manualmente os crashes para um diretório de entrada para controlar diretamente as iterações da execução de reutilização) `litefuzz -l -c "antiword FUZZ" -i docs-crashes -n 500000 -z` nota: este modo é suportado apenas para aplicações locais. ### auxiliares de depuração de memória `-z` ativa o Electric Fence (ou glib malloc debugging como fallback) no Linux, Guard Malloc no Mac e PageHeap no Windows. Além disso, `-zz` pode ser usado para desabilitar o PageHeap após ativá-lo para uma aplicação. Se quiser apenas ativar/desativar sem iniciar o fuzzer, basta omitir a flag `-i`. Durante a instalação no Windows, o [gsudo](https://github.com/gerardog/gsudo) é instalado e pode ser usado para executar comandos elevados na linha de comando, como ativar o PageHeap para alvos. `sudo litefuzz -l -c "notepad FUZZ" -i texts/files -z` `sudo litefuzz -l -c "notepad FUZZ" -zz` No Linux, auxiliares específicos podem ser escolhidos. Por exemplo, em vez de apenas usar glib malloc como fallback, ele pode ser selecionado. `litefuzz -l -c "geany FUZZ" -i texts/codes -z glibc` O depurador de malloc padrão Electric Fence é ótimo, mas não funciona com todos os alvos. Você pode testar o alvo com EF e, se ele crashar, selecione o auxiliar glibc. ### verificando a saída ao vivo do alvo Se estiver fuzzing aplicações locais no Linux ou Mac, você pode usar `cat /tmp/litefuzz/RUN_ID/fuzz.out` para verificar qual foi a última saída stdout do alvo. `RUN_ID` é mostrado na área de informações STATS quando o fuzzing começa. No caso de um crash, o stdout também é capturado no diretório de crashes como o arquivo `.out`. O stdout/stderr global também vai para `/tmp/litefuzz/out` para fins de depuração para todos os alvos de fuzzing, com exceção dos modos insulated ou local server, cuja saída do depurador vai para `/tmp/litefuzz/RUN_ID/out`. O Winappdbg não suporta nativamente a captura de stdout de alvos (AFAIK), portanto este artefato não está disponível no Windows. ### modos cliente e servidor Se o servidor puder ser executado localmente simplesmente executando o binário (com ou sem flags e configuração), você pode passar sua linha de comando com `-c` e ele será iniciado, fuzzado e morto em uma nova execução a cada iteração. A ideia aqui é trocar velocidade pela capacidade de evitar aqueles bugs irritantes que são acionados apenas após a memória do alvo estar em um "certo estado", o que pode levar a falsos positivos. O mesmo vale para fuzzing local de clientes de rede. Ele suporta até conexões TLS, gerando certificados para você dinamicamente (permitir que o usuário forneça um certificado de cliente ao fuzzing um servidor que o exija e o fuzzing do próprio certificado são outras ideias aqui). O suporte de depuração não é fornecido pelo Litefuzz ao fuzzing clientes e servidores remotos, portanto a configuração na extremidade remota fica a cargo do usuário. Para servidores, simplesmente verificamos se o servidor parou de responder e registramos o payload anterior como o causador do crash. Isso funciona bem para conexões TCP, mas não temos esse luxo para serviços UDP, portanto o monitoramento do servidor remoto fica a cargo do recurso ReportCrash (disponível no Mac), da execução do alvo em um depurador (via modo local server ou manualmente) ou da criação de scripts de suporte personalizados. Além disso, alguns servidores podem reiniciar automaticamente ou se recuperar de outra forma após um crash, mas pode haver sinais disso nos logs ou outros artefatos no sistema de arquivos que podem ser analisados por scripts de suporte escritos para um alvo específico. ### exemplos de rede local `litefuzz -lk -c "wget http://localhost:8080" -a tcp://localhost:8080 -i input/http -z` `litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -z` `litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -o crashes/curl --tls -n 100000 -z` (abra o Wireshark e capture a resposta de a d, clique com o botão direito em Simple Network Management Protocol -> Export Packet Bytes -> resp.bin) `litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3` `litefuzz -ls -c "./sc_serv shoutcast.conf" -a localhost:8000 -i input/shouts -z` `litefuzz -ls -c "snmpd" -i input/snmp -a udp://localhost:161 -z` **notas rápidas** - Sockets UDP podem se comportar de forma um pouco estranha no Mac + Py2, portanto apenas Mac + Py3 foi testado e suportado - O fuzzing de clientes de rede local no Windows pode ser problemático e deve ser considerado experimental neste momento ### exemplos de rede remota Fuzzing de clientes e servidores remotos é um pouco mais desafiador: não temos depuração local e dependemos de detectar uma parada na interação entre as duas partes pela rede para capturar crashes. Além disso, como presumivelmente estamos cegos para o que está acontecendo na outra extremidade, o fuzzing termina quando o cliente ou servidor para de responder e precisa ser reiniciado manualmente após o cliente ou servidor ser restaurado a um estado normal (sem crash), a menos que o usuário tenha scripts configurados no lado remoto para gerenciar esse processo. O UDP complica ainda mais isso. Mesmo enviar um pacote de teste para ver se há um serviço ouvindo em uma porta UDP não garante uma resposta. Portanto, é possível fuzzar clientes e servidores de rede remotamente, mas há uma troca em termos de visibilidade. #### cliente `while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done` `litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -pp -n 100` O modo cliente é mais complicado aqui porque é difícil saber se um cliente realmente crashou e por isso não está reconectando, ou se a dança de envio/recebimento está apenas fora de sintonia, já que diferentes clientes podem lidar com conexões como quiserem. Observe também que isso é apenas um exemplo e que o fuzzing remoto de clientes por natureza é complicado e deve ser considerado um tanto experimental. #### servidor Os prós e contras de fuzzar um servidor localmente ou remotamente podem ajudá-lo a decidir como abordar um alvo quando ambas as opções estão disponíveis. Basicamente, fuzzar com o servidor em um depurador será mais lento, mas você conseguirá logs de crash com a triagem automática, enquanto fuzzar o servidor em modo remoto (mesmo apontando para o localhost) será muito mais rápido em média, mas você perde a alta visibilidade e as capacidades de triagem baseadas em depurador, mas ganha tempo para reiniciar manualmente o servidor após cada crash para continuar antes que ele saia (apenas servidores TCP, o recurso não suporta servidores baseados em UDP). **Shoutcast** `./sc_serv ...` `litefuzz -s -a localhost:8000 -i input/shouts -n 10000` **SSHesame** `sshesame` `litefuzz -s -a tcp://target:2022 -i input/ssh-server -p -n 1000000 -x 0.05` **FTP** `litefuzz -s -a tcp://target:21 -i input/ftp/req.txt -pp -n 1000` **DNS** `coredns -dns.port 10000` `litefuzz -ls -c "coredns -dns.port 10000" -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000` ou `litefuzz -s -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000` ##### TLS `litefuzz -s -a tcp://hostname:8080 -i input/http --tls -n 10000```` ... @ 48/10000 (1 crashes, 0 duplicates, ~7:13:18 remaining) [!] check target, sleeping for 60 seconds before attempting to continue fuzzing...

O fuzzer divide cada linha em sua própria resposta FTP para tentar fuzzar o tratamento de uma sessão por um cliente. Não há garantia, no entanto, de que um cliente irá "se comportar" ou agir de maneiras que não permitam que uma sessão termine corretamente, então um pouco de tentativa e erro + ajuste fino para casos de teste de sessão enquanto executa o Wireshark pode ser útil para entender as diferenças de interação entre os alvos. `litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z` Isso também pode ser combinado com *-u* para isolar alvos de rede GUI como FileZilla. `litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc` ### anexando a um processo Se o alvo cria um novo processo na conexão, é possível especificar o nome de um processo (ou pid) para anexar após a conexão ter sido estabelecida com o servidor. Isso é útil em casos onde, por exemplo, o launchd está ouvindo em uma porta e só inicia o processo de manipulação quando um cliente está conectado. Esta é uma característica que meio que borra a linha entre fuzzing local e remoto, pois tecnicamente o fuzzer está em modo remoto, mas especificamos o endereço alvo como localhost e pedimos para anexar a um processo. `./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000` nota: atualmente este recurso é suportado apenas no Mac (LLDB) e para fuzzing de rede, embora se implementado, deve funcionar bem para Linux (GDB) também. ### artefatos de crash Quando um crash é encontrado durante o fuzzing, ele é reproduzido em um depurador para produzir artefatos de depuração e informações de agrupamento. As informações variam de plataforma para plataforma, mas geralmente um arquivo de texto é produzido com um backtrace, informações de registradores, coisas do tipo `!exploitable` (quando disponível) e outras informações básicas. **Dumps de memória** podem ser ativados no Windows passando `--memdump` ou desativados com `--nomemdump`, semelhante a como depuradores malloc são controlados via `-z` e `-zz` respectivamente. Se ativado, o dump também será carregado no depurador de console (cdbg) e a saída da análise de crash `!analyze -v` é capturada em um log adicional de análise de crash do dump de memória. O Winappdbg já possui análise do tipo !exploitable que obtemos na análise inicial de crash, então apenas fazemos !analyze aqui. `litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump` ou para desativar dumps de memória para um aplicativo `litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump` Além da triagem automática de crash, diffs binários/string (conforme apropriado) e a saída padrão do alvo (dependente da plataforma/alvo) também são produzidos, além dos arquivos de reprodução, claro. Para fuzzing local, os artefatos geralmente incluem diffs, saída padrão (apenas linux/mac), arquivo de reprodução e o log de crash e arquivo de informações.``` $ ls crashes/latex PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.out PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.tex PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.txt

# troféus O Litefuzz encontrou crashes (falhas) em vários pacotes de software, como... * antiword * AppleScript (OS X) * ArangoDB VelocyPack * Avast authenticode-parser * Avast RetDec * BBC Audio Waveform * ColorSync (OS X) * Dynamsoft BarcodeReader * eot2ttf * evernote2md * faad2 * Facebook's Origami Studio * FontForge * ForestDB * Gifsicle * GPUJPEG * GPAC Multimedia Framework * Google Draco * Google Quipper * GoPro GPR * GtkRadiant * IIPImage Server * John The Ripper * Kyoto Cabinet * latex2rtf * libMeshb * libembroidery * libsndfile * Lion Vector Graphics (lvg) * L-SMASH * mp3-decoder * MindNode * minimp4 * MiniWeb Server * MLpack * Nvidia Data Center GPU Manager * Numbers (OS X) * OpenJPEG * OpenOrienteering Mapper * OSM Express * Pages (OS X) * PBRT-Parser * Pixar USD * Remote Apple Events (OS X) * Samsung rlottie * Samsung ThorVG * Shoutcast Server * Silo * syslog (OS X) * Tencent NCNN * TinyXML2 * UEFITool * Ulfius Web Framework * zlib # FAQ ## como surgiu este projeto? Fuzzing é divertido! E é bom fazer projetos que adotam uma visão contrária, de que os fuzzers nem sempre precisam seguir as abordagens modernas ou populares para atingir o objetivo final de encontrar bugs. Seja próximo ao hardware, obtendo cobertura de código em todos os caminhos ou simplesmente otimizando a abordagem rápida e flexível, a maneira fundamental de "invalidar suposições" de fazer as coisas, etc. Independentemente de como se manifesta, aproveite. ## este projeto é mantido ativamente? Por favor, não espere suporte ativo ou manutenção do projeto. Sinta-se à vontade para fazer um fork para adicionar novos recursos ou corrigir bugs, etc. Talvez até faça um PR para coisas menores, embora por favor não tenha expectativas de respostas ou solução de problemas. Não é pretendido que o desenvolvimento neste repositório seja ativo. ## como você sabe que o fuzzer está funcionando bem e você o mediu em relação a outros? O objetivo do Litefuzz é encontrar bugs em várias plataformas. E ele encontra. Então, honestamente, a capacidade de medi-lo contra fuzzerX ou fuzzerY simplesmente não foi priorizada. Certas compensações foram feitas e reconhecidas desde o início, veja [#intro](https://github.com/sec-tools/litefuzz/blob/main/README.md#intro) para mais detalhes. ## o que você mudaria se reescrevesse hoje? Ele funciona muito bem como está e foi testado em uma tonelada de alvos e cenários diferentes. Dito isso, poderia se beneficiar da padronização em um sistema mais modular e baseado em plugins, onde alternar entre alvos e plataformas não exigisse tantas verificações adicionais no lado operacional do código, etc. Claro, ter mais testes formais e um sistema de implantação que testasse em sistemas operacionais compatíveis criaria um ambiente mais fácil de trabalhar ao fazer alterações em funções principais. Ele cresceu de um projeto pequeno, mas ambicioso, para algo um pouco maior rapidamente. ## quão estável é o litefuzz? A linha de comando, a GUI, o fuzzing de rede (principalmente no Linux e Mac), a minimização, etc., foram bastante testados e devem ser bastante sólidos no geral. Alguns dos recursos mais exóticos, como fuzzing de rede GUI isolada, suporte ReportCrash para Mac e alguns outros recursos de nicho, devem ser considerados experimentais. ## existem cenários não suportados para o litefuzz? Alguns deles, sim. Mas a maioria são cenários incomuns que são problemáticos, exigem mais tempo e pesquisa para "acertar" ou simplesmente não funcionam por razões relacionadas à plataforma. Muitos deles saem explicitamente com uma mensagem "não suportado" quando você tenta executá-lo com essas opções, e algumas ressalvas foram mencionadas nas seções acima ao descrever vários recursos. Alguns dos mais matizados incluem: o modo de reprodução em aplicativos *isolados* não é suportado e também houve testes limitados em aplicativos Mac usando o recurso de isolamento; o Pyautogui parece funcionar bem no Linux e Windows, mas no Mac não se mostrou muito confiável, então considere-o funcionalmente não suportado; e o fuzzing de cliente no Windows pode ser um pouco menos confiável do que outros modos em outras plataformas. Pode haver alguns casos extremos aqui e ali, mas os cenários mais comuns de fuzzing local e de rede foram testados e estão funcionando. Ah, essas são as alegrias de escrever ferramentas multiplataforma: recompensador, mas é difícil fazer tudo funcionar bem o tempo todo. No geral, o fuzzing no Linux/Mac parece ser mais estável e suportar mais recursos no geral, especialmente porque teve muito mais testes de fuzzing de rede do que na plataforma Windows, mas foi feito um esforço para que pelo menos o básico estivesse disponível no Win32 com alguns extras. Sinta-se à vontade para fazer um fork deste fuzzer e fazer melhorias, suportar o atualmente não suportado, etc., ou PRs para coisas menores, mas úteis. ## que garantias são dadas para este projeto ou seu código? Absolutamente nenhuma. Mas é muito divertido fuzzar e vê-lo entregar bugs. ## autor / referências - [Jeremy Brown](https://github.com/sec-tools/litefuzz/blob/main/jbrown3264%5BNOSPAM%5Dgmail) - [Apresentação de slides para macOS Fuzzing](https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)

litefuzz

Mais Populares

introdução

exemplo docker

Create crashes directory

Run fuzzing with example input (1000 iterations with heap debugging)

notas

testes

testes unitários

ReportCrash

modos de múltipla troca de dados

golang

repros

remover arquivo

minimização

comando

exemplos

aplicativo local

visão rápida```

enumerando manipuladores de arquivos no OS X

client

quick look```

servidor local

servidor remoto

linha de comando```