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

Palestra na H2HC

Enquanto eu não atualizo o blog, segue slides e vídeos da minha palestra no H2HC 2010.

http://www.conviso.com.br/html5-seguro-ou-inseguro/

Estou escrevendo alguns posts para o blog e tenho escrito bastante no blog da Conviso: http://www.conviso.com.br/category/blog/

[OFF-Topic] Problemas em faturas da TIM

Eu peço desculpa pelo off-topic, mas eu quero saber se mais pessoas estão com o mesmo problema. Meus problemas com a TIM começaram no ano passado, quando meu celular simplesmente parou de funcionar e acusava que o SIM Card era inválido.

Ao entrar em contato com a central de atendimento fui informado que meu CHIP estava com problema e eu precisava ir até uma loja TIM para trocá-lo. Após várias visitas em lojas TIM eu descobri que não era problema do CHIP e sim que meu aparelho havia sido cancelado por falta de pagamento. Sim! Meu telefone foi cancelado por falta de pagamento e eu não sabia. Em uma loja da TIM a atendente retirou as faturas em atraso. Apareceram várias contas com valores irrisórios, algumas com 1 centavo, isto mesmo, 1 centavo. No total as contas totalizavam menos de R$ 30,00. O detalhe é que eu não sabia destes valores e as contas eram de anos anteriores, isto mesmo, as contas eram de anos anteriores e o meu telefone funcionava normalmente e eu não sabia que devia.

Descoberto o problema, paguei os valores e pasmem, ainda tinha mais carroço-nesse-angu. Apareceram mais coisas, não acusaram outros pagamentos. Para resolver eu tinha que pagar valores que chegavam a aproximadamente R$ 150,00. Paguei os valores e finalmente eu não devia mais nada a TIM.

Bom, agora eu religo meu telefone e problema resolvido. NÃO! Os problemas só começaram! A central de atendimento dizia que meu telefone havia sido cancelado e que eu tinha perdido meu número. Após muitas discussões, reclamações em todos os canais possíveis e 2 meses depois eu consegui religar o meu número antigo.

E a saga continua! Na primeira fatura um susto, um valor assustador tarifando internet e uma multa de R$ 400,00 pelo religamento da linha. Lá vou eu percorrer todos os canais de atendimento da TIM. Após várias reclamações eu consegui que eles revisasem os valores da fatura pois o meu plano tinha internet ilimitada e eu não pagaria uma multa para religar uma linha se eles é que erraram e cancelaram meu celular indevidamente.

Problema resolvido eu tinha meu número e tudo ia muito bem. De repente a uns meses atrás surgiram novas contas com valores altos, cobrando acesso a internet. Lá vou eu contestar as contas novamente, pois o que eu devia de internet era R$ 89,00 referente a um plano ilimitado de internet. Após muitas reclamações e o telefone novamente cancelado por falta de pagamento, a TIM resolve começar a resolver meu problema. Mas sinceramente eu não confio mais, afinal, olha ai as contas que teimam em surgir de anos anteriores, inclusive uma de 1 centavo.
-------------------
Senhor Wagner, referente ao
protocolo de atendimento nº 2010161893074;

 Primeiramente
pedimos desculpas pelo ocorrido;

Em resposta ao seu e-mail, após verificações em
protocolos finalizados recentemente, localizamos o protocolo 20101350244874,
que tratava-se de contestação de valores de cobranças de serviços Tim connect Fast
e Tim Wap Fast, A fatura com vencimento em 04/08/2010 tinha o valor de R$ 3.294,95,
o valor atualizado para pagamento é de R$ 481,04, abaixo a numeração do código
de barras para o pagamento a menor:

84630000004-5 81040109080-0 00046587709-0 00775286999-5

Informamos os valores e vencimentos das faturas em aberto:

FATURA 04/03/2009 R$
0,01
FATURA 04/11/2008 R$
9,67
FATURA 04/12/2008 R$
52,75
FATURA 07/10/2010 R$
50,38
FATURA 04/01/2009 R$
1,94
FATURA 04/08/2010 R$
481,04

Total: R$ 595,79

Estamos a sua
disposição através deste canal com um novo registro no site www.tim.com.br

Agradecemos por
utilizar o canal Fale com a Tim

Atenciosamente,

Central de Relacionamento
com clientes
Sonia
www.tim.com.br

