Mostrando postagens com marcador Testes de Segurança. Mostrar todas as postagens
Mostrando postagens com marcador Testes de Segurança. Mostrar todas as postagens

quarta-feira, 25 de março de 2015

Entenda as diferenças entre testes de aplicações dinâmicos e estáticos

No cenário atual onde vulnerabilidades e vazamentos de dados rotineiramente são notícia, as empresas devem prestar atenção especial aos seus processos de desenvolvimento de software, incorporando boas práticas de segurança em todas as suas etapas — especialmente no ponto focal deste artigo: o teste dinâmico de aplicação e o teste estático de código de software.


As análises estáticas e dinâmicas são os dois tipos mais populares de abordagem para garantia de qualidade do software — vamos usar os termos "teste" e "análise" de maneira intercambiável nesse artigo, exceto quando houver algum ponto mais específico. Esses procedimentos devem ser antecedidos por um desenvolvimento carregado de boas práticas de segurança, pois teste algum é capaz de imunizar o software contra programação pobremente executada. Os testes devem ser considerados investimentos no software, já que mobilizam profissionais e recursos, e portanto devem ser gerenciados com atenção.

terça-feira, 15 de julho de 2014

Você sabe qual a diferença entre crowdtest e teste de segurança completo?

Para você que está buscando a melhor solução para segurança do seu software, seja enquanto produto ou mesmo como sistema de apoio para sua empresa, é importante conhecer diferentes ferramentas que estão disponíveis no mercado.




Duas formas bastante utilizadas por desenvolvedores são o Crowdtest e o Teste de Segurança Completo. No entanto, antes de saber qual dos modelos de análise é o mais adequado para a sua empresa, é preciso entender como cada um funciona.

segunda-feira, 19 de novembro de 2012

Um pouco sobre teste de parâmetros em aplicações web


 Introdução

Neste artigo vamos abordar testes em entradas de dados em uma aplicação web. Durante o artigo teremos uma explanação de como algumas ferramentas funcionam para testar sua aplicação web.

Quando falamos de testes em entradas de aplicações Web, muitos pensam em TDD (Test Driven Development), logo alguns iram citar até o Selenium. Embora o Selenium tenha poder para nos ajudar, o uso do browser seria na maioria dos casos inútil. Lembre-se que nosso foco é testar entradas para verificar existência de padrões nas respostas, julgando a segurança da aplicação e não a funcionalidade de uma aplicação.


Ferramentas

Embora seja interessante reinventar a roda por motivos de aprendizado ou otimização, temos em nosso alcance um grande número de ferramentas que podem ajudar nos testes.

Uma das ferramentas disponíveis é o Burp Suite, com ele poderíamos usar o intruder, para alterar os valores dos parâmetros de uma request HTTP e analisar a resposta buscando por padrões que são característicos de uma aplicação vulnerável.

Além do Burp, temos scanner de vulnerabilidades como o Skipfish e Arachni que fazem a tarefa de mapeamento do alvo bem como um "sitemap", ou seja, é feita a abstração de todas as URLs do alvo de forma recursiva,  e analisado os dados para identificar uso de entradas e, de forma automática, é feito um teste nas entradas encontradas.

Reinventando a roda, mas por um bom motivo

Pensando no aprendizado apresento a vocês o 0d1n, uma ferramenta para testar entradas em aplicações web. Essa aplicação possui código fonte simples por ter poucas funções, e usa libCurl pela praticidade para executar uma request e obter  a resposta.

Supondo que você use algum derivado de unix siga os seguintes passos:

 $ wget http://0d1n.googlecode.com/files/0d1n_stable_v9.zip
 $ unzip -e 0d1n_stable_v9.zip; cd 0d1nstable
 $ make

lembrando que você precisa da "libCurl", caso esteja em um linux derivado de debian, por exemplo, basta o seguinte comando para instalar:

 $ apt-get install libcurl-dev

Estamos preparados para usar o programa conforme a Figura 1.

 $ ./0d1n

Figura 1


Como usar a ferramenta


O caractere “!” é um indicador de onde você deseja injetar os valores que estão na sua lista de payloads.

Exemplo:

site.com/site.jsp?login=admin&pass=!

Neste caso o programa irá trocar todos os “!” por strings que estão presentes em uma determinada lista(chamamos de lista de payloads), enviaria um "request" e procuraria determinadas strings que estão em "response2find". Se contiver qualquer string do "response2find" será salvo em um log o "response".

Outro exemplo:

http://site.com/index.jsp?var=1&feijoada=3
http://site.com/index.jsp?var=!&feijoada=!

Logo se a primeira linha da lista de payloads for ” or 1=1” nosso programa irá executar:
site.com/index.jsp?var= or 1=1&conviso=3

Para testar parâmetros POST usamos o argumento -P e o argumento -h seria o local onde receberia o POST.

