FBI: Programador Russo Roubou Código Secreto da Goldman Sachs

[ Update - 18/02/2012 ]

Brechas em sistemas + brechas na lei = impunidade? Isto vale também para os Estados Unidos - a prisão do desenvolvedor da Goldman Sachs que roubou código secreto da instituição financeira foi revertido na justiça.

Mais detalhes: "Goldman Sachs Code-Theft Conviction Reverse" http://www.wired.com/threatlevel/2012/02/code-theft-conviction-reversed/


[ Update - 19/03/2011 ]

Em um caso prático de monitoração de vazamento de informação confidencial bem sucedido, finalmente chega ao final o julgamento do programador russo (naturalizado americano) Sergey Aleynikov. A sentença foi de 8 anos e um mês de prisão.

O desenvolvedor copiou vários códigos proprietários responsáveis por transações sofisticadas no mercado de ações - que eram consideradas segredo comercial pela Goldman Sachs.

Ele assumiu ter copiado o código, mas alegou que estava coletando software "open-source" que ele tinha desenvolvido, e que o trabalho proprietário do banco GoldMan Sachs havia sido copiado por engano (entre outros lugares, para um servidor de hospedagem na Alemanha).

Sergey faturava U$ 400.000 anuais na Goldman Sachs e foi abordado em 2009 pelo FBI quando desembarcava - com o código proprietário em seu notebook - para conversar com um novo empregador, que pagaria o triplo.

No post original sobre o assunto, abaixo - mais detalhes sobre o caso.

Para uma leitura de como a utilização de tecnologias como DLP e outras medidas podem auxiliar a identificar este tipo de situação, siga o link a seguir: http://www.software.co.il/wordpress/2011/01/using-dlp-to-protect-your-source-code/

Mais informações:

• Wall Street Journal: http://blogs.wsj.com/law/2011/03/18/goldman-sachs-code-stealer-hit-with-harsh-sentence/?mod=e2tw
• Wired: http://www.wired.com/threatlevel/2011/03/aleynikov-sentencing/

[ Post Original - 06/07/2009 ]

Através da monitoração de tráfego suspeito https, a corretora de valores Goldman Sachs conseguiu detectar e comprovar a cópia ilegal de código secreto de sua plataforma de transações financeiras feita por um programador russo naturalizado americano.

Pela leitura da acusação feita pelo FBI (pdf), pode-se verificar o benefício de uma série de controles de segurança implantados pela Goldman Sachs que apoiam sobremaneira o tratamento de incidentes como este, de vazamento de informações confidenciais:

• Monitoração de tráfego com direção à internet, e revisão das transferências criptografadas, como https.
• Controle de acesso físico por andar, com crachás personalizados
• Travamento de Desktop por inatividade
• Registro e guarda das informações de acesso remoto (logs de VPN).
• Gravação das ações efetuadas em estações e servidores linux/unix (bash history, demais logs)

Mais informações no Threat Level da Wired, no DarkReading e na Reuters.

Vulnerabilidade SSLv3 e TLS

[ Update - 2010/01/13 ]

A Internet Engineering Task Force (IETF) publicou uma extensão de segurança para o protocolo SSL que corrige a falha desctrita no post original (que afeta implementações em servidores, navegadores, smartcards, produtos VPN, etc.).


Mais informações em:



http://www.darkreading.com/vulnerability_management/security/vulnerabilities/showArticle.jhtml?articleID=222300635

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tls-renegotiation-03.txt


[ Post Original - 2009/11/18 ]

Na última semana veio a público um trabalho de Steve Dispensa, Marsh Ray e Martin Rex que descreve uma séria vulnerabilidade na fase de renegociação dos protocolos SSLv3 e TLS.

Em linhas gerais, o ataque permite que um atacante faça um "Man in The Middle", injetando informações de sua escolha no começo do stream que será passado de volta para aplicação sendo "protegida" por SSL/TLS, permitindo desta forma algumas possibilidades de exploração bastante preocupantes, como o a escolha pelo atacante de que requisições / transações serão feitas a um internet banking - depois da autenticação do usuário, por exemplo.

O problema está na falta de associação a uma conexão existente durante a renegociação do handshake no SSL/TLS.

Uma descrição detalhada da vulnerabilidade e suas possíveis contra-medidas do lado do cliente e servidor, além de algumas aplicações práticas de exploração delas (SMTP, HTTPS) foi publicada hoje por Thierry Zoller, da G-SEC.

Entrada no CVE (Common Vulnerabilities and Exposures)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.

Mais detalhes: http://securosis.com/blog/what-the-renegotiation-bug-means-to-you/

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.