Por favor, não responda a esta mensagem,
estamos à sua disposição através deste mesmo
canal Fale com a Tim.

-------------------------------------------------------------

Nome: WAGNER ELIAS
CPF/CNPJ: xxxxxx
Telefone: 11xxxx
E-Mail: xxxx
Estado: SP
Tipo: RECLAMAÇÃO
Assunto: ATENDIMENTO
Mensagem: Boa noite. Eu tenho
algumas reclamações abertas há mais de 5 dias úteis e não tive nenhuma
resposta. Eu continuo com o meu problema e a TIM adotou o silêncio como
resposta. Aguardo uma solução. Grato

-------------------

Além do transtorno de ter que ficar brigando com a TIM e ficar sem meu número que é conhecido por meus amigos e clientes, ainda tenho que ouvir piadas, passar por constrangimentos, porque parece que eu não pago minha conta de telefone. Por isto a idéia de escrever esse post e ver se pessoas também passam pelo mesmo problema ou eu sou premiado.

Quem teve ou tem problemas semelhantes com a TIM, por favor deixem um comentário.

Abs.

OSSTMM e ISO/IEC 15.408 dois problemas que nós mesmos criamos

Como assim problemas? OSSTMM é a metodologia referência para Penetration Test e a ISO/IEC 15.408 é a referência para segurança em desenvolvimento de software.

MENTIRA!

Mas como, se muitos profissionais da área afirmam que este é o caminho? Exatamente por isto que eu credito este problema a nós mesmos profissionais que atuamos na área.

Hoje a maioria dos clientes coloca como critério para projetos de segurança em desenvolvimento a aderência a ISO/IEC 15408 e para Penetration Test a utilização de alguma metodologia como OSSTMM. Colocam porque durante anos os profissionais pregaram e divulgaram tais informações. O pior, na grande maioria das vezes quem divulga nunca aplicou e muitas vezes se quer conhece o padrão. Muitos profissionais amparam todo o seu discurso, argumentos em chavões, mentiras ditas tantas vezes que acabam virando verdade.

Por que OSSTMM não é referência para Penetration Test?

O primeiro grande desafio é ter o documento completo, a OSSTMM está em desenvolvimento há anos e nunca se teve conhecimento de toda metodologia, abordagem proposta. Todo o desenvolvimento é baseado em puro marketing, mesmo pagando a taxa pelo suposto método completo, ele sempre está incompleto e em desenvolvimento. E vou falar, eles sofrem de um problema sério de falta de produtividade, este cenário permanece por anos.

Bom, vamos falar da parte que existe. A documentação não apresenta fases que sejam viáveis para um Penetration Test, ele apresenta um número grande de coisas que devem ser analisadas e não passa disto. Um outro ponto que é difícil de se implementar na prática é uma abordagem quantitativa chamada rav. Esta abordagem prevê que seja analisado os controles e pontuado de acordo com um critério que, após o cálculo usando a fórmula apresentada, irá determinar uma pontuação ao ambiente. De acordo com a pontuação o ambiente é considerado mais ou menos seguro.

Abordagem quantitativas são a eterna busca de gestores na área de tecnologia, busca louvável, mas em Penetration Test isto é ineficaz e inútil. Sim, o propósito de um Penetration Test é identificar fragilidades que possam levar ao comprometimento do ambiente e não ser uma análise de riscos. A análise do Penetration Test irá apresentar uma análise qualitativa e servirá como uma das n variáveis de uma análise de riscos quantitativa. Está análise irá determinar qual o controle deve ou não ser implementado de acordo com o risco associado ao ambiente e o custo envolvido na solução versus o impacto que pode causar no ambiente.

Resumindo, OSSTMM não pode servir de referência para realização de um Penetration Test. O profissional que executa estes projetos com freqüência desenvolve seu próprio método levando em consideração as características do mercado que atua e a necessidade de organizar e apresentar os resultados esperados pelo cliente. Já escrevi algumas idéias sobre metodologia em Penetration Test e também recomendo a leitura do documento SP 800-115 (Thecnical Guide to Security Testing) do NIST.

Por que a ISO/IEC 15.408 não é referência para segurança em desenvolvimento?

Existem vários motivos que levam ao entendimento claro de que a ISO/IEC 15.408 ou Commom Criteria não é para segurança em desenvolvimento, mas o Geraldo Fonseca no Twitter deu uma descrição breve e que para mim é perfeita:

