Webfight - Automatizando a análise passiva de aplicações web

Conforme prometido, acabo de publicar os fontes da ferramenta que eu lancei na OWASP AppSec Latam deste ano. A ferramenta chamada WebFight é Open Source e pretendo ir incrementando e lançando novas atualizações de acordo com a minha necessidade e claro, espero a contribuição da comunidade.

A idéia

A WebFight nasceu da minha necessidade de lidar com um número grande de informações que uma aplicação web pode gerar. Como eu quero continuar analisando os detalhes de cada requisição e não adotar um web security scanner, decidi criar uma ferramenta que automatizasse a análise de um log de proxy. Assim eu continuo analisando os detalhes manualmente, mas ganhando muito tempo na análise do log.

A ferramenta

A idéia foi fazer um parser do log do Burp e a partir deste parser criar módulos para realizar as análises. A estrutura da ferramenta é resumida no fluxo a seguir:

A ferramenta é facilmente estendida criando módulos e as seguintes análises já estão implementadas:

• Apresenta todas as requisições e seus parâmetros para que sejam realizados testes fuzzing e de validação de dados


• Apresenta todos os status codes, possibilitando identificar erros 500; Redirects 30x; Conteúdo estático 0


• Apresenta as requisições fora do escopo da análise para identificar integrações, ou requests a outros domínios


• Realiza um fingerprint a partir da análise de headers e informações da aplicação


• Apresenta todos os cookies de sessão e a existência de cookies de sessão passados como parâmetro em requisições GET


• Cria PoC em arquivos html de todas as requisições com parâmetros para que seja testado CSRF


• Faz grep e identifica objetos DOM (password; hidden; file upload; iframe; etc...)


• Apresenta todos os comentários em client-side (HTML e javascript)


• Identifica arquivos javascript e javascripts no corpo da página apresentando o conteúdo com syntaxhighlight e realiza análise sintática no javascript apresentando Sink e Sources potencialmente perigosos


• Identifica arquivos swf; realiza download; desassembla o swf e faz grep buscando características potencialmente vulneráveis em flash


• Apresenta todas as respostas em JSON


• Apresenta todos as diretivas de cache nos headers Pragma e Cache-Control


• Apresenta as diretivas de segurança de headers CSP; HSTS e X-Frame-Options


• Apresenta o base64 do header authorization (autenticação básica de HTTP)

A Interface

A interface também facilita bastante a análise por classificar as análises e possibilita que se pesquise e filtre os registros apresentados.

Demo

 

Aguardo feedback e requisição de outras análises. Faça um clone do Git na página do Projeto e participe da lista de discussão.

A besta assusta, mas nem tudo está perdido

Na última Ekoparty foi apresentada uma técnica de exploração de uma falha antiga na configuração do SSL/TLS 1.0 via browser. O ataque foi identificado pelos pesquisadores Juliano Rizzo e Thai Duong e foi batizado como BEAST (Browser Exploit Against SSL/TLS).

A pesquisa foi brilhante e mostrou mais uma vez a destreza dos pesquisadores, mas assim como a outra pesquisa apresentada pela mesma dupla no ano passado: Padding Oracle Attack, gerou muita confusão e FUD na mídia. A do ano passado gerou pânico nos desavisados que achavam que o ataque era uma nova aterrorizante maneira de explorar banco de dados Oracle e a deste foi um prato cheio para a mídia, pois supostamente eles iriam derrubar um gigante da web o SSL. Além das fragilidades em algumas implementações eu aprendi com estes pesquisadores o poder de um bom título para palestras. Lembram das dicas de Jeremiah Grossman para ter um paper aprovados?

O ataque

Explorado em client-side, depende de alguma ação que irá fazer a vítima carregar um conteúdo malicioso em javascript que irá utilizar características do websocket do HTML5  ou outras técnicas de bypass para realizar requisições quebrando a SOP (Same-Origin Policy). O javascript irá explorar uma falha antiga no algoritmo CBC (Cipher Block Chaining) para conseguir decifrar em client-side o conteúdo cifrado pelo SSL/TLS 1.0. No blog do Thai Duong tem alguns detalhes sobre a pesquisa e um vídeo mostrando um PoC, também recomendo a leitura dos posts falando do Chrome e o Opera frente ao BEAST.

