cisco-talos/mutiny-fuzzerFuzzer de protocolo de rede que reproduz tráfego PCAP através de um motor de mutação (Radamsa) para descobrir rapidamente vulnerabilidades em hosts alvo por meio de processadores e monitores de mensagens personalizáveis.
Postagem do blog aqui:
Links para demonstração em vídeo do YouTube:
Para mais recursos voltados para campanhas de fuzzing/feedback/harnesses:
O Mutiny Fuzzing Framework é um fuzzer de rede que opera reproduzindo PCAPs através de um fuzzer mutacional. O objetivo é iniciar o fuzzing de rede o mais rápido possível, à custa de ser completo.
O fluxo de trabalho geral do Mutiny é capturar uma amostra de tráfego legítimo, como uma requisição de navegador, e alimentá-la em um script de preparação para gerar um arquivo .fuzzer. Então, o Mutiny pode ser executado com este arquivo .fuzzer para gerar tráfego contra um host alvo, mutando os pacotes que o usuário desejar.
Existem extensões que permitem alterar como o Mutiny se comporta, incluindo alterar mensagens com base em entrada/saída, alterar como o Mutiny responde a erros de rede e monitorar o alvo em uma thread separada.
Mutiny usa Radamsa para realizar mutações.
O Decept Proxy é um proxy de rede multiuso que pode encaminhar tráfego de uma conexão de socket TCP/UDP/domínio em texto simples ou TLS para uma conexão de socket TCP/UDP/domínio em texto simples ou TLS, entre outros recursos. É um bom companheiro para o Mutiny, pois pode tanto gerar arquivos .fuzzer diretamente, especialmente útil ao fuzzear conexões TLS, quanto permitir que o Mutiny se comunique com hosts TLS.
sample_apps dão uma ideia básica de algumas coisas que podem ser feitas com o fuzzer, com alguns aplicativos/clientes diferentes para testar.
Escrito por James Spadaro ([email protected]) e Lilith Wyatt ([email protected])
Certifique-se de que python e scapy estão instalados.
Descompacte o Radamsa e make (Você não precisa executar make install, a menos que queira ele em /usr/bin - usará o Radamsa local) Atualize mutiny.py com o caminho para o Radamsa se você o alterou.
Salve o pcap em uma pasta. Execute mutiny_prep.py no <XYZ>.pcap (opcionalmente, passe também o diretório de um processador personalizado, se houver, mais abaixo). Responda às perguntas, obtenha um arquivo <XYZ>.fuzzer na mesma pasta do pcap.
Execute mutiny.py <XYZ>.fuzzer <targetIP>. Isso iniciará o fuzzing. Os logs serão salvos na mesma pasta, no diretório <XYZ>_logs/<time_of_session>/<seed_number>.
Os arquivos .fuzzer são legíveis por humanos e comentados. Eles permitem alterar várias opções por arquivo .fuzzer, incluindo qual mensagem ou partes da mensagem são fuzzeadas.
Dentro de um arquivo .fuzzer estão os conteúdos das mensagens. São simplesmente linhas que começam com 'inbound' ou 'outbound', indicando a direção da mensagem. Elas estão no formato de string Python, com '\xYY' sendo usado para caracteres não imprimíveis. São geradas automaticamente por 'mutiny_prep.py' e Decept, mas às vezes precisam ser modificadas manualmente.
Se uma mensagem tem a palavra-chave 'fuzz' após 'outbound', isso indica que deve ser fuzzeada através do Radamsa. Uma determinada mensagem pode ter continuações de linha, basta colocar mais dados da mensagem entre aspas em uma nova linha. Nesse caso, esta segunda linha será mesclada com a primeira.
Alternativamente, a palavra-chave 'sub' pode ser usada para indicar um subcomponente. Isso permite especificar um componente separado da mensagem, para fuzzear apenas certas partes e por conveniência dentro de um Processador de Mensagens.
Aqui está um exemplo arbitrário de conjunto de dados de mensagem:
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
Isso fará com que o Mutiny transmita say hi and fuzz this but not this(0xdeadbeef). 0xdeadbeef será transmitido como 4 bytes hex. and fuzz this será passado pelo Radamsa para fuzzing, mas say hi e but not this(0xdeadbeef) serão deixados intactos.
O Mutiny aguardará uma resposta do servidor após transmitir a única mensagem acima, devido à linha 'inbound'. A resposta esperada do servidor é this is the server's expected response. O Mutiny não fará muito com esses dados, além de verificar se o que o servidor realmente enviou corresponde a essa string. Se ocorrer uma falha, o Mutiny registrará tanto a saída esperada do servidor quanto o que o servidor realmente respondeu.
mutiny_classes/ contém classes base para o Processador de Mensagens, Monitor e Processador de Exceção. Qualquer um desses arquivos pode ser copiado para a mesma pasta do .fuzzer (por padrão) ou para uma subpasta separada especificada como 'processor_dir' dentro do arquivo .fuzzer.
Essas três classes permitem armazenar respostas do servidor e alterar mensagens de saída, monitorar o alvo em uma thread separada e alterar como o Mutiny lida com exceções.
O Processador de Mensagens define vários callbacks que são chamados durante uma execução de fuzzing. Dentro desses callbacks, qualquer código Python pode ser executado. Anecdoticamente, eles são usados principalmente de três maneiras.
O mais comum é quando o servidor envia tokens que precisam ser adicionados a futuras mensagens de saída. Por exemplo, se a primeira mensagem do Mutiny faz login, e o servidor responde com um ID de sessão, o callback postReceiveProcess() pode ser usado para armazenar esse ID de sessão. Então, em preSendProcess(), os dados de saída podem ser ajustados com esse ID de sessão. Um exemplo disso está em sample_apps/session_server.
Outro uso comum de um Processador de Mensagens é limitar ou alterar uma mensagem fuzzeada. Por exemplo, se o servidor sempre descarta mensagens maiores que 1000 bytes, pode não valer a pena enviar mensagens grandes. preSendProcess() pode ser usado para encurtar mensagens após fuzzing, mas antes de serem enviadas, ou para lançar uma exceção.
Levantar uma exceção traz à tona a maneira final como os Processadores de Mensagens são comumente usados. Dentro de um callback, quaisquer exceções personalizadas definidas em mutiny_classes/mutiny_exceptions.py podem ser levantadas. Existem várias exceções, todas comentadas, que causarão vários comportamentos do Mutiny. Geralmente envolvem registrar, tentar novamente ou abortar a execução atual.
O Monitor tem uma função monitorTarget() que é executada em uma thread separada do fuzzer principal do Mutiny. O objetivo é permitir a implementação de um processo de longa duração que possa monitorar um host de alguma forma. Isso pode ser qualquer coisa que possa ser feita em Python, como comunicar-se com um daemon de monitoramento em execução no alvo, ler um arquivo longo, ou até mesmo pingar o host repetidamente, dependendo dos requisitos da sessão de fuzzing.
Se o Monitor detectar uma falha, ele pode chamar signalMain() a qualquer momento. Isso sinalizará para a thread principal do Mutiny que ocorreu uma falha, e ele registrará a falha. Esta função geralmente deve operar em um loop infinito, pois retornar fará com que a thread termine, e ela não será reiniciada.
O Processador de Exceção determina o que o Mutiny deve fazer com uma determinada exceção durante uma sessão de fuzzing. No sentido mais geral, a função processException() traduzirá exceções de nível Python e de SO em ações de tratamento de erro do Mutiny da melhor forma possível.
Por exemplo, se o Mutiny receber 'Connection Refused', a resposta padrão é assumir que o servidor alvo morreu de forma irreversível, então o Mutiny registrará a execução anterior e parará. Isso é verdade na maioria dos casos, mas esse comportamento pode ser alterado para o de qualquer uma das exceções em mutiny_classes/mutiny_exceptions.py conforme necessário, permitindo a adaptação da detecção de falhas e correção de erros.