"@gfonseca_  @welias  cc/15408 é framework de avaliação, não de desenvolvimento. É para avaliar o "fato consumado", e não para ajudar a criar algo seguro."

É exatamente isto, ela não propõe ou valida nenhum método para se conseguir chegar ao desenvolvimento de um código seguro. Ela apresenta apenas alguns critérios que um produto de software deve ter para que possa ser acreditado por laboratórios credenciados. Define características que um software deve ter. Mas como eu chego lá? Procuro lá na ISO/IEC 15.408 e me diz.

Bom, se você leu pode responder que ela não apresenta nada disto. Para se conseguir um software seguro é preciso ter um processo maduro e implementar práticas de segurança em código, testes e principalmente um trabalho de conscientização e treinamento dos profissionais envolvidos. 

Um post do Fernando Cima comenta sobre o relatório "State of the Art of Software Security Assurance" do Departamento de Defesa americano e o papel da ISO/IEC 15.408. Eu também escrevi um artigo para revista da ISSA.

Não que eu queira jogar uma bomba de fumaça, mas é necessário orientar as pessoas, pesquise neste cara aqui e verifique se você encontra alguma referência internacional que associe o uso da ISO/IEC 15.408 como base para desenvolvimento seguro.

Pesquisou? Pois é, não encontrou nada.

Agora procura em português. Bingo! Existem várias citações a ISO/IEC 15.408 para desenvolvimento seguro. Este "fenômeno" eu credito a este livro: SEGURANÇA NO DESENVOLVIMENTO DE SOFTWARE

Mas o propósito do livro é claro: Como desenvolver sistemas seguros e AVALIAR A SEGURANÇA DE APLICAÇÕES DESENVOLVIDAS COM BASE NA ISO 15.408

Ah! Ai é outra história! A maioria das pessoas virá especialista apenas lendo a capa de um livro, ou no melhor dos casos, fazendo como o Pateta do Walt Disney que lê o início e o fim do livro.

Inimigos do Código Seguro

Estou lendo o livro: Innocent Code - A Security Wake-Up Call for Web Programmers! O Livro é antigo, de 2004, mas eu ainda não havia tido a oportunidade de ler.

O que me chamou a atenção no livro é que ao invés de tentar apresentar trechos de códigos, técnicas de secure coding ele apresenta idéias e tópicos que todo programador deve levar em consideração.

E uma coisa que gostei foram alguns pontos que ele apresenta como inimigos do Secure Code:

Ignorance

Isto mesmo, ele apresenta a ignorância como um dos inimigos da segurança de código. Eu acredito nisto! A grande maioria dos desenvolveres cometem erros de segurança por desconhecimento. Ele desenvolve um bom código, que funciona, mas que tem uma falha de segurança. Mas um bom código pode ser inseguro? Sim! Ele pode inserir falhas de arquitetura, privacidade mesmo desenvolvendo um código de excelente qualidade.

Por este motivo é fundamental que seja disponibilizado material de estudo e um trabalho de conscientização constante.

Mess

Exatamente, muitos ambientes de desenvolvimento são uma verdadeira bagunça. Os desenvolvedores não adotam nenhuma prática de teste, integração contínua e algumas vezes nem o básico, como controle de versão.

O desenvolvimento de código de qualidade e seguro depende da adoção de práticas de desenvolvimento e organização. Eu já escrevi sobre Bug Tracking e incluo como uma excelente prática a adoção de ferramentas que implementem o processo de integração contínua.

Deadlines

Prazos são um problema sério em desenvolvimento de software e isto naturalmente afeta a segurança. Com a definição de prazos apertados o planejamento, análise e inspeção de código é deixado de lado e entra em cena as soluções mirabolantes e a popular POG (Programação Orientada a Gambiarra) ou a XGH (eXtreme Go Horse) que tem como principal característica:

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

Salesmen

Vendedores, sempre eles. Vendem o que não podem entregar e depois o desenvolvedor precisa desenvolver um sistema ruim para atingir prazos e orçamentos. E sem contar aquelas features que são um atentado a segurança, mas precisam estar disponíveis pois foram vendidas ao cliente.

São pontos bem comuns, mas que afetam e muito o desenvolvimento de um bom código.

Minha participação no Stay Safe Podcast

O Stay Safe Podcast é um podcast sobre segurança da informação produzido por Thiago Bordini e Jordan Bonagura. Fui convidado por eles para bater um papo e a edição já está disponível.

