TLS 1.3

Estendendo o OWASP ZAP – Parte 1

Autor: Ailton Caetano, postado em 29/06/2017 as 15:30
Hashtags: #PenTest, #Desenvolvimento, #RedTeam

Quando realizamos análises de segurança, encontramos os mais diversos tipos de aplicações web, desde as empacotadas com sua configuração padrão até as personalizadas e as desenvolvidas in-house. Nesse ínterim, podem acontecer as mais diferentes integrações e transformações de dados, o que torna impossível a criação de uma ferramenta capaz de reconhecer todas as coisas estranhas que se pode encontrar.

Nestes casos, ferramentas open source são primordiais para facilitar o trabalho do analista, já que elas permitem quaisquer modificações necessárias ao seu código-fonte para a adaptação às particularidades da aplicação, sem que este precise escrever uma ferramenta nova partindo do zero.

Nesta série de artigos, falaremos sobre a possibilidade de mudanças no comportamento do OWASP ZAP através de uma interface de scripts que nos permite, inclusive, a adição de novas verificações de vulnerabilidades e o desenvolvimento de provas de conceito (PoC).

O Zed Attack Proxy (ZAP) permite o uso de scripts escritos em qualquer linguagem que dê suporte à JSR 223. Para isto, é necessário instalar o add-on “Script Console” e o add-on relativo à linguagem que se pretende utilizar na criação do script. A única exceção é Javascript, já suportada sem a necessidade de um add-on adicional. Atualmente existem add-ons para as linguagens Zest, Groovy, Python e Ruby. Para efeito deste artigo, é necessário instalar o add-on “Python scripting” pois será esta a linguagem em que faremos nossos exemplos. Também é preciso que o leitor possua noções básicas de programação para compreender o assunto abordado nesta série de postagens.

Aba Scripts

aba de scripts do zap

Esta aba mostra todos os scripts disponíveis em uma árvore. Os nós superiores “Scripts” e “Templates” mostram os scripts e os modelos existentes, respectivamente. Note que os scripts possuem uma marcação verde ou vermelha em seus ícones. Eles simbolizam o estado atual do script, informando se o mesmo está habilitado ou não para execução.

No topo da aba existem botões que permitem o carregar, salvar e criar scripts. Também é possível criar scripts utilizando o botão direito do mouse sobre cada tipo.

Tipos de Scripts

  • Active Rules
  • Executados como parte do Active Scanner e podem ser habilitados individualmente.
  • API
  • Criados para utilização em tarefas executadas no modo “Headless” (sem GUI).
  • Authentication
  • Scripts que podem ser invocados para autenticação dentro de um contexto. Para usar, é preciso selecionar o script desejado quando estiver configurando o “método de autenticação por script”.
  • Fuzzer Http Processor
  • Podem acessar e modificar as requisições e respostas HTTP, controlando o processo de fuzzing e interagindo com a interface gráfica.
  • Fuzzer Websocket Processor
  • Podem acessar e modificar as mensagens Websocket, controlando o processo de fuzzing e interagindo com a interface gráfica.
  • Http Sender
  • São executados durante o funcionamento geral do ZAP, mudando cada requisição e resposta e podem ser habilitados individualmente. Eles são invocados para requisições que passam pelo proxy e requisições que são originadas no próprio ZAP, como o módulo Active Scanner e/ou o módulo Spider.
  • Passive
  • Estes scripts são executados como parte do Passive Scanner e também podem ser habilitados individualmente.
  • Payload Generator
  • Empregados para gerar payloads a serem usados no fuzzer.
  • Payload Processor
  • Podem modificar os payloads antes de serem utilizados pelo fuzzer.
  • Proxy
  • São executados durante o funcionamento geral do ZAP, mudando cada requisição e resposta. Podem ativar breakpoints e podem ser habilitados individualmente. Diferente dos scripts do tipo “Http Sender”, não são invocados para requisições que são originadas pelo ZAP, como o Active Scanner e o Spider.
  • Sequence
  • Definem uma sequência de requisições para a realização de uma tarefa específica na aplicação. Devem ser implementados na linguagem Zest e são utilizados pelo add-on opcional “Sequence”.
  • Standalone
  • Scripts com maior autonomia, somente sendo executados de forma manual pelo usuário. Possuem maior poder que os outros tipos de script, já que não estão restritos às invocações da ferramenta, deixando o usuário livre para implementar novas funcionalidades ou alterar seu comportamento, podendo até mesmo criar telas e interações com o mouse.
  • Targeted
  • Só podem ser invocados pelo usuário e com uma URL alvo. Um exemplo seria a seleção de uma opção de um menu exibido por um clique do botão direito nas abas Histórico ou Sites.
  • Script Input Vector (Variant)
  • Estes podem definir novos vetores para a inserção de dados. São utilizados pelo Active Scanner.

