TLS 1.3

Estendendo o OWASP ZAP – Parte 2

Autor: Ailton Caetano, postado em 13/09/2017 as 12:00
Hashtags: #PenTest, #Desenvolvimento, #RedTeam

Continuando nossa série de postagens sobre como estender funcionalidades no OWASP ZAP, nesta edição abordaremos a construção de payloads personalizados em tempo de execução.


xkcd fuzzing 1137
XKCD 1137

Na postagem anterior vimos os diferentes tipos de script e fizemos o equivalente ao nosso “helloworld”. Hoje veremos como implementar nosso próprio gerador de payloads para ser utilizado em uma sessão de fuzzing. Precisaremos instalar o addon AdvFuzzer.

Quando realizamos análises, há situações em que payloads prontos não servem aos nossos propósitos e precisamos realizar algum tipo de tratamento. Existem também os casos em que um determinado campo tem seu valor associado a outro, resultando em uma requisição inválida e erro caso isso não aconteça. Para evitar desperdiçar requisições e tempo, devemos definir e realizar a adequação necessária, podendo empregar para este fim o tipo “payload generator”.

Funções:

Aqui usaremos 5 funções pré-definidas: getNumberOfPayloads, next, hasNext, reset e close.

getNumberOfPayloads: Deve retornar o número de payloads gerados, utilizando-se o 0 (zero) para indicar um número desconhecido. Este valor é usado no cálculo de progresso dos testes.

next: Retorna o próximo payload gerado. Este método é chamado enquanto hasNext retornar True.

hasNext: Retorna True caso ainda existam payloads a serem gerados. Do contrário, deve retornar False.

reset: Reinicia o estado interno do gerador de payloads, como se não houvesse chamadas anteriores a next() ou hasNext(). Geralmente é chamada quando hasNext() retorna False e payloads ainda são requeridos.

close: Libera recursos utilizados na geração de payloads (como um arquivo). Chamado quando o gerador de payloads não é mais necessário.

Cenário:

Digamos que a aplicação precise receber um nome de usuário em um campo e que outro deva receber o hash SHA1 do mesmo valor após ser convertido para Base64 (SHA-1, Whirlpool, estruturas personalizadas, etc). Então temos um campo query = “Teste” e outro campo, o campo de validação, com check = SHA1(Base64(“Teste”)).

query 02
Requisição com campo de validação

O código para testes no lado servidor foi feito em NodeJS e segue abaixo.

codigoweb 01
Código no lado servidor

A questão aqui é que existe um (ou mais) campo(s) que depende(m) do valor atual da etapa de fuzzing. O OWASP ZAP, nativamente, permite apenas o uso de payloads independentes, ou seja, se definirmos mais de 1 local para receber os payloads, os testes serão feitos de forma independente. Caso definíssemos dois campos diferentes com 5 payloads cada, ele faria uma permutação simples de 25 testes, gerando requisições inúteis, pois sabemos que 24 delas serão rejeitadas pela aplicação. A saída é selecionarmos os dois valores conforme a seleção feita abaixo.

query 03
Nosso fuzzer deve preencher todo o trecho selecionado

A solução consiste em gerar o payload inicial, concatená-lo com a string “&check=” e depois concatenar a parte dependente no final de tudo. Teremos um payload final assim:

“<payload>&check=<campo_dependente_do_payload>”

Para isso, criaremos o seguinte script do tipo Payload Generator:

payload generator 01
Script para gerar os payloads necessários

Criado o script, agora precisamos habilitar seu uso na aba “Scripts”, no ramo “Payload Generator”.

enable script 01
Habilite o script criado

Agora crie a sessão de fuzzing e selecione o script no menu dropdown:

fuzzing 01
Criando a sessão de testes

fuzzing 02
Clique nos botões para adicionar o payload

fuzzing 03
Selecione o tipo e o script que acabamos de criar

Clique nos botões “Adicionar” e “OK” para adicionar o payload à configuração do fuzzer. Na parte superior da janela existem também as abas “Opções” e “Processadores de mensagens”. A primeira é usada para mudar a estratégia de geração dos payloads quando temos campos independentes e para alterar configurações como quantidade de requisições simultâneas e atraso entre requisições.

Na outra aba selecionamos operações a serem executadas na mensagem http, seja na requisição ou na resposta. Aqui é possível adicionar scripts do tipo “Fuzzer HTTP Processor”.

Uma vez terminada a seleção do payload, clique no botão para iniciar os testes e vá para a aba “Fuzzer”.

fuzzed requests 01
A aba “Fuzzer” contém os resultados da sessão de testes

Com nosso trabalho concluído, obtivemos um script que consegue emular o ataque “Battering Ram” do Burp, com a vantagem de evitar a necessidade de criação da wordlist para campo de validação antes do uso.

Caso tenha interesse em copiar o exemplo, ele está no repositório oficial da comunidade.

Dúvidas? Entre em contato conosco através do endereço info@3elos.com.br