Aqui está disponível a edição que eu participei:
http://www.staysafepodcast.com.br/?p=184

Quero agradecer a oportunidade e quem quiser dar seu feedback, só deixar um comentário.

Chamada de trabalhos - OWASP AppSec Brasil 2010

Começou o Call for Papers do OWASP AppSec Brasil 2010, veja abaixo a reprodução da chamada em  português.

APPSEC BRASIL 2010

CHAMADA DE TRABALHOS

O OWASP (Open Web Application Security Project) solicita propostas de apresentações para a conferência AppSec Brasil 2010, que ocorrerá na Fundação CPqD em Campinas, SP, de 16 a 19 de novembro de 2010. Haverá mini-cursos nos dias 16 e 17, seguidos de sessões plenárias de trilha única nos dias 18 e 19 de novembro de 2010.

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 aplicaçõ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.

Para submeter uma proposta, preencha o formulário disponível em http://www.owasp.org/images/6/68/OWASP_AppSec_Brasil_2010_CFP%28pt-br%29.rtf.zip, que deve ser enviado através da página da conferência no site Easychair: http://www.easychair.org/conferences/?conf=appsecbr2010

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 é 17 de agosto de 2010 às 23:59, horário de Brasília.
• A notificação de aceitação ocorrerá até o dia 8 de setembro de 2010.
• A versão final das apresentações deverá ser enviada até o dia 30 de setembro de 2010.

A comissão organizadora da conferência pode ser contactada pelo e-mail: organizacao2010@appsecbrasil.org

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

• Página da conferência: http://www.owasp.org/index.php/AppSec_Brasil_2010_(pt-br)
• OWASP Speaker Agreement (em inglês): http://www.owasp.org/index.php/Speaker_Agreement
• Página do OWASP: http://www.owasp.org
• Página da conferência no Easychair: http://www.easychair.org/conferences/?conf=appsecbr2010
• Formulário para apresentação de propostas: http://www.owasp.org/images/f/f7/OWASP_AppSec_Brasil_2010_CFP.rtf.zip

ATENÇÃO: Não serão aceitas propostas sem TODAS as informações solicitadas no formulário

Favor divulgar a todos os possíveis interessados.

O Óbvio Ululante

"O trágico da nossa época ou, melhor dizendo, do Brasil atual, é que o idiota mudou até fisicamente. Não faz apenas o curso primário, como no passado. Estuda, forma-se, lê, sabe. Põe os melhores ternos, as melhores gravatas, os sapatos mais impecáveis. Nas recepções do Itamaraty, as casacas vestem os idiotas. E mais: – eles têm as melhores mulheres e usam mais condecorações do que um arquiduque austríaco."

Nelson Rodrigues - O Óbvio Ululante - 1968

Muitos já pensaram logo: é, ele ficou louco de vez, citando Nelson Rodrigues em um blog de segurança da informação. Não, é apenas o que eu acho sobre a mais óbvia das citações feitas por 8 entre 10 profissionais de segurança da informação.

Mas que citação é esta?

"O elo mais fraco são as pessoas"

Sem contar as variações que citadas por abotoaduras que são mestres em falar o Mesmo-do-Mesmo com tamanha destreza que faz milhares de pessoas o seguirem como se fosse algo digno de um grande mestre.

Sim, falar que pessoas são a parte mais difícil de tratar quando se pensa em segurança da informação é o Óbvio Ululante, afinal em toda ciência que envolva pessoas isto será sempre assim.

Se isto é óbvio por que a maioria dos profissionais baseiam todo seu discurso nesta citação óbvia?

Simples, por ser a verdadeira bomba de fumaça. É aquela mesma que os ninjas usam para desaparecer sem deixar vestígios.

Falando que o problema são as pessoas exime o profissional de pesquisar e discorrer sobre temas que exigem bastante envolvimento e maturação para que se façam entendivel ao ser humano. É fácil dizer que as pessoas não respeitam uma política, mesmo quando ela é mal feita e descabida. Difícil é desenvolver e implementar uma política que seja de senso comum e que as pessoas entendam sua importância e que as pratiquem sem dificuldades.

Por isto você profissional que está iniciando ou já atua em segurança da informação, fuja desta, busque respostas e não engula o óbvio ululante.

Slides da Apresentação no GTS 15 2010 - Explorando falhas em aplicações em Flash