Porque o mundo não acabou com este ataque?

Ao contrário do que muita gente achava a falha não quebra o SSL/TLS, ele consegue via browser e um ataque client-side (esta vulnerabilidade no CBC já foi explorado em VPN) explorar uma fragilidade de configuração (porque você pode usar o RC4 como workaround para mitigar isto e muitos serviços já utilizam recursos contra esta fragilidade) e conseguir tornar viável a identificação do ID de sessão. Apesar de na teoria ser possível ter o conteúdo todo em texto claro, o poder computacional necessário é alto para isto, o que inviabiliza muitos ataques. Uma outra característica importante é que o usuário que for realizar o ataque precisa estar no mesmo segmento de rede da vítima, o que restringe bastante a superfície de ataque. Ai eu pergunto: se eu preciso estar no mesmo segmento, explorar uma falha client-side, porque não fazer algo mais fácil? Existem n ataques para sequestrar uma sessão e ferramentas "dummies" como BeEF e Firesheep. A pesquisa é fantástica, mas a aplicabilidade em ataques reais é contestável.

Alguns pesquisadores estão apresentando alternativas ao SSL/TLS, como o Convergence apresentado por Moxie Marlinspike's (lembra do SSLStrip?), mas recomendo manter a tranquilidade, consultar o TLS/SSL Hardening & Compatibility Report e o Cheat Sheet da OWASP para configurar adequadamente o seu ambiente e se manter protegido. Claro, até quando ninguém pode garantir.

Quando segurança também é melhor desempenho

Eu estava estudando as dicas de otimização de sites apresentadas na excelente palestra do Sérgio Lopes da Caelum e uma dica eu queria discutir aqui, afinal em avaliações de segurança de aplicações geralmente encontramos falhas de configurações associadas a Cookies.

A dica número 8: Diminua Cookies e Headers

Nesta dica ele apresenta uma referência que recomenda a separação de conteúdo estático do dinâmico e que no conteúdo estático não seja enviado Cookies.

Esta recomendação não só ajuda a melhorar o desempenho das páginas como pode evitar que seu Cookie seja interceptado em ataques contra a sessão da sua aplicação. É comum páginas configuradas para utilizar HTTPS possuírem objetos como imagens; javascripts; css; no seu conteúdo e estes arquivos estarem em diretórios onde não está configurado o HTTPS. Sendo assim mesmo uma página HTTPS pode deixar "vazar" os Cookies em requisições HTTP para carregar arquivos estáticos.

Para uma garantia a mais, recomendamos que sites com HTTPS insiram em seus Cookies a flag secure. E em breve será comum o uso do header HTTP HSTS (HTTP Strict Transport Security). Recomendo a leitura do guia da OWASP para TLS.

E sobre headers, alguma recomendação?

É muito comum os headers servirem como base para um mapeamento da aplicação, informando dados sobre o seu funcionamento, versão e tecnologia, portanto, valide se realmente são necessários estes headers, caso não sejam, retirando eles você aumenta o desempenho e não propaga informações que podem ajudar a comprometer a sua aplicação.

E agora que você pode usar a segurança como argumento para aumentar o desempenho, será que vai?

Apresentações

Ultimamente o meu blog está parecendo o Reclame Aqui, mas vou começar a divulgar algum conteúdo.

Para começar quero deixar um link para algumas palestras que eu e o time da Conviso realizamos em alguns eventos: http://www.conviso.com.br/recursos_pt/apresentacoes/

Em breve outros posts sobre segurança em aplicações.

O ecossistema de Segurança da Informação no Brasil

Que porcaria de título é este? Para falar sobre a babaquice do mercado de segurança brasileira, nada melhor do que usar um título clichê e "bonito". ;-)

Conversando com amigos frequentemente entramos em discussões sobre os profissionais e mercado de segurança no Brasil. Já surgiram várias visões:

A teoria de Darwin

Em poucas palavras: o sistema dirá quem é quem.

Eu discordo muito disto, pois o mercado se nivela por baixo. A grande maioria dos profissionais na minha opinião, não tem experiência e sequer tempo investido em estudo e aprendizado. Eles falam com eloquencia de assuntos e temas dos quais nunca colocaram em prática, apenas conhecem a teoria dos livros básicos. Ah claro, quero acreditar que eles leram algo e não apenas repetem clichês que ouviram em palestras.