Script console:

script console do zap

Quando um script é selecionado, ele é imediatamente mostrado na aba “Script Console”. Aqui é possível editar os scripts que desejar, exceto quando a linguagem em uso for Zest. Nesse caso, o script será exibido graficamente na própria aba “Scripts”.

No topo desta aba podemos ver os botões para “Executar” o script ou “Parar”, que fica habilitado caso ele esteja em execução. É importante notar que nem todos os scripts podem ser executados desta forma. Há tipos que só serão executados dentro de componentes do ZAP. Por exemplo, scripts do tipo Active Rules só serão executados dentro do Active Scanner.

Abaixo da janela para edição de scripts existem botões para controlar a saída dos scripts na área que fica imediatamente abaixo.

Mãos à obra

Em nosso primeiro exemplo, utilizaremos o tipo de script mais abrangente, o HttpSender. Como vimos na descrição dos tipos, ele está presente nas requisições que passam pelo proxy e nas que são originadas pelo próprio ZAP.

Geralmente o fluxo de execução funciona em um sistema de origem e sumidouro das informações, ou seja, o ZAP faz uma chamada a um nome de função fixo passando parâmetros definidos e quando uma resposta é necessária, essa mesma função a retorna para a ferramenta, deixando o que acontece com as informações nesse ínterim a cargo do analista. Por este motivo, teremos que utilizar o nome esperado na função de entrada de nosso script, ficando livres depois disso.

HttpSender

Neste tipo, o ZAP faz uma chamada a uma função de nome “sendingRequest(msg, initiator, helper)” sempre que houver uma requisição, e uma chamada a uma função de nome “responseReceived(msg, initiator, helper)” sempre que houver uma resposta. Note que existe diferença no uso de maiúsculas e minúsculas nestas chamadas, então certifique-se de ter digitado corretamente, ou surgirá um erro “java.lang.reflect.UndeclaredThrowableException”.

Um exemplo simples é a adição de cabeçalhos a uma requisição e à sua resposta. Os dois scripts abaixo mostram como fazer isso.

Cada script adiciona um cabeçalho baseado em uma váriavel, que contém os cabeçalhos desejados, às mensagens HTTP. No primeiro caso, os cabeçalhos são adicionados no momento da requisição, e no segundo exemplo, os cabeçalhos desejados são adicionados à resposta HTTP.


adição de cabeçalhos à requisição
Adição de cabeçalhos à requisição

adição de cabeçalhos à resposta
Adição de cabeçalhos à resposta

Ao executar o segundo script, será mostrado o código html da página web carregada, pois o navegador passou a interpretá-lo como texto puro. Isso porque o script informou ao navegador, através do cabeçalho inserido, que o mime-type do conteúdo é “text/plain”.

Caso a resposta à requisição fosse uma imagem ou outro arquivo para download, o navegador tentaria exibir os bytes do arquivo convertidos em caracteres imprimíveis, o que pode auxiliar o analista a notar diferenças neste arquivo em testes de injeção de dados. Caso tenha interesse em copiar os exemplos, ambos estão no repositório oficial.

Estes são exemplos simples, mas que servem como introdução às muitas possibilidades desta ferramenta.

Em breve continuaremos com outros exemplos e explicação sobre outros tipos uso dos scripts do ZAP.