Na última edição do GTS eu tive a oportunidade de fazer uma apresentação sobre as falhas comuns em aplicações desenvolvidas em Flash. Aproveitem os slides e fiquem a vontade para comentar e trocar informações.

Encontrando falhas em aplicações web baseadas em flash

View more presentations from Conviso IT Security.

OWASP AppSec Brasil 2010 - Chamada de Mini Cursos

**APPSEC BRASIL 2010**

**CHAMADA DE MINI-CURSOS**

O OWASP (Open Web Application Security Project) solicita propostas de apresentações para a conferência AppSec Brasil 2010, que ocorrerá na Fundação CPqD em Campinas, SP, de 16 a 19 de novembro de 2010. Haverá mini-cursos nos dias 16 e 17, seguidos de sessões plenárias de trilha única nos dias 18 e 19 de novembro de 2010.

Buscamos pessoas e organizações que queiram ministrar mini-cursos sobre segurança de aplicações. 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 aplicaçõ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.

Para submeter uma proposta, preencha o formulário disponível em
http://www.owasp.org/images/4/43/OWASP_AppSec_Brasil_2010_CFT%28pt-br%29.rtf.zip,
que deve ser enviado por email para organizacao2010@appsecbrasil.org.

Cada mini-curso poderá ter 1 ou 2 dias (8 horas por dia) de duração e deverão estar em conformidade com as regras definidas pelo OWASP em seu "Speaker Agreement". A conferência pagará aos instrutores pelo menos 30% do fatuamente de seus mini-cursos. Cursos que consigam atrair mais que o número mínimo de alunos poderão receber percentagens
maiores (mais detalhes abaixo). Não haverá qualquer outro tipo de remuneração (passagens, hospedagem, etc) para os apresentadores ou autores dos mini-cursos. Caso seja necessário um arranjo diferente, favor entrar em contacto com o comitê organizador pelo email abaixo.

**Remuneração**
Os instrutores e autores dos cursos serão remunerados conforme a quantidade de alunos. Se o curso atrair apenas o número mínimo de alunos, a remuneração será 30% do faturamento. Para cada 10 alunos a mais, a remuneração será acrescida de 5% do faturamento, até um máximo
de 45% do faturamento do curso. Por exemplo, para um curso de 1 dia para uma turma de 10 a 19 alunos, os instrutores e autores receberão 30% do faturamento do curso. Para turmas entre 20 e 29 alunos, a remuneração sobe para 35% do faturamento e assim sucessivamente.

Em casos excepcionais, poderá ser acordado um esquema diferente para remuneração dos instrutores. Possíveis interessados devem entrar em contacto com a comissão organizadora pelo email organizacao2010@appsecbrasil.org

**Valores das inscrições**
Cursos de 1 dia: R$ 450 por aluno
Cursos de 2 días: R$ 900 por aluno

**Mínimo de alunos**
10 alunos para cursos de 1 dia
20 alunos para cursos de 2 dias

**Datas importantes:**
A data limite para apresentação de propostas é 26 de julho de 2010 às 23:59, horário de Brasília.
A notificação de aceitação ocorrerá até o dia 16 de agosto de 2010.
A versão final do material dos mini-cursos deverá ser enviada até o dia 15 de setembro de 2010.

A comissão organizadora da conferência pode ser contactada pelo e-mail: organizacao2010@appsecbrasil.org

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

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

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

Página do OWASP: http://www.owasp.org

Página da conferência no Easychair: http://www.easychair.org/conferences/?conf=appsecbr2010

Formulário para apresentação de propostas: http://www.owasp.org/images/4/43/OWASP_AppSec_Brasil_2010_CFT%28pt-br%29.rtf.zip

********* ATENÇÃO: Não serão aceitas propostas sem TODAS as informações solicitadas no formulário *********

Favor divulgar a todos os possíveis interessados.
______________________________

_________________
Owasp-brazilian mailing list
Owasp-brazilian@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-brazilian

Palestra no GTS 15

No próximo dia 14 de Maio estarei palestrando no GTS! O evento é realizado pelo Grupo de Trabalho em Segurança de Redes, do CGI.Br e é gratuito.

A palestra irá acontecer as 14 hrs. Irei apresentar as principais falhas e técnicas para correções em aplicações baseadas em Adobe Flash.