Como o sistema irá aplicar a teoria de Darwin se o pareto é a favor deles?

 

Para ser um profissional de segurança da informação é relativamente simples, siga a cartilha do abotoadura. O mercado compra; os eventos aceitam e você ainda ganha um bom salário.

O especialista by Google

Hoje com poucos minutos você encontra artigos; apresentações e uma série de conteúdo sobre qualquer coisa. O especialista by Google é fera no Google Hacking em um dia de estudo ele é capaz de conduzir uma discussão com opiniões fortes e amplamente embasadas. ;-)

A internet é a ferramenta, mas só a prática e após muito quebrar a cabeça você será um especialista em algo. Não ache que você é um Jedi porque leu um post em um blog na internet.

O diferencial do brasileiro é ser generalista

Eu acho esta visão completamente absurda e mal entendida. Tudo bem o brasileiro ter uma maneira diferente de fazer as coisas, mas é completamente diferente de achar uma vantagem o encanador que conserta o seu equipamento eletrônico de última geração. Eu não consigo entender como um profissional pode ser um generalista em segurança da informação.

Os mais interessados perguntam: Mas qual área de segurança da informação você se dedica?

O gênio responde: Todas, inclusive aprendo rápido as novas que surgem. Sim, só um gênio para ser especialista em todas as áreas de segurança da informação.

Eu sempre procurei focar em um determinado assunto, aquele com o qual lido no meu dia-a-dia, foi assim com BCP e de alguns anos para cá a segurança em desenvolvimento. Eu ouço piadinhas sempre que dou mais uma palestra sobre web, é um tema que evolui muito, tem muitas tecnologias envolvidas e é o que eu sei fazer e estudo. ;-) Sempre terá um assunto que eu não domine e terei que estudar e muito provavelmente tentarei palestrar em algum lugar. ;-)

Esta é minha visão do mercado de segurança da informação no Brasil, completamente raso e com pouca especialização. Quem quer fazer diferente siga estudando e trabalhando, mas não espere que isto mudará, já esperei, mas hoje acho que isto não irá acontecer.

Adeus a certificação CBCP

Eu decidi não renovar a minha certificação CBCP (Certified Business Continuity Professional).

Por que dar adeus a uma certificação que você estudou para tirar e é muito fácil manter?

Primeiro quero justificar o porque foi difícil tirar esta certificação. Todas as certificações que eu tirei foram com experiência prática. Eu já atuava profissionalmente com o tema abordado na certificação e tirava a certificação para ter um requisito para muitos projetos que eu participava. Nunca estudei para uma certificação para buscar um emprego melhor ou ostentar uma sigla e um bonito broche.

Para a CBCP o processo foi ainda mais prazeroso, pois na época em que tirei a certificação não existia bons materiais de estudo e podíamos contar nos dedos os profissionais certificados.

Em Abril de 2006 eu recebi o e-mail com o resultado do estudo e um atestado para aqueles que necessitavam de um certificado para acreditar na capacidade de um profissional.


A facilidade para manter uma certificação

A maioria das certificações se quer pede algo para renovar, o profissional poderá manter a certificação no currículo sem necessidade de comprovar qualquer envolvimento com o tema.

As certificações mais elaboradas exigem a necessidade de acumular CPE um acrônimo em inglês para Educação Profissional Continuada. Para acumular pontos o profissional certificado deve escrever artigos; participar de eventos; fazer treinamentos; ou seja, se manter continuamente envolvido com o tema da certificação.

Algo complicado nisto? Quando eu vejo um profissional certificado choramingando por CPEs eu acho lamentável. Se você não está continuamente envolvido com o objetivo da certificação você não deve ser certificado.

Por este motivo eu irei abandonar o CBCP. Hoje eu não atuo mais com continuidade de negócios e não estou mais confortável em manter esta certificação.

Mesmo conseguindo atingir os CPEs com muita facilidade, não irei perder tempo precioso que pode ser investido em estudo e executando algo para preencher um formulário para manter uma sigla que eu já não tenho nenhum envolvimento.

Resumindo, ADEUS CBCP.

Wagner Elias, ex-CBCP