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.

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?

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.

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.

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

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/

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

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

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.

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.

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.