Mais informações sobre o evento podem ser conferidas aqui: https://gts.nic.br/reunioes/gts-15

Aguardo vocês lá!

Versão 5 do SDL (Microsoft Security Development Lifecycle)

Acaba de ser lançado uma nova versão do guia da microsoft para implementação de um processo de segurança em desenvolvimento. Neste post do blog do SDL você pode ter mais detalhes das alterações e aqui baixar o arquivo.

O que eu mais gostei de ver no guide foram algum pontos que sempre mencionamos em análises e que geralmente não são tratados por desenvolvedores:

Página 23 - Strong log-out and session management

Proper session handling is one of the most important parts of Web application security. At the most fundamental level, sessions must be initiated, managed, and terminated in a secure manner. If a product employs an authenticated session, it must begin as an encrypted authentication event to avoid session fixation.

•    A session identifier/token must never be transmitted via the URL to avoid side-jacking via the referrer header or browser history.
•    All session data must be maintained on the server, not the client, to avoid tampering.
•    Sessions must be completely terminated on the server side via logout and timeout mechanisms. When multiple sessions are tied to a single authentication event, all of the sessions tied to that event must be terminated by logout/time-out.
The following items must be met as part of the exit criteria for this recommendation:
•    When multiple sessions are tied to a single user identity, they must be collectively terminated on the server side at timeout or logout.
•    Authentication events must invalidate unauthenticated sessions and create a new session identifier.
•    Logout functionality is available on every page.
•    Session state, outside of a single identifier, is maintained on the server and not accepted from the user (including via cookie or header).
•    Session tokens are not present in the URI.
•    Timeout functionality is present and timeout thresholds are documented along with the rationale.

Página 28 - Avoid EXEC in stored procedures

Using stored procedures helps to mitigate the SQL injection threat to a great extent since type checking is available for parameters. If the attacker supplies input that does not match the type constraints, the stored procedure will throw an exception. In the vast majority of the cases, this exception should be properly handled within the application.
However, if the stored procedures perform string manipulation in their code and then execute that query using the "exec @sql" construct, incorrect handling of user input can produce the same SQL injection vulnerability as would be seen at the application layer.

EXEC and EXECUTE are prohibited in T-SQL stored procedures except in the case where they are used to call other stored procedures. Using EXEC to call ad-hoc SQL is not allowed. For example, the following is allowed:

EXEC('MyStoredProc')

But the following is prohibited:

EXEC('SELECT * FROM Foo')

Note that there are some situations in which it is impossible to write a parameterized T-SQL query. For instance, you cannot specify table names or column names as parameters. Similarly you cannot parameterize the operands of some operators, such as the IN operator.
If your product falls into one of these situations or any other case in which you believe the only reasonable option is to use EXEC with ad-hoc SQL, investigate an alternative design or implement appropriate escaping logic to mitigate SQL injection attacks.

Exit criteria for this requirement is that stored procedures contain no calls to EXEC or EXECUTE (except for calls to EXEC other stored procedures).

Página 32 - HTTPOnly Cookies

To mitigate the risk of information disclosure with a cross-site scripting attack, a new attribute was introduced to cookies for Internet Explorer 6 SP1 and is now in use in all current browsers. This attribute specifies that a cookie is not accessible through script. By using HTTP-only cookies, a Web application reduces the possibility that sensitive information contained in the cookie can be stolen via script. Watcher, a Web security testing tool, can help you meet this recommendation.
All HTTP-based applications that use cookies must specify HttpOnly in the cookie definition for all cookies not explicitly required by legitimate scripts in the Web page. For example:

Set-Cookie: USER=123; expires=Wednesday, 10-Feb-2010 23:12:40 GMT; HttpOnly"

Página 33 - ClickJacking defense

For each page that could contain user controllable content, you should use a "frame-breaker" script and include the HTTP response header named X-FRAME-OPTIONS in each authenticated page. The Watcher tool may be of use in meeting this recommendation. The exit criteria for this recommendation is as follows:

1. A "frame-breaker" script is included in each authenticated page to prevent unintentionally framing.

2. The X-FRAME-OPTIONS header has been added to all authenticated page HTTP responses that should not be framed (for example, DENY) or is utilized to only allow trusted sites to frame site content (for example, the current site with the use of SAMEORIGIN).

Se em versões anteriores algumas pessoas criticavam por não atender claramente as características de aplicação web, a cada nova versão este cenário vem sendo melhorado.

