Windows7 UserAssist - Microsoft troca de ROT13 para Vigènere

[ 29/01/2009 ] - Update:

A Microsoft anunciou que a cifra Vignère está sendo utilizada apenas na versão beta do Windows 7, na versão final, o ROT13 voltará a ser utilizado.

[ 19/01/2009 ]

Do ponto de vista forense, uma das informações interessantes presentes no registro de uma máquina Windows (9x a Vista) são os dados relacionados à utilização de programas / abertura de documentos.

Nos Windows 95,98,ME,2000,XP,2003,Vista e 2008, esta informação está codificada em ROT13 (ref: http://en.wikipedia.org/wiki/Rot13 ) em arquivo por usuário (NTUSER.DAT ) - a chave correspondente é a "Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist" ou no Registro "Live" localizado em "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist"

Na versão beta do Windows7 - recém lançado em beta - isto foi modificado, por uma cifra um pouco mais complexa - a Vigènere (ref: http://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher ), com a seguinte chave de descriptografia (por enquanto fixa) : BWHQNKTEZYFSLMRGXADUJOPIVC.

Por mais que existam críticas à maneira de guardar esta informação - mesmo que a Microsoft mude da cifra de Vigenère para algo melhor, a descriptografia será sempre possível, pois o Windows precisa acessar esta informação todo o tempo - para compilar a lista de programas mais usados, por exemplo...

Crédito: Didier Stevens -> http://blog.didierstevens.com/2009/01/18/quickpost-windows-7-beta-rot13-replaced-with-vigenere-great-joke/

Projeto de Lei - Crimes Eletrônicos (PL 84/99)

A importância do combate aos Crimes Digitais é cada vez mais clara, e no Brasil há alguma evolução neste sentido. Naturalmente vem aumentando a cobrança de uma priorização adequada por parte dos agentes públicos envolvidos.

O Tratado de Budapeste - "Convention on Cybercrime" (pdf), de 2001, foi assinado por 46 países (para detalhamento e restrições, veja aqui) . Ele possui em sua introdução um trecho que encerra a urgência de possuirmos uma legislação adequada nesta área:

"Convictos da necessidade de prosseguir, com carácter prioritário, uma política criminal comum, com o objectivo de proteger a sociedade contra a criminalidade no ciberespaço, designadamente, através da adopção de legislação adequada e da melhoria da cooperação internacional" - mais informaçôes atualizadas sobre a Convenção aqui.

O Brasil não é signatário (já existe alguma movimentação no sentido), e apesar de existirem lei específicas sobre assuntos correlatos (pirataria, invasão de bancos de dados do governo, lei geral das telecomunicações, etc.. ), até o momento o projeto mais importante, PL 84/99, continua em trâmite e sem previsão de virar lei - acompanhe aqui o status do projeto de lei.

Têm havido consultas públicas sobre o texto - eu tive a oportunidade de participar na Anatel de reuniões com interessantes discussões técnicas e jurídicas, no Âmbito da Comissão Brasileira de Comunicações, Tema 1 Segurança. Várias outras sugestões/críticas sobre o projeto foram feitas durante todos estes anos (1,2,3,4,5) . Hoje um post na ISTF me proporcionou conhecer o que considero a melhor contribuição feita até o momento, proposta pela Escola de Direito da Fundação Getulio Vargas - leitura recomendada:

Comentários e Sugestões sobre o Projeto de Lei de Crimes Eletrônicos (PL n. 84/99) (pdf)

TOP 25 CWE/SANS - Problemas de Segurança em Programação (Prós e Contras)

Programar é uma tarefa relativamente simples, mas desenvolver produtos complexos de forma segura e garantir que sua implementação/configuração não irá incluir riscos associados tem se mostrado uma tarefa dificílima de se conseguir. Não é a toa que recentemente o tema de Segurança em Desenvolvimento tem crescido fortemente dentro da comunidade de Segurança da Informação.

Recentemente, o CWE e o SANS Institute divulgaram uma lista dos 25 erros piores erros de programação do ponto de vista da segurança.

A iniciativa não é nova (vide OWASP Top 10, 19 Sins book, e as específicas de linguagens como Java, C, Perl, PHP, ...) , mas claro que é bastante válida - desde que usada com critério.

Algumas críticas interessantes (obrigado, Lucas) foram colocadas por alguns especialistas na área de desenvolvimento seguro, como Gary McGraw - que compilou uma interessante lista de 11 principais motivos do porque listas de "top 10" (ou 25) devem ser avaliadas com cautela.

Alguns pontos interessantes da crítica de McCgraw (tradução livre):

• 1 - Executivos não dão a mínima para erros técnicos
• 3 - Listas de Vulnerabilidades ajudam mais aos auditores do que aos desenvolvedores
• 6 - Listas de erros se modificam de acordo com a mudança da tecnologia
• 9 - Métricas construídas sobre listas "Top N" são enganadoras.

16/01/2009 Update - a OWASP acusa o SANS Institute de plágio.

pdymail - Forense de Memória para o Yahoo Mail

Em outubro eu postei sobre o pdgmail, uma ferramenta desenvolvida em python e disponibilizada por Jeff Bryner, que auxilia em muito a análise de dumps de memória de browsers por informações relacionadas ao uso do Gmail.

Pois bem, o mesmo autor publicou hoje o pdymail, uma ferramenta análoga para a nova interface do Yahoo! Mail, que como o Gmail utiliza JSON/AJAX/XML para manter várias informações em memória e deixa poucos vestígios de seu uso em disco.

O mais importante é definir antecipadamente a forma que você coletará o dump de memória (full ou do processo do browser em execução) - depois disto feito - o uso do pdymail é bastante simples (em linux ou cygwin):

$ strings -el pid1234.dump| ./pdymail -f -

Trocando em miúdos, este tipo de ferramenta é muito útil na fase de análise de investigações que envolvam interfaces modernas de WebMail como o Gmail e o Yahoo! Mail, pois não será muito útil utilizar o processo tradicional de vasculhar o disco por artefatos de Webmail (incluindo espaço não alocado/arquivos deletados).

Uma informação adicional, o dump terá informações úteis desde que o browser tenha sido utilizado anteriormente (naquela execução) para acesso a interface do Yahoo! Mail / Gmail. Ou seja, não é necessário que o usuário esteja logado do Webmail no momento do dump.

Forjando certificados SSL que utilizam o MD5

O tema da virada do ano foi o ataque demonstrado por Alexander Sotirov et al que mostra a necessidade de se deixar de utilizar o algorítimo de hashes criptográficos MD5 em mais uma aplicação: PKI, ou Public Key Infrastructure (slides PDF) / (site SSL prova de conceito)

A implicação mais óbvia é a utilização desta vulnerabilidade em ataques de phishing/pharming mais sofisticados (combinados com ataques de DNS possibilitariam a um atacante a falsificação quase perfeita (e talvez o tunelamento do acesso do cliente através de um site forjado) de instituições de comércio eletrônico e personal banking (https://)

Há quem argumente que não é de grande impacto a notícia, porque o usuário comum simplesmente clicaria em "Add Exception" no Browser quando um ataque similar é feito com um certificado SSL não forjado, mas as implicações são ainda mais sérias neste caso, tanto é que a Verisign estará substituindo gratuitamente para seus clientes os certificados que ainda utilizam o MD5...

Segundo os pesquisadores, além da aplicação da colisão de hashes MD5, o ataque foi possível porque a Verisign e outras (RapidSSL, FreeSSL, TrustCenter, RSA Data Security, Thawte, verisign.co.jp):

• ainda utilizavam (até dias atrás) certificados com assinaturas criadas utilizando MD5 (caso você seja responsável por certificados SSL em uma PKI interna, verifique também... )
  
• automatizam as solicitações de certificados
• não verificam solicitações anômalas
  
• permitem a previsão da combinação entre número de série e validade do certificado
• não limitam o tamanho da cadeia de certificados

Ou seja, uma melhor aplicação do velho e bom conceito de "segurança em profundidade" teria evitado o sucesso do ataque demonstrado, mesmo que a vulnerabilidade existisse.

Vale lembrar que o MD5 tem um crescente histórico de identificações de vulnerabilidades que possibilitaram esta prova de conceito.

Segundo a Netcraft, 14% dos sites que usam SSL utilizam o MD5 como algoritimo de hash.

Estas duas extensões para Firefox podem auxiliá-lo a detectar se o site HTTPS que você está acessando usa certificados que utilizam MD5:

• SSL BlackList
• Perspectives

Além disto, recentemente foi disponibilizado um módulo para o metasploit framework que pode varrer o endereçamente interno da sua empresa e identificar se existem certificados que precisam ser trocados:

Uma lista de referências sobre o assunto segue abaixo:

• http://www.win.tue.nl/hashclash/rogue-ca/
• http://www.phreedom.org/research/rogue-ca/
• http://www.rsa.com/blog/blog_entry.aspx?id=1411
• http://blog.mozilla.com/security/2008/12/30/md5-weaknesses-could-lead-to-certificate-forgery/
  
• http://www.microsoft.com/technet/security/advisory/961509.mspx
• http://doggdot.us/security/Free_SSL_Certificates_?FC=PRCK0
• http://feeds.feedburner.com/~r/SecuritySoapbox/~3/501614128/broken-md5-cracked-ssl-and-end-of-all.html

Um outro detalhe interessante é que para parte da computação necessária para o sucesso do ataque, foram utilizados os cores SPU do processador "Cell" de um cluster de mais de 200 videogames Playstation 3.