Exemplo:

-h ‘http://site.com/index.jsp ‘ –P ‘var=!&var2=!&var3=teste’

Prova de Conceito

Para testar a ferramenta vamos usar o DVWA. Com o DVWA rodando vamos alterar o Security Level para Low no menu Security Level.

Antes, precisamos do Cookie da sessão do DVWA, pois para explorar o XSS preciamos estar autenticado na aplicação. Portanto logue no sistema e salve o “cookie jar”. Para isso podemos usar o plugin Export Cookie do firefox.

Tendo o Cookie da sessão em mãos definimos um alvo. Agora vamos explorar um reflected XSS na url  http://localhost/dvwa/vulnerabilities/xss_r  executando o seguinte comando:

$ ./0d1n -h ‘http://localhost/dvwa/vulnerabilities/xss_r/?name=!‘ -p payloads/list.txt -f response2find/find.txt -c cookies_dvwa.txt -o dvwa

Para analisar o resultado abrimos o arquivo "tables/hammer.html".


Nas linhas da tabela da Figura 2 podemos ver o padrão que buscamos no conteúdo da página e clicando nela podemos identificar uma requisição onde o payload XSS foi executado e demonstra que a aplicação é vulnerável a XSS conforme a Figura 3.

Figura 2 

Figura 3

Um pouco sobre o código fonte

Com uso simples de "sockets" podemos nos comunicar usando protocolo HTTP, automatizando o envio de entradas e analise das respostas.

Vamos analisar o código fonte do programa em "spider.c" (linha 46) onde é feito a  construção da request com libCurl usando macros para setopt.

// injeta payload
    make=payload_injector( (POST?arg[4]:arg[0]),line,old);
    curl = curl_easy_init();
    curl_easy_setopt(curl,  CURLOPT_URL, POST?arg[0]:make);
// caso seja post
     if(POST)
      curl_easy_setopt(curl, CURLOPT_POSTFIELDS, make);
// escreve o "response" na memória
    curl_easy_setopt(curl,  CURLOPT_WRITEFUNCTION, WriteMemoryCallback);
    curl_easy_setopt(curl,  CURLOPT_WRITEDATA, (void *)&chunk);
// caso seja definido useragent
    if(arg[6]!=NULL)
    {
     curl_easy_setopt(curl,  CURLOPT_USERAGENT, arg[6]);
    } else {
     curl_easy_setopt(curl,  CURLOPT_USERAGENT, "Mozilla/5.0 (0d1n v0.1) ");
    }
 // para comprimir os dados e ganhar desempenho
    curl_easy_setopt(curl,  CURLOPT_ENCODING,"gzip,deflate");
// caso queira usar cookiejar
    if(arg[3]!=NULL)
    {
     curl_easy_setopt(curl,CURLOPT_COOKIEFILE,arg[3]);
     curl_easy_setopt(curl,CURLOPT_COOKIEJAR,arg[3]);
    } else {
     curl_easy_setopt(curl,CURLOPT_COOKIEJAR,"odin_cookiejar.txt");
    }
    curl_easy_setopt(curl,CURLOPT_FOLLOWLOCATION,1);
//caso queira carregar um certificado
    if(arg[7]!=NULL)
    {
     curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);
     curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 2);
     curl_easy_setopt(curl, CURLOPT_CAINFO, arg[7]);
    } else {
     curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,0);

Na linha 104, temos uma busca pela string de "response2find/*" dentro do response, repare que não usamos a função strstr(), e sim bitap, que procura uma substring aproximada a de um determinado padrão.

if(chunk.memory && bitap_search(chunk.memory,line2))

Conclusão

Concluímos então que com a simplicidade dessa ferramenta, podemos facilmente entender o funcionamento de um teste de entradas de uma aplicação de web, ver as etapas do teste de forma transparente. 


Autor do Post

Antonio Costa "Cooler_" é desenvolvedor em ASM,C,Common Lisp,Perl e outras linguagens, foi um dos escritores da e-zine cogumelo binário,é um dos fundadores do grupo de estudo e pesquisa BugSec, já palestrou em alguns eventos como OWASP,YSTS e Bsides, Nas suas horas livres gosta de tomar todynho e colecionar gibis, brinca com microcontroladores AVR e eletrônica, apesar de ser perna de pau nunca recusa uma boa pelada dia de domingo.

quarta-feira, 8 de setembro de 2010

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

  2. Fuzzgrind: an automatic fuzzing tool

  3. Tarantula: Easy Fuzz Testing for Rails Apps

  4. Webslayer

  5. RFuzz The Web Destroyer

  6. Powerfuzzer

  7. Burp Intruder

  8. SPIKE Proxy

  9. !exploitable Crash Analyzer

  10. Crash Analysis with BitBlaze

  11. Automated Whitebox Fuzz Testing

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

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