Cursos no YSTS 4.0

Mais conhecida pela organização do evento You Sh0t the Sheriff (YSTS), a STS Produções está ofertando uma série de treinamentos em Segurança da Informação, através de criteriosa seleção do conteúdo e dos instrutores.

Estarei ministrando os cursos que estão sendo ofertados em parceria com o Conviso Security Labs. Confira aqui os detalhes e não perca a oportunidade de aprendizado e networking.

O uso de ferramentas de Bug Tracker no tratamento de vulnerabilidades

Ao implementar processos de desenvolvimento seguro, geralmente nos deparamos com problemas considerados pelo senso comum como básicos e essenciais para a produção de software, o que é o caso da ausência de uma ferramenta de bug tracker. Neste post, descrevo a implementação de uma ferramenta destinada a preencher este ponto e customizada para auxiliar o processo de gestão e correção de vulnerabilidades em softwares.

A ferramenta escolhida é o Mantis (http://www.mantisbt.org/), uma vez que é de fácil customização e instalação, porém qualquer outro produto que possa ser utilizado no processo de bug tracking e possibilite a criação de campos customizados pode ser adotada no mesmo princípio.

Características do Mantis

O Mantis é uma terramenta Open Source desenvolvida em PHP e que tem suporte a diversos bancos de dados, tais como MySQL e Postgres, além de contar com recursos completos para suportar o processo de gestão na correção de problemas encontrados no processo de desenvolvimento de software.

Instalando o Mantis

Para a instalação do Mantis as etapas abaixo apresentadas devem ser cumpridas de forma seqüencial:

1. Execute o download do pacote de instalação à partir do endereço http://www.mantisbt.org/download.php.
2. Descompacte este pacote no diretório de publicação que será utilizado no Servidor de Aplicação.
3. Acesse a URL do web site publicado.
4. Na tela de configuração apresentada, informe os parâmetros referentes ao banco de dados que será utilizado e execute a instalação seguindo as instruções que serão fornecidas.
5. Configure o servidor de e-mail que será utilizado pelo Mantis no arquivo: config_defaults_inc.php que será instalado no diretório raiz do web site.

Com estas configurações o Mantis estará funcionando e pronto para ser utilizado, porém para garantir a aplicação de alguns protocolos de segurança adicionais, sugiro que sejam cumpridos os pontos abaixo apresentados:

1. Apague o diretório admin do diretório raiz do site.
2. Crie um novo usuário e apague o usuário padrão administrator, cuja senha padrão é root. :-)
3. No arquivo config_defaults_inc.php altere a diretiva “$g_allow_signup = ON” para OFF, uma vez que assim será removida a possibilidade de solicitação do usuário que aparece como padrão na página de acesso.

Dica: O funcionamento do Mantis depende muito do envio de e-mails, inclusive para os processos de criação e validação dos usuários, não esqueça de configurar um smtp para suportar esta finalidade e caso você precise testar o processo localmente, uma uma boa pedida é o Papercut que simula o envio e recebimento de e-mail no seu computador.

Customizando o Mantis para suportar um processo de gestão de vulnerabilidade

1 – A primeira etapa é criar as tags para definir qual o tracker será utilizado. No menu, escolha a opção Manager=>Manage Tags e crie as tags:

• Bug
• Feature
• Support
• Vulnerability
• Security Service

2 – Em seguida, é necessário definir os campos personalizados, o que é realizado pela escolha da opção Manager=>Manage Custom Fields no menu, seguida da criação dos campos personalizados abaixo relacionados, onde os campos “lista” e “texto” são obrigatórios:

• Security Impact – Booleano
• Compliance Impact – Booleano
• Privacy Impact – Booleano
• Vulnerability Category – Lista
• Identified By – Lista
• Identification Method – Lista
• Identification Method Source – Lista
• Report – Texto
• Requested Security Activity - Lista

Conteúdo dos Campos Lista

1 - Vulnerability Category:

• Authentication
• Authorization
• Input Validation
• Output Encoding
• Error Handling
• Session Management
• Logging

2 - Identified By:

• Development Team
• Security Team
• Third Party Assessor
• Client
• External Researcher
• Attacker
• Operations Team

3 - Identification Method:

• Code Review
• Penetration Testing
• Architecture Review
• Design Review
• Other

4 - Identification Method Source:

• Automated Tool
• Human
• Unknown

5 - Requested Security Activity:

• Requirements Review
• Architecture Review
• Design Review
• Code Review
• Penetration Test
• Third Party Assessment
• Final Security, Compliance and Privacy Assessment

Utilizando o BugTracker para suportar o tratamento de vulnerabilidades

A ferramenta de Bug Tracker será utilizada para suportar o processo de documentação e auxiliar na integração das equipes responsáveis pelo desenvolvimento, análise da segurança, assim como na gestão destas equipes. O primeiro passo é entender o que representa cada estado do BugTracker, a imagem a seguir apresenta os status que o Mantis utiliza:

Entendo o Mantis

A imagem a seguir apresenta a aplicação de cada um dos status no tratamento da vulnerabilidade e a utilização dos campos customizados que foram citados :

Esta abordagem foi adotada com base no post de Nick Coblentz, respeitando as regras da licença Creative Commons e autorizado pelo autor.

Php Security - Nem tudo que é publicado deve ser seguido

Eu estava lendo o livro: Pro PHP Security (Chris Snyder and Michael Southwell) - Apress. É no passado mesmo, eu não li o resto, pois analisando os códigos no começo do livro encontrei algumas falhas, incluindo problemas de design e arquitetura.

1 - Uso de variáveis Super Globals do Php sem sanitização - página 77

<form action="<? $_SERVER['SCRIPT_NAME']" method="post">
<p>
username: <input type="text" name="userName" size="32" /><br />
username: <input type="password" name="userPassword" size="16" /><br />
<input type="submit" name="submit" value="login" />
<p>
</form>

Estas variáveis como qualquer input podem ser manipuladas, o que torna este form vulnerável a XSS (Cross Site Scripting).

2 - Implementação inadequada de salt - página 78

O livro começou bem neste ponto, sugerindo a utilização de salt como recurso para fortalecer os hashs de senha. Mas, como geralmente acontece, a idéia é boa mas a implementação é ruim.

$salt = time();
$hashedPassword = sha1($userPassword . $salt);

O código apresentado sugere gerar um hash no momento da criação baseado em time(). Como comparar este resultado na hora de cada login se o time() tem um valor que não é fixo? Eles sugerem armazenar um hash em um campo na mesma tabela de usuários, junto com o hash da senha.

$query = 'INSERT INTO LOGIN VALUES (' . dbSafe($userName) . ', ' . dbSafe($hashedPassword) . ',' .dbSafe($salt) . ')';

Geralmente o comprometimento dos hashs de senhas acontece por falhas de SQL Injection, portanto se o usuário mal intencionado pega o hash e salt numa paulada só e consegue reverter a senha (óbvio que aqui estamos falando de senhas com baixa complexidade e que podem ser revertidas por base de hashs pré-compilados).

Este é o típico caso onde existe a exceção, se em código compilado e local não é recomendado a senha hard-coded, neste caso em linguagem interpretada como php, asp é mais seguro que quardar no banco, pois para comprometer o salt ele precisa ter acesso aos diretórios do servidor de aplicação.

As páginas seguintes são uma enrolação danada e nada de código, nem vulnerável. Ai fiquei curioso para ver quais eram as sugestões para controles de sessão,uma falha comum em aplicações.

3 - Controle inadequado contra CSRF/XSRF (Cross Site Request Forgery) - Página 402

<?php

$referrer = $_SERVER['HTTP_REFERER'];
if (!empty($referrer)) {
$uri = parse_url($referrer);
if ($uri['host'] != $_SERVER['HTTP_HOST']) {
exit("Form submissions from $referrer not allowed.");
}
}

else {
exit('Referrer not found. Please <a href="' . $_SERVER['SCRIP_NAME'] . '">try again</a>.');
}

?>

O referer é um recurso do HTTP que informa de onde a requisição está vindo, mas como é coletado usando uma variável Super Global, pode ser manipulado como analisamos no início do post na falha número 1. Controles efetivos para CSRF/XSRF são token de sessão com boa entropia e solicitar uma nova autenticação em operações críticas.

Para forjar um referer e bypassar este controle pode ser usado scripts que geram um referer, exemplo:

<META HTTP-EQUIV="refresh" CONTENT="0;url=[url a ser atacada];">

Não preciso nem falar que não li o livro todo. Não recomendo, o livro não acrescenta praticamente nada em segurança e ainda comete erros grosseiros.