Suas aplicações são seguras?

Conheça a Conviso!

Sobre as limitações do fuzzing black-box em Aplicações Web

Este artigo está também disponível para leitura on-line no Scribd.

por Gabriel Quadros | Conviso Security Labs

O fuzzing é um dos métodos mais usados para a descoberta de vulnerabilidades em aplicações, tendo como principais características sua eficiência e bom custo-benefício em relação à outros métodos. Apesar disso, os fuzzers geralmente têm dificuldades para encontrar vulnerabilidades que não estão localizadas na “superfície” da aplicação.

Atualmente existem vários fuzzers para aplicações Web, tanto comerciais quanto Open Source. Eles podem ser do tipo white-box, quando requerem acesso ao código fonte da aplicação para guiar o teste [3], ou black-box, quando o código fonte da aplicação não é utilizado [4-8]. Os fuzzers black-box para aplicações Web, além de sofrerem das mesmas limitações inerentes a qualquer um deste tipo, têm que lidar com um ambiente mais restrito que, entre outras coisas, não fornece acesso nem ao código nativo ou bytecode da aplicação.

Quando contratadas para realizar um teste de penetração em uma aplicação Web, dificilmente as empresas de segurança recebem o código fonte da aplicação que será testada. Isso mostra a importância do desenvolvimento de ferramentas para auxiliar na descoberta de vulnerabilidades em testes do tipo black-box.

Este artigo descreve algumas limitações do fuzzing black-box de aplicações Web e busca provocar uma reflexão sobre formas de melhorar esse tipo de teste.

Como funcionam as ferramentas que fazem esse tipo de fuzzing?

Os fuzzers black-box de aplicações Web operam sobre requisições HTTP. Cada elemento de uma requisição GET, POST, etc pode ser modificado na tentativa de descobrir alguma vulnerabilidade na aplicação-alvo [1]. A análise dos resultados é feita em cima das respostas retornadas pelo servidor, onde geralmente é usado um conjunto de expressões regulares para identificar a ocorrência de palavras-chave que caracterizam a vulnerabilidade sendo testada ou alguma função hash para comparar essas respostas.

Diferenças entre o fuzzing black-box de aplicações Web e Desktop

O fuzzing black-box de aplicações Web tem uma grande desvantagem em relação ao de aplicações Desktop, que é a impossibilidade de acesso ao código server-side da aplicação. Esse código nunca é disponibilizado para os usuários, exceto quando alguma vulnerabilidade descoberta na aplicação permite o download de qualquer arquivo do servidor. O acesso ao código da aplicação favoreceria a utilização de várias técnicas de teste de software, que vão da análise da cobertura do código obtida com a execução de um caso de teste, até algoritmos para a geração de casos de teste com maior probabilidade de detectar vulnerabilidades.

Já no fuzzing black-box de aplicações Desktop, é sempre possível analisar o código nativo ou bytecode do executável, o que permite uma conversão para o fuzzing white-box dada a capacidade de se realizar análises sobre esse tipo de código. Com isso, consegue-se aplicar várias técnicas para obter uma melhor cobertura do código da aplicação, como a Execução Simbólica, que têm sido bastante utilizada em pesquisas acadêmicas [11-13] e em algumas ferramentas comerciais ou Open Source [2].

Outra grande desvantagem está relacionada com a forma como os casos de teste bem-sucedidos são detectados. Nas aplicações Desktop, isso geralmente é feito com o monitoramento da aplicação-alvo por meio de depuradores para identificar a ocorrência de exceções, tais como violações de acesso ao ler ou escrever dados em uma certa posição na memória. Algumas ferramentas mais sofisticadas também são usadas, como o plugin !exploitable [9] do WinDBG e soluções que usam Taint Analysis para detectar se dados oriundos do usuário são usados nas instruções que causaram a exceção [10].

No fuzzing de aplicações Web, essa detecção é feita com base nas respostas para as requisições retornadas pelo servidor [1]. Os cabeçalhos HTTP, o conteúdo da resposta e até mesmo outros parâmetros como o tempo decorrido entre o envio da requisição e o recebimento da resposta são analisados na procura por indícios que revelem a presença de alguma vulnerabilidade.

Outra diferença é que a entrada que será enviada para a aplicação Web geralmente precisa trafegar pela Internet e isso aumenta o tempo necessário para se realizar o fuzzing. Já no fuzzing de aplicações Desktop, o teste é feito localmente, em geral.

Conclusões

Apesar do fuzzing ser uma técnica eficiente para a identificação de vulnerabilidades, não é difícil perceber que as técnicas utilizadas pela maioria das ferramentas hoje deixam passar uma grande quantidade de vulnerabilidades. Precisamos de ferramentas que tragam melhores resultados. Assim, a grande questão é: “Como melhorar as ferramentas existentes para o fuzzing black-box de aplicações Web?”

Levando em consideração os resultados das pesquisas acadêmicas e as ferramentas disponíveis para o público em geral, a resposta para essa pergunta pode não ser fácil. O que sabemos é que é preciso melhorar a forma como geramos os casos de teste e analisamos as respostas para as requisições.

Além disso, muito do que era feito com código server-side há algum tempo atrás, hoje está sendo feito através de código client-side como JavaScript e Flash. Essa mudança provocada pela Web 2.0 possibilita que, agora, uma parte significativa do código fonte total da aplicação esteja disponível para a execução de fuzzing white-box.

Sobre o Autor

Gabriel Quadros começou a estudar segurança da informação em 2003, com interesse principal em engenharia reversa, pesquisa de vulnerabilidades e desenvolvimento de exploits. Atualmente cursa o último ano do Bacharelado em Ciência da Computação na Universidade Estadual do Sudoeste da Bahia – UESB e atua na Conviso IT Security como pesquisador do Conviso Security Labs. Pode ser contatado pelo e-mail gquadros@conviso.com.br.

Referências

 

    1. Playing Web Fuzzing

 

    1. Fuzzgrind: an automatic fuzzing tool

 

    1. Tarantula: Easy Fuzz Testing for Rails Apps

 

    1. Webslayer

 

    1. RFuzz The Web Destroyer

 

    1. Powerfuzzer

 

    1. Burp Intruder

 

    1. SPIKE Proxy

 

    1. !exploitable Crash Analyzer

 

    1. Crash Analysis with BitBlaze

 

    1. Automated Whitebox Fuzz Testing

 

    1. Klee: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs

 

    1. EXE: A System for Automatically Generating Inputs of Death Using Symbolic Execution

 

Originalmente postado no Blog da Conviso Application Security – Siga-nos no Twitter @conviso Google+

Tags

Deixe um comentário

topo
%d blogueiros gostam disto: