Sony PSN hacked - updated

[ Update - 29/06/2011 ]


Hoje a empresa VeraCode publicou um excelente infográfico contendo uma linha do tempo do incidente envolvendo a empresa Sony, contendo os principais eventos, a reação da empresa e o acompanhamento do valor das ações da empresa na bolsa de valores.


Disclaimer: No final, um FUDzinho básico para vender os serviços de varredura de segurança em aplicações WEB da empresa..

[ Post Original - 28/04/2011 ]

Dados de cerca de 100 milhões de contas da
PlayStation Network foram roubados

FAQ da Sony:
http://faq.en.playstation.com/cgi-bin/scee_gb.cfg/php/enduser/std_adp.php?locale=en_GB&p_faqid=5593

FAQ da F-Secure:
http://www.f-secure.com/weblog/archives/00002148.html

Post no blog da Kaspersky sobre a venda dos dados roubados incluindo o código CCV2 do Cartão de Crédito:
http://www.securelist.com/en/blog/6196/Playstation_data_for_sale

Solicitação oficial de esclarecimentos do Congresso Norte-Americano à empresa Sony:
http://republicans.energycommerce.house.gov/Media/file/Letters/112th/042911sony.pdf


Análise do Dr. Alexandre Atheniense sob a perspectiva da legislação brasileira:
http://www.dnt.adv.br/noticias/os-efeitos-do-vazamento-de-dados-das-redes-da-sony-na-legislacao-brasileira/

Conversa em um canal de IRC "ps3dev" da rede efnet sobre a natureza dos eventos:

http://173.255.232.215/logs/efnet/ps3dev/2011-02-16

Discussão sobre a possibilidade de transformar os milhões de consoles PS3 conectados à PSN em uma botnet gigantesca (sabemos do poder de se usar consoles em cluster):
http://www.theregister.co.uk/2011/04/29/sony_playstation_breach_analysis/

E por último, algumas sugestões de precauções para usuários do serviço:

1 - Troque sua senha em quaisquer outros serviços em que ela seja igual ou parecida com a utilizada no PSN;

2 - Caso você tenha fornecido seu número de Cartão de Crédito, solicite um novo Cartão ao seu banco;

3 - Fique de atenção redobrada para futuras tentativas de phishing e/ou fraudes através de emails.

NSA paga Bilhões por "grampo" no Skype

[ Update: 29/06/2011 ]

Obviamente um serviço tão popular quanto o Skype já possui uma estrutura de Lawful Interception (Inteceptação Telemática). Porém com a recente compra da companhia pela Microsoft, alguns analistas estão sugerindo que uma estrutura mais completa e parruda de "grampo" esteja sendo montada.

Leia mais em: Microsoft May Add Eavesdropping To Skype

[ Post Original: 15/02/2009 ]

Tem gente que ficou impressionado com a recente oferta da Microsoft (U$ 250.000 por informações que levem à prisão do autor do Worm Conficker).

Isto é fichinha... O site inglês The Register noticiou que a Agência de Segurança Americana (NSA) estaria oferecendo bilhões de dólares por uma tecnologia que a permita "grampear" ligações utilizando o software de Voz sobre IP Skype. Estas informações teriam sido passadas por um executivo de uma empresa especializada em tecnologias para interceptação telemática em uma feira desta indústria, em Londres.

Possivelmente a NSA consegue quebrar a criptografia da comunicação do Skype, mas talvez isto consuma mais ciclos de processamento que eles gostariam...

O artigo sugere que a eBay (que comprou a Skype) também pode faturar alto para facilitar para a NSA (backdoor, talvez?) as interceptações de ligações via Skype.

A estrutura de funcionamento do Skype dificulta a interceptação telemática - (nome utilizado para o "grampo" autorizado judicialmente) . A comunicação é ponto a ponto ( peer2peer - ou seja, os dados não passam por um site central). Segundo o artigo, a Skype não divulga o método/algorítmo de criptografia utilizado * e o troca de tempos em tempos).

Um caso relacionado interessante aconteceu em 2006, quando o ex-presidente da empresa de tecnologia para Telecomunicações Comverse foi preso na África. Ele estava foragido dos EUA por fraude financeira e que foi encontrado graças à uma ligação feita por ele no Skype.

Neste caso, o FBI não precisou ouvir a ligação do fugitivo, bastava ter certeza que se tratava do usuário dele se logando e/ou utilizando algum serviço que entregasse alguma informação útil aos investigadores, como uma ligação para algum número conhecido via skype-out... Em outras palavras, neste caso o Skype garantiu um bom nível de confidencialidade para o fugitivo, mas não anonimato...

Este tipo de assunto normalmente sucita uma interessante guerra de argumentos entre os defensores da privacidade e os responsáveis por investigações / indústria da inteligência - que precisam da interceptação autorizada (ou de grampos mesmo) para efetuar importantes trabalhos de segurança...

Em países em que esta discussão não existe (como a China), o problema se resolve de uma forma mais simples. Mais informações no post: "Skype Chinês - Você está sendo vigiado... e suas conversas estão disponíveis na Internet!."

Aproveitando o assunto, existe um bom guia para análise dos registros de uso (logs) do Skype - pode ser útil para investigações em que você tenha acesso ao disco do suspeito (fisicamente ou remotamente) - detalhes aqui (pdf).

Para os interessados, segue o link para um paper sobre análise/monitoração de tráfego voip criptografado (pdf)

(*) - A apresentação "Silver Needle in the Skype" (pdf) feita na conferência Black Hat Europe de 2006 - há detalhes sobre os algorítimos utilizados na época: RC4 para obfuscação de informações pacotes de rede; criptografia assimétrica com chaves RSA de 1024 bits e 1536 bits, e simétrica com AES 256 bits.

Existem algumas ferramentas interessantes para análise forense de arquivos .DB e .DBB do Skype:

• Skypr (free, mais simples),
• SkypeLog (free),
• SkypeAlyzer (comercial, mais completa).

Análise de hipóteses: (D)DOS no site da Presidência da Republica

[ Update - 2011/06/22 13:50 ]

Em nota, o SERPRO indica que a hipótese II abaixo é a mais próxima da realidade:

"O Serpro (Serviço de Processamento de Dados) detectou nesta madrugada, entre 0h30 e 3h, uma tentativa de ataque de robôs eletrônicos aos sites Presidência da República; Portal Brasil e Receita Federal. O sistema de segurança do Serpro, onde estes portais estão hospedados, bloqueou todas as ação dos hackers, o que levou ao congestionamento das redes, deixando os sites indisponíveis durante cerca de uma hora"

No momento ainda há instabilidade e lentidão no acesso aos sites http://www.brasil.gov.br e http://www.presidencia.gov.br

O site da Petrobras foi também atacado mas ficou indisponível por poucos minutos no dia de hoje.

[ Update - 2011/06/22 02:22]

Mais uma vez sites da Presidência da República são alvos ataques de Negação de Serviço. Desta vez o grupo @LulzSecBrazil assumiu a responsabilidade pelo ataque, nestes tweets:

LulzSecBrazil: @AnonymousGenie @YourAnonNews TANGO DOWN brasil.gov.br & presidencia.gov.br LulzSecBrazil

Os sites http://www.brasil.gov.br e http://www.presidencia.gov.br estavam mesmo indisponíveis durante esta madrugada, e curiosamente os demais sites na mesma classe-C (161.148.172/24) estão respondendo normalmente (ex: http://161.148.172.185/). A partir disto, imagino algumas hipóteses - por ordem de probabilidade:

I) Como ambos sites rodam Apache - segundo a NetCraft - podem estar sob ataque de DoS do tipo Slowloris (abertura e manutenção da conexão através de envios sequenciais de cabeçalhos HTTP por longos períodos até inviabilizar novas conexões ao serviço) - neste caso mitigações são possíveis com o modsecurity, por exemplo.

II) um ataque tradicional de DDoS (Loic/Botnet) ocorreu e algum filtro de ACL em roteador ou regra de firewall pode ter sido criado a alguns hops destes dois IPs até que perguntas sejam respondidas (ver abaixo) e uma solução mais definitiva seja encontrada.

III) o ataque direcionado aos servidores - que não estão conseguindo responder ás conexões - não afetaram o restante da infra-estrutura (roteadores, firewalls, balanceadores, demais webservers up, etc..)


Além da tráfego de rede dos uplinks, obviamente deve-se analisar o efeito do ataque no alvo afetado, a partir dos registros de roteadores, servidores web e firewalls disponíveis.
Entre as perguntas a responder neste momento - por quem tem acesso aos dados para uma Resposta a Incidentes adequada: (lista rápida a ser editada com auxílio dos comentários dos Senhores):

1) que dispositivo(s) falhou(aram), afinal?

2) que serviços foram afetados?

3) Se trata de DoS ou DDoS?

4.1) Qual foi o troughput (Gpbs) e número de pacotes por segundo (PPS) durante ataque?
4.2) No pico? Em média durante a indisponibilidade?

5.1) Há spoofing de IP?
5.2) Configurações de ingress filtering da sua infraestrutura e em seus uplinks estão adequadas?

6.1) Caso quem falhou, resista - os próximos da cadeia falhariam? (ex: roteador->firewall->balanceador de carga->servidor web)
6.2) Quais configurações anti-ddos podem ser feitas nestes dispositivos?

7) Serão necessários novos dispositivos ou serviços especializados em mitigação de DDoS? (Arbor, VeriSign, Narus, etc..)

8) Vale a pena mover sua home page para outra estrutura menos vulnerável a negação de serviço? (até mesmo na nuvem: Akamai ou Amazon Elastic Computing Cloud)

Como resultado da análise destes pontos, pode-se chegar a respostas mais apropriadas. Normalmente a mitigação deste tipo de ataque se inicia em uma análise que envolve a equipe de Redes e de Resposta a Incidente dos alvos, além dos times de segurança de backbone dos uplinks - no caso em pauta, a Oi (AS 8167 e AS 7723) e a Telefônica (AS 10429).

Depois da identificação da(s) origem(ns) reais, o ideal é que se consiga configurar um "Black Hole" para o tráfego indesejado: Entre outras ações, isto normalmente envolve configurações para roteamento nulos (null0) e redirecionamento de origens do ataque identificadas com uRPF.

Outras ações estão sendo executadas pelo grupo LulzSecBrazil, inclusive o defacement de páginas (até agora, nenhuma do governo - mas a atenção deve estar redobrada já que os interessados em se juntar ao grupo estão sendo recrutados em toda a parte).

Pulando do técnico para o Jurídico: do ponto de vista da responsabilização dos atacantes - retomo material já apresentamos aqui em post conjunto com o Dr. Emerson Wendt:

"Pode haver configuração de crime de dano, previsto no art. 163 do Código Penal Brasileiro:

Dano
Art. 163 - Destruir, inutilizar ou deteriorar coisa alheia:

Pena - detenção, de um a seis meses, ou multa.

Dano qualificado

Parágrafo único - Se o crime é cometido:

I - com violência à pessoa ou grave ameaça;

II - com emprego de substância inflamável ou explosiva, se o fato não constitui crime mais grave;

III - contra o patrimônio da União, Estado, Município, empresa concessionária de serviços públicos ou sociedade de economia mista;

IV - por motivo egoístico ou com prejuízo considerável para a vítima: Pena - - detenção, de seis meses a três anos, e multa, além da pena correspondente à violência.

Veja a nova redação do Artigo 163, prevista no Projeto de Lei 84/99 - que deve - finalmente?! - ser votado este ano:

Art. 163. Destruir, inutilizar ou deteriorar coisa alheia ou dado eletrônico alheio:

Ademais, o PL 84/99 prevê outro artigo interessante, no qual pode ser enquadrado o caso em questão:

“Inserção ou difusão de código malicioso”

Art. 163-A. Inserir ou difundir código malicioso em dispositivo de comunicação, rede de computadores, ou sistema informatizado.

Pena – reclusão, de 1 (um) a 3 (três) anos, e multa.

Inserção ou difusão de código malicioso seguido de dano

§ 1º Produzir intencionalmente ou vender código malicioso destinado ao uso em dispositivo de comunicação, rede de computadores ou sistema informatizado.

Pena – reclusão de 1 (um) a 3 (três) anos, e multa

§ 2º Se do crime resulta destruição, inutilização, deterioração, alteração, dificultação do funcionamento, ou funcionamento desautorizado pelo legítimo titular, de dispositivo de comunicação, de rede de computadores, ou de sistema informatizado:

Pena – reclusão, de 2 (dois) a 4 (quatro) anos, e multa.

§ 3º Se o agente se vale de nome falso ou da utilização de identidade de terceiros para a prática do crime, a pena é aumentada de sexta parte

Enquanto isto, no exterior, a recente prisão de um rapaz de 19 anos na Inglaterra por envolvimento com o grupo gera discussão se ele era apenas admin de um canal de IRC ou tinha uma importância maior.. A polícia ainda tenta descobrir..) Além disto, é crescente a divulgação de dados dos participantes do grupo (por eles mesmos: http://pastebin.com/MBEsm5XQ e por inimigos: http://lulzsecexposed.blogspot.com).

E você, o que você acha do movimento #AntiSec? Acha que há exageros? Ou não? Acha que o grupo vai ficar mais forte e numeroso? Novas prisões ocorrerão lá fora e aqui no Brasil? E sobre os ataques do LulzSec? Dê a sua opinião! Comente!

Posts Relacionados:

• As Ações Anti-Anti-Wikileaks (DDoS) e a legislação penal brasileira
• Anti-Anti-Wikileaks e seus efeitos

• O Anchises fez um bom apanhado sobre a "Operação AntiSec" e links para outros blogs sobre o assunto, neste post.

[ Post Original - 2011/01/03 ]

Hoje vários portais anunciaram um DOS (negação de serviço) que afetou o site da Presidência da República (http://www.presidencia.gov.br):

• Terra - Após posse, sites da Presidência e do governo sofrem ataques
• Folha - Após posse de Dilma, site da Presidência sofre ataque e fica fora do ar
• Info Abril - Ataques deixam site da Presidência fora do ar
• UOL - Grupo assume autoria de ataque ao site da presidencia
• The Washington Post - Hackers attack Brazilian government's website

Apesar das poucas informações técnicas disponíveis sobre o ataque, segue uma análise preliminar:

Uma conta do twitter (@fatalerrorcrew) que é utilizada por um grupo de defacement - ou desfiguração de sites - (lista de ataques no zone-h) brasileiro está assumindo a responsabilidade pelo ataque e infelizmente suas ações recebem apoio de alguns usuários do serviço online.

[ Update 2010/01/05 - o UOL divulgou um entrevista com os crackers responsáveis pelos ataques - Grupo que atacou site da presidência nega motivação política e não teme punição ]

Como o SERPRO e o DSIC/CTIR possuem excelentes recursos e analistas, independente da motivação (publicidade, política, etc.) os autores certamente serão identificados e pode configurar-se - minimamente - crime de dano, conforme Artigo 163 do Código Penal brasileiro (como já publicamos aqui no caso dos ataques de DDOS "Anti-Anti-Wikileaks" em post conjunto com o Dr. Emerson Wendt):

Dano
Art. 163 - Destruir, inutilizar ou deteriorar coisa alheia:

Pena - detenção, de um a seis meses, ou multa.

Dano qualificado

Parágrafo único - Se o crime é cometido:

I - com violência à pessoa ou grave ameaça;

II - com emprego de substância inflamável ou explosiva, se o fato não constitui crime mais grave;

III - contra o patrimônio da União, Estado, Município, empresa concessionária de serviços públicos ou sociedade de economia mista;

IV - por motivo egoístico ou com prejuízo considerável para a vítima:

Pena - detenção, de seis meses a três anos, e multa, além da pena correspondente à violência.

Veja a nova redação do Artigo 163, prevista no Projeto de Lei 84/99 - que deve - finalmente - ser votado este ano:

Art. 163. Destruir, inutilizar ou deteriorar coisa alheia ou dado eletrônico alheio:

Ademais, o PL 84/99 prevê outro artigo interessante, no qual pode ser enquadrado o caso em questão:

“Inserção ou difusão de código malicioso”

Art. 163-A. Inserir ou difundir código malicioso em dispositivo de comunicação, rede de computadores, ou sistema informatizado.

Pena – reclusão, de 1 (um) a 3 (três) anos, e multa.

Inserção ou difusão de código malicioso seguido de dano

§ 1º Produzir intencionalmente ou vender código malicioso destinado ao uso em dispositivo de comunicação, rede de computadores ou sistema informatizado.

Pena – reclusão de 1 (um) a 3 (três) anos, e multa

§ 2º Se do crime resulta destruição, inutilização, deterioração, alteração, dificultação do funcionamento, ou funcionamento desautorizado pelo legítimo titular, de dispositivo de comunicação, de rede de computadores, ou de sistema informatizado:

Pena – reclusão, de 2 (dois) a 4 (quatro) anos, e multa.

§ 3º Se o agente se vale de nome falso ou da utilização de identidade de terceiros para a prática do crime, a pena é aumentada de sexta parte.

O site da presidência usava desde o início do ano o Squid como proxy reverso no IP 161.148.24.14 (http://toolbar.netcraft.com/site_report?url=http://www.presidencia.gov.br) e desde o dia dos ataques passou a ter o seguinte banner HTTP (respondendo pelo IP: 161.148.172.40):

Apache/2.2.3 (Red Hat) Server at www.presidencia.gov.br Port 80

É possível que o Squid como proxy reverso tenha sido removido para diminuir os possíveis pontos de falha diante dos ataques.

Os detalhes técnicos do ataque ainda não foram publicados, mas pode-se imaginar quatro possíveis vetores:

1. ataques "slow-dos" como o Slowloris para apache;
2. utilização (ou sub-locação) de botnets;
3. utilização de ferramentas como a LOIC;
4. abuso de DNS Recursivos abertos;

Com relação à defesa destes tipos de ataque, seguem algumas referências:

• Para o Slowloris (1) - o módulo para apache "ModSecurity" recentemente fez uma atualização para se defender deste tipo de ataque.
• Para os ataques de botnets numerosas (2,3) (voluntárias como LOIC ou não), recomendo as soluções Anti-DDOS da Arbor NetWorks, como o PeakFlow SP
• Se o caso for de abuso de DNS Recursivos abertos, recomendo um paper do CERT.BR que tive o prazer de revisar em 2007: Recomendações para Evitar o Abuso de Servidores DNS Recursivos Abertos (pdf atualizado em 2009)

Vale a pena também conferir o seguinte material:

• Five Ways to defend against a DDOS attack (bandwidth, geoblocking, cloud, reverse proxy, choose neighbours)
• Tudo que você precisa saber sobre os ataques DDoS CAIS/RNP via @giseletruzzi (um pouco desatualizado..)

Uma lamentável reação a este incidentes são usuários do Twitter apoiando os ataques abertamente.

Providências poderão ser tomadas pela PGR, assim como no incidente de ameaças à presidente eleita feitas recentemente pelo Twitter.

Não podemos permitir que a Internet brasileira seja uma terra sem lei, e na minha opinião este tipo de acontecimento deve ser combatido com veemência pelas autoridades competentes.

Inscreva-se no RSS Feed e receba atualizações automáticas

[ Update - 2011/01/04 ]

Mais um ataque de DDOS em sites do governo notificado pela mídia:

• Terra - Hacktivismo: protesto tira site da prefeitura de SP do ar
• JB - Protesto hacker tira do ar site da prefeitura de São Paulo

O site da prefeitura de SP (http://prefeitura.sp.gov.br) também está sendo afetado por um ataque de DDOS, e está inacessível neste momento (IP 189.20.216.167). Segundo a netcraft, seu banner é o seguinte:

Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch proxy_html/3.0.0

Como forma eficiente de mitigação - por volta do meio dia - o site da prefeitura de Sp passou a redirecionar os acessos para "capital.sp.gov.br" como pode ser visto no código abaixo:

META http-equiv="refresh" content="0;URL=http://www.capital.sp.gov.br

Desta vez o grupo que assumiu a responsabilidade pela "ação de hacktivismo" foi o drwxr - que alega estar fazendo um protesto: "Pelo aumento abusivo do transporte público na cidade de São Paulo, estamos protestando - o site www.prefeitura.sp.gov.br encontra-se fora do ar" - segundo o atacante "ploks" entrevistado pelo Terra.

É digno de nota a cobertura dada a estes eventos pela mídia brasileira, inclusive com alguns exageros como o excessivo destaque e quase heroificação (como nos casos dos apoiadores de mídias sociais) dos atacantes em alguns casos.

Todas as observações legais e de possíveis vetores de ataque apresentadas no caso abaixo também se aplicam a este caso. Este tipo de "hacktivismo" é miope e criminoso por interferir com serviços prestados pelo estado à população pela internet.

Empreiteiras militares americanas atacadas / vulnerabilidades do RSA/Securid

Militares e suas empreiteiras obviamente possuem adversarios preparados e motivados (como nacoes inimigas e hackers trabalhando para elas). Isto nao eh novidade, como pode ser visto na historia que se passou ha 25 anos, contada por Cliff Stoll no livro "The Cucko's Egg" (veja nosso post sobre isto aqui).

Para usar um exemplo real mais recente (2010) e talvez menos conhecido, veja o caso do vazamento de informacoes do projeto de um jato americano chamado "Joint Strike Fighter" (para mais informacoes, clique aqui).

Na semana passada eu comecei a acompanhar as noticias relacionadas ao ataque ocorrido no dia 21 de maio a uma grande empresa empreiteira (contractor) militar norte-americana. No inicio eram informacoes desencontradas e muita suposicao e poucos fatos, mas nesta 2a-feira foram publicadas informacoes mais precisas. Vamos aos dados:

O blogueiro Robert X. Cringely divulgou o seguinte post no dia 25 (quarta-feira):

http://www.cringely.com/2011/05/insecureid-no-more-secrets/

No dia 27, (sexta), a Reuters publicou uma "exclusiva" e colocou o "nome nos bois" no caso: - a empresa atacada foi a LockHeed Martin - a maior empreiteira militar americana - que atua nas areas de defesa aeronautica e aeroespacial.

No mesmo dia (27/05/2011) a LockHeed Martin divulgou o seguinte comunicado oficial (grifos meus):

On Saturday, May 21, Lockheed Martin (NYSE: LMT) detected a significant and tenacious attack on its information systems network. The company's information security team detected the attack almost immediately, and took aggressive actions to protect all systems and data. As a result of the swift and deliberate actions taken to protect the network and increase IT security, our systems remain secure; no customer, program or employee personal data has been compromised.
Throughout the ongoing investigation, Lockheed Martin has continued to keep the appropriate U.S. government agencies informed of our actions. The team continues to work around the clock to restore employee access to the network, while maintaining the highest level of security.
To counter the constant threats we face from adversaries around the world, we regularly take actions to increase the security of our systems and to protect our employee, customer and program data. Our policies, procedures and vigilance mitigate the cyber threats to our business, and we remain confident in the integrity of our robust, multi-layered information systems security.

A Lockheed Martin tem um bom time de Resposta a Incidentes, incluindo o especialista Michael Cloppert - que considero um dos melhores Incident Reponders do mundo, e que ja foi citado aqui no blog (e nao atualiza seu twitter desde o dia 21, curiosamente o mesmo dia do incidente envolvendo a empresa).

[ Update 31/05/2011 17h - A Wired divulgou que outro Contractor também foi afetado: Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks ]

[ Update 01/06/2011 12h - A Fox News publicou uma noticia envolvendo um terceiro contractor: Northrop Grumman ]

Dentre as acoes de mitigacao do incidente, todos os acessos remotos a empresa LockHeed Martin foram revogados temporariamente, incluindo a reconfiguracao dos tokens SecurID, da RSA, que serviam como segundo fator de autenticacao dos acessos via VPN, por exemplo.

Desde o incidente divulgado pela empresa RSA em marco deste ano, envolvendo o possivel vazamento do codigo do SecurID - ataques como este ja eram esperados. Este trecho do comunicado da RSA fez muita gente "ligar os pontos" entre os dois incidentes (grifo meu):

While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.

Para explorar com sucesso um sistema utilizando a autenticacao SecurID da RSA - como o da LockHeed Martin, eh necessario saber o nome do usuario, o PIN (ou senha) - que podem ser alvo de um ataque de forca bruta - e o valor da semente (seed) original (que foi facilitada devido ao ataque a RSA de marco).

Desta forma, o segundo fator de autenticacao permitia que os acessos dos usuarios que escolhiam senhas fracas (curtas e/ou pouco complexas), estivessem protegidos.

Na verdade estruturas de acesso remoto sao sempre uma porta obvia aberta para ataques externos, E eh possivel que a monitoracao em tempo real das autenticacoes nos sistemas SecureID da LockHeed Martin tenha possibilidado a identificacao do ataque a tempo de conter vazamentos consideraveis de informacoes sigilosas.

Vale ressaltar que para vencer o SecurID e sistemas similares nao eh necessario tanto esforco, pois ataques do tipo "man in the middle" e/ou a instalacao de trojans na maquina do cliente que esta se autenticando podem interceptar toda a comunicacao diretamente do S.O. ou browser do usuario e passa-las ao atacante - no mesmo estilo dos ataques a acessos a personal banking.

Para sistemas criticos, caso o acesso remoto seja realmente necessario, outros esquemas de protecao de acesso remoto podem (e devem) ser implementados, como a utilizacao de biometria (que pode ser o 2o ou 3o fator de autenticacao) e o meu preferido: o port-knocking <= mas isto vale outro post..

Em uma nota paralela, a LockHeed Martin acaba de adquirir o primeiro computador quantico comercial do mundo por US$ 10.000.000,00 (dez milhoes de dolares) . Ja que a tendencia eh que a criptografia classica (como a usada com o SecurID da RSA) seja facilmente quebrada utilizando a computacao quantica (.pdf) - quem sabe em alguns meses eles nao liberam uma solucao de autenticacao utilizando criptografia quantica usando o "D-Wave One" recem comprado! ;)

100.000 page-views + sorteio de 2 livros para os leitores do blog

[ Update: 25/05/2011 - Marca alcancada e Resultado do Sorteio ]

Chegamos aos 100 mil pageviews (~ 500 acessos por post publicado)

Obrigado a todos que participaram da promocao de comemoracao dos 100 mil pageviews do blog. Acabo de realizar o sorteio (screenshots abaixo) dos dois livros (*) e ja estou contactando os dois vencedores para definir qual livro enviarei para cada um:

@HigorJorge
@Marcosfsn

*) Windows Registry Forensics +DVD - livro recém lançado de Harlan Carvey (U$ 60,00)

*) Desvendando a Computação Forense - livro dos Peritos Criminais Federais Pedro Eleutério e Márcio Machado (R$ 45,00)

Screenshot do Sorteio 1:

Screenshot do Sorteio 2:

[ Post Original: 01/05/2011 ]

Senhores, é com prazer que nos aproximamos da marca de 100.000 page-views no nosso blog. No momento deste post estamos com 97.102 page-views e pela tendência recente de acessos devemos atingir a marca entre duas e tres semanas.

Até hoje, registramos aqui no blog as marcas de page-views alcançados de 10 em 10 mil. Assim foi nos 10, 20, 30, 40, 50, 60, 70, 80 e 90 mil pageviews.

Como desta vez a marca é especial, resolvi sortear entre os nossos leitores dois excelentes novos livros que adquiri em duplicidade exatamente para este evento dos 100.000 page-views.

1o Livro) Windows Registry Forensics +DVD - livro recém lançado de Harlan Carvey (U$ 60,00)

2o Livro) Desvendando a Computação Forense - livro dos Peritos Criminais Federais Pedro Eleutério e Márcio Machado (R$ 45,00)


Para facilitar o sorteio entre os leitores do blog interessados, basta escrever no twitter a hashtag #100milSSeguranca

O "regulamento" é muito simples: no dia em que o nosso blog alcançar esta marca, eu irei sortear dois usuários dentre os que usaram a hashtag #100milSSeguranca e irei entrar em contato via DM (direct message) para obter o endereço para envio dos livros.

Obs1: Não é necessário nos seguir no twitter para participar - mas é necessário estar no twitter e ter escrito a hashtag #100milSSeguranca, pois é assim que escolherei os participantes do sorteio.

Obs2: Para participantes com endereços de entrega dentro do território brasileiro, eu arcarei com o valor do frete do envio, para os demais participantes, este valor deve ser pago pelo eventual vencedor.

Mais uma vez obrigado a todos pelos comentários e sugestões de tópicos nestes quase 3 anos de blog e mais de 200 artigos publicados!

Comodo Hack e MySQL.com SQL injection

A poeira da invasao e possivel compremetimento do código do SecurID da RSA ainda não baixou e outros ataques que merecem nota já ocorreram nos últimos dias. Segue um breve resumo sobre o I) #ComodoGate e II) blind SQL injection do MySQL.com e Sun.com.

I) COMODOGATE:


Update (25/05/2011 - 09:34) - A ComodoBr.com (apesar dos varios selos estilo "HackerSafe" no rodape do site) foi tambem comprometida via SQL Injection e um dump parcial de seu Banco de Dados foi publicado: http://pastebin.com/9qwdL1pA

Update (04/04/2011- 12:17) - O cryptome.org acaba de publicar um .rar com dois arquivos com o backup dos bancos de dados da GlobalTrust (33M) e da InstantSSL (9,3M).

Update (30/03/2011 - 17:43) - Mais 2 Autoridades Registradoras da Comodo foram comprometidas (além da italiana GlobalTrust). Que outros certificados forjados foram gerados? Aguardemos..

Fonte: o "ComodoHacker" postou mais uma de suas mensagens no estilo "Avassalador" em http://pastebin.com/kkPzzGKW - Trecho:

"From listed resellers of Comodo, I owned 3 of them, not only Italian one, but I interested more in Italian brach because they had too many codes, works, domains, (globaltrust, cybertech, instantssl, etc.) so I thought they are more tied with Comodo".

A Comodo confirmou em mensagem de um executivo, que descreve algumas das ações de "contenção de danos" que estão sendo colocadas em prática pela empresa.

Update (29/03/2011 - 20:15) - o G1 Segurança (Globo.com) publicou bastante material sobre o tema - Hacker invade empresa de segurança e falsifica 'cadeados' de sites - incluindo link para este post. Obrigado @altieres!

Update (29/03/2011 - 14:33) - o jornal Alemão Der Spiegel também o entrevistou.

Update (28/03/2011 - 18:47) - o blog ErrataSec divulgou uma entrevista com o hacker iraniano responsável pelo "ComodoGate.

Update (28/03/2011 - 17:01h) - O "ComodoHacker" agora tem conta no twitter: @ichsunx e acaba de divulgar outros dois dados para confirmar que é ele o responsável pelos ataques: 1) o Certificado falso gerado para o site de addons da Mozila. 2) a tabela de hashes de um BD do RA invadido.

Todos os textos publicados pelo hacker podem ser visualizados no seguinte link: http://pastebin.com/u/ComodoHacker

1) O Certificado parece válido - eis a saída do comando " $ openssl x509 -in mozilla.crt -text -noout "

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

92:39:d5:34:8f:40:d1:69:5a:74:54:70:e1:f2:3f:43

Signature Algorithm: sha1WithRSAEncryption

Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware

Validity

Not Before: Mar 15 00:00:00 2011 GMT

Not After : Mar 14 23:59:59 2014 GMT

Subject: C=US/postalCode=38477, ST=Florida, L=English/streetAddress=Sea Village 10, O=Google Ltd., OU=Tech Dept., OU=Hosted by GTI Group Corporation, OU=PlatinumSSL, CN=addons.mozilla.org

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (2048 bit)

Modulus (2048 bit):

00:ab:c6:6d:36:f3:15:73:78:83:73:ce:74:85:d5:

ae:ec:b2:f0:e0:24:1f:13:83:b8:20:ac:bb:9a:fe:

88:bb:ab:a1:1d:0b:1f:45:00:aa:49:b7:35:37:0c:

6a:ef:47:4c:b9:d1:be:e3:57:12:04:8d:92:c7:b6:

ec:01:bc:b6:da:c7:81:38:20:ad:72:85:e6:0e:fc:

81:6c:07:ad:68:76:38:c5:44:d7:cc:c6:4a:c5:97:

3e:64:f4:51:e6:f0:7e:b2:ec:56:f7:25:82:4d:49:

98:cb:16:98:dd:23:f1:89:91:d1:17:97:40:99:26:

d6:e2:a2:2b:5e:df:bd:89:f2:1b:1a:53:2d:cc:50:

41:7a:d0:3d:2a:0c:55:70:14:01:e9:58:49:10:7a:

0b:93:82:8b:e1:1e:ed:3a:80:10:82:ce:96:8a:34:

f0:cc:d7:d3:b9:b4:50:87:55:54:09:b8:9d:42:28:

55:00:e5:8c:35:54:bf:dd:25:91:46:b7:0d:e5:5d:

83:a8:e5:8b:fb:84:e4:3c:ae:76:da:c4:43:2b:5b:

74:0b:f8:be:5d:68:f1:78:5b:b5:ce:7d:f1:5d:99:

40:da:ca:ee:38:81:50:be:98:a1:6c:b8:24:ad:f3:

af:8c:0f:d7:11:28:2c:84:18:4c:7d:b5:d9:8f:30:

b5:1b

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Authority Key Identifier:

keyid:A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45

X509v3 Subject Key Identifier:

DD:80:D2:54:3D:F7:4C:70:CA:A3:B0:DD:34:7A:32:E4:E8:3B:5A:3B

X509v3 Key Usage: critical

Digital Signature, Key Encipherment

X509v3 Basic Constraints: critical

CA:FALSE

X509v3 Extended Key Usage:

TLS Web Server Authentication, TLS Web Client Authentication

X509v3 Certificate Policies:

Policy: 1.3.6.1.4.1.6449.1.2.1.3.4

CPS: https://secure.comodo.com/CPS

X509v3 CRL Distribution Points:

URI:http://crl.comodoca.com/UTN-USERFirst-Hardware.crl

URI:http://crl.comodo.net/UTN-USERFirst-Hardware.crl

Authority Information Access:

CA Issuers - URI:http://crt.comodoca.com/UTNAddTrustServerCA.crt

OCSP - URI:http://ocsp.comodoca.com

X509v3 Subject Alternative Name:

DNS:addons.mozilla.org, DNS:www.addons.mozilla.org

Signature Algorithm: sha1WithRSAEncryption

33:3b:63:15:fc:b1:ec:14:2c:93:dd:75:94:de:81:5a:d9:4e:

99:be:fb:4a:a4:39:55:4d:a1:40:7a:de:13:2a:87:a9:37:cf:

e8:d5:fb:ad:d1:7b:6d:6f:8c:20:87:82:54:e6:57:49:bc:20:

28:84:cd:d6:01:d9:93:8b:17:6e:23:66:e5:84:c8:80:3f:c6:

a1:70:80:e4:ec:4d:1d:f9:fc:91:5a:73:62:29:9a:f7:20:1c:

61:e0:8b:39:9f:ca:bc:7e:8d:dd:bc:d9:b1:e3:9f:9e:df:15:

53:91:21:52:0b:d9:1a:23:0f:66:36:db:ac:93:96:4a:a3:a5:

22:cf:29:f7:a2:99:a8:f6:b6:d9:40:ae:d9:7e:b6:f6:58:2e:

9b:ac:36:ca:64:8f:65:52:dc:86:9c:82:ab:6e:50:4b:da:5f:

fa:05:00:88:30:0e:de:8d:56:bf:81:47:8d:3d:06:e2:b2:62:

92:67:8f:9e:c8:9a:b2:e5:06:b8:70:24:b8:77:7c:23:0a:38:

c3:79:08:d8:b1:51:9d:ac:95:11:c7:40:17:9e:a3:1c:8f:f2:

11:a7:68:27:da:49:05:84:18:7c:58:2d:01:67:5c:e5:9f:a1:

29:bb:4a:39:45:2f:bf:11:aa:79:a2:ed:b4:d4:b5:65:43:b7:

93:46:8a:d3

A chave privada também foi postada:

-----BEGIN RSA PRIVATE KEY-----

MIIEowIBAAKCAQEAq8ZtNvMVc3iDc850hdWu7LLw4CQfE4O4IKy7mv6Iu6uhHQsf

RQCqSbc1Nwxq70dMudG+41cSBI2Sx7bsAby22seBOCCtcoXmDvyBbAetaHY4xUTX

zMZKxZc+ZPRR5vB+suxW9yWCTUmYyxaY3SPxiZHRF5dAmSbW4qIrXt+9ifIbGlMt

zFBBetA9KgxVcBQB6VhJEHoLk4KL4R7tOoAQgs6WijTwzNfTubRQh1VUCbidQihV

AOWMNVS/3SWRRrcN5V2DqOWL+4TkPK522sRDK1t0C/i+XWjxeFu1zn3xXZlA2sru

OIFQvpihbLgkrfOvjA/XESgshBhMfbXZjzC1GwIDAQABAoIBAQCJoijaEXWLmvFA

thiZL7jEATCNd4PK4AyFacG8E9w8+uzR15qLcFgBTqF95R49cNSiQtP/VkGikkkc

ao25aprcu2PnNA+lpnHKajnM9G3WOHuOXHXIps08es3MmBKTxvjNph6cUlqQULrz

Zry+29DpmIN/snpY/EzLNIMptn4o6xnsjAIgJDpQfFKQztxdmZU6S6eVVn0mJ5cx

q+8TTjStaMbh+Yy73s+rcaCXzL7yqWDb1l5oQJ/DMYNfufY6lcLgZUMwFxYKjCFN

ScAPCiXFUKTzY3Hy1Z4tLndFxipyEPywDep1TB2nMb+F3OOXUs3z+kKVjGFaGnLZ

591n3x3hAoGBAOOgsb4QybjHh9+CxhUkfsqcztGGdaiI3U5R1qefXL7R47qCWfGc

FKdoJh3JwJzHEDX68ZmHz9dPhSXw6YrlLblCi6U/3g7BOMme5KRZKBTjHFo7O9II

B0laE5ISRH4OccsOC3XUf9XBkm8szzEBj95DgzB0QydPL4jp7NY0h0QrAoGBAMEv

jEFkr/JCRe2RWUSx/a1WT/DHnVLMnDb/FryN2M1fAerpMYNUc2rnndjp2cYbsGLs

cSF6Xecm3mUGqn8Y5r8QqBwxCp5OunCFCXEJvkiU3NSs8oskCsB8QJ6vk3qmauUK

jClX91heSCigwhC2t+1txnF290m/y0T46EfqOSrRAoGAUlyVk4D9jEdeCWiHBaVj

3ynnx3ZQYj/LW4hPE+2coErPjG+X3c0sx/nuOL8EW3XHjtCS1IuIj45tTfIifqg3

6B2E67D1Rv9w7br5XeIIl64pVxixp2hSQp8+D49eiwHs+JzHVsYhzxUwR9u9yCyZ

gsGI2WJn3fRP7ck+ca8l9msCgYB4B2Hec3+6RqEKBSfwvaI+44TRtkSyYDyjEwT+

bCeLGn+ng/Hmhj8b6gKx9kH/i86g+AUmZtAXQZgmLukaBM/BYMkCkxnk2EeQh6gh

Goumrw8x+K7N8rvXcpv3vGEmcGW0H0SMn4In3pR44cER/2Tx2SXV87Obl9Xk6b3w

iL+yMQKBgFjXcmiBW8lw3l2CaVckd/1SzrT80AfRpMT9vafurxe+iAhl9SDAdoZe

3RlshoItDQLW1ROlkLhM7Pdq/XZvLRm128hiIGKTDBnxtfN8TKAg+V7V+/TTfdqv

8jq7epvZsq5vjOC1FZh2gOhf50QwpqDJktjdyka1sPiBKQSoxfbZ

-----END RSA PRIVATE KEY-----

Resumindo os passos:

a) usando o certificado publico da mozilla para addons.mozilla.org para criptografar um arquivo:

$ openssl rsautl -encrypt -inkey public.pem -pubin -in verify.txt -out encrypted

b) usando o certificado privado divulgado pelo hacker (acima) para descriptografar:

$ openssl rsautl -decrypt -inkey private.pem -in encrypted -out decrypted.txt

c) verificando que os arquivos são iguais e portando a chave privada é válida:

$ md5sum verify.txt decrypted.txt

830ea5a732ec9c497d5999ca7b9575b2 verify.txt

830ea5a732ec9c497d5999ca7b9575b2 decrypted.txt

A "prova dos 9" está postada em http://erratasec.blogspot.com/2011/03/verifying-comodo-hackers-key.html

2) a tabela de hashes do RA italiano comprometido - como era esperado - já começou a ser crackeada (fonte):

Post Original (28/03/2011 - 03h30):

No ano passado, no post "Root DNS, CA e AS - uma questão de (des)confiança" - já havíamos alertado para as falhas estruturais que foram exploradas pelo(s) hacker(s) que emitiram certificados emitidos pela Comodo:

Os Root Certificates são a base do sistema de confiança de comunicações criptografadas de comércio eletrônico, personal banking, etc - São utilizados em comunicações criptografadas e pré-cadastrados e autorizados por sistemas operacionais e navegadores, que possuem listas independentes que são enviadas aos usuários sem sua anuência.

Num exemplo corriqueiro, uma vez que um certificado SSL/TLS seja apropriadamente assinado por um destes certificados raiz, ele passa a ser "confiável" e o usuário verá o cadeado ao lado da URL iniciada porhttps no navegador - gerando uma sensação de confiança que muitas vezes pode não corresponder à realidade. (..continua.. )

E foi exatamente isto que aconteceu.. Uma vez que um atacante possua um certificado assinado por uma root CA e por conseguinte aceito pelo browser do usuário - game over. Ataques do tipo MITM (man-in-the-middle) podem ser aplicados - vide demo com o sslstrip. O resultado: nem o usuário, nem o site que utiliza https não perceberão que sua comunicação "https" está sendo "aberta" e lida por um adversário.

Muito se especulou sobre como o ataque teria ocorrido e sobre a atribuição de responsabilidade:

- Iran targets Gmail and Skype with fake SSL hack (PCPro - UK)
- Hack Obtains 9 Bogus Certificates for Prominent Web Sites - Traced to Iran (Wired)
- Iranian Hackers Suspected in Recent Security Breach (New York Times)

A própria empresa atacada (Comodo) liberou dados sobre o comprometimento - resumindo:

- 9 certificados falsos foram emitidos: entre eles Microsoft Live (Hotmail), Yahoo, Skype, Google , Gmail, Mozilla Addons [ nota:

- Evidências (IPs) indicam que ataque veio do Irã. [ nota: conforme Bejtlich e Coppert, a atribuição mais precisa de responsabilidade para este tipo de ataque precisa considerar mais pontos, dentre eles: 1)Timing, 2)Vítimas,3)Origem, 4)Mecanismo de Entrada, 5)Vulnerabilidade ou Exposição, 6)Exploit ou Payload, 7)Weaponization,8)Atividade pós-exploração, 9)Método de Comando e Controle, 10)Servidores de Comando e Controle,11)Ferramentas, 12)Mecanismo de Persistência, 13)Método de Propagação, 14)Dados Alvo, 15)Compactação de Dados, 16)Modo de Extrafiltração, 17)Atribuição Externa, 18)Profissionalismo, 19)Variedade de Técnicas, e 20)Escopo.

- O foco do atacante foi a infra-estrutura de comunicação, e não financeira como em um cybercrime tradicional [ nota: realmente, o atacante poderia ter lucrado milhões emitindo certificados falsos de bancos por exemplo. A análise dos pontos 2-vítimas 14-dados alvo e 20-escopo dentre as possíveis atribuições listadas acima parecem indicar um ataque focado na monitoração de comunicações e possivelmente com interesse político e não econômico.]

- O atacante somente pode fazer uso dos certificados se controlar a infra-estrutura de DNS [nota: para uma capacidade de "grampo" nacional, sim [ nota: no caso da suspeita do envovimento do governo do Irã), mas ataques a estrutura de DNS de pequenos ISP até root-dns são possíveis.. ]

- O perpetrador executou seus ataques com precisão cirúrgica / O governo do Irã recentemente atacou outros métodos de comunicação criptografada. [nota: bons pontos, mas a dificudade de atribuir a responsabilidade a um Estado por ações como esta é constante e já observamos no caso do Aurora, e do StuxNet, por exemplo. ]

Até que - supostamente (a ser confirmado) - o próprio "hacker" publicou - hoje - um "manifesto" sobre detalhes do ataque, seus objetivos e motivações (e completa falta de modéstia =) .Para comprovar a autoria do incidente, mais tarde ele publicou partes do código decompilado da biblioteca "TrustDLL" do parceiro da Comodo.

Dentre os comentários do "ComodoHacker" - destaco:

- o RA (Registration Authority) invadido foi a italiana GlobalTrust.it / InstantSLL.it
- não há um grupo de hackers envolvido no ataque, somente ele (com a "experiência de 1000")
- ele cita que decidiu hackear o algoritimo RSA - mas não há evidências que o liguem ao ataque ao SecureID (que discutiremos mais abaixo neste post)
- ele reclama que muita atenção está sendo dada a este ataque e mais ninguém escreve sobre o StuxNet e o envolvimento de Israel e dos EUA aos ataques às centrífugas iranianas, e também reclama que a mídia não dá atenção aos projetos HAARP e Echelon..

O "hacker" termina sua carta com a seguinte frase: "Janam Fadaye Rahbar”, que significa “Eu vou sacrificar minha alma pelo meu líder".

Os ingredientes da história indicam que se tratou de um ataque com o objetivo de possibilitar uma fácil monitoração de comunicação encriptada com SSL e - independente de quem foi o responsável - um possível "cliente final" é o governo do Irã (aliás, qualquer governo interessado em monitorar a comunicação de seus cidadãos) .

Algumas reações ao que foi publicado pelo "ComodoHacker":

- The Comodo hacker releases his manifesto (ErrataSec)
- Solo Iranian hacker takes credit for Comodo certificate attack (ComputerWorld)
- How the Comodo certificate fraud calls CA trust into question (ArsTechnica)

Contramedidas:

A criptografia por sí não é útil sem a autenticação / confiabilidade dos dois lados da comunicação, e por isto os principais browsers (Chrome, Firefox, IE) já atualizaram suas blacklists com a lista dos certificados SSL fraudulentos. Esteja certo que você utiliza a última versão do seu navegador e habilite a checagem "verificar revogação certificado" / OCSP - Online Certificate Status Protocol.

O problema é que um atacante em condições de interceptar as comunicações https também pode impedir que o processo de validação das blacklists funcione adequadamente - enviando para o cliente um código 3 OCSP - try later.

Mais detalhes sobre isto pode ser visto na apresentação de Moxie Marlinspike na BlackHat de 2009, chamada "More Tricks For Defeating SSL In Practice" - (se estiver com pressa, veja a página 129) e outro bom material sobre o assunto aqui (revocation is useless). Como vocês podem ver, mais uma vez o Chrome (e agora o FF4) sai na frente no quesito segurança por suportar HSTS - o que ao menos gera um alerta ao usuário..

Como já informamos por aqui anteriormente, um passo é manter em seu browser apenas os certificados-raiz realmente necessários.

Um tweet recente do Moxie Marlinspike sugere aos possíveis responsáveis pelo ataque (os iranianos) que liberem os americanos Shane and Josh caso o Irã esteja usando a ferramenta dele (sslstrip) com o modo autoupdate para evitar o download de add-ons de segurança do firefox (em http://addons.mozilla.org).

Outras dicas de como evitar a utilização de certificados forjados pelo seu browser foram publicadas nos links a seguir:

- How to avoid fraudulent SSL (Verisign)

- Detecting Certificate Authority compromises and web browser collusion (TorProject)

Do ponto de vista corporativo, você pode monitorar os certificados SSL vistos no seu gateway internet e revisá-los, com ferramentas free como o Bro-IDS ou o NetWitness Investigator.

II) MySQL.com / Sun.com Blind SQL injection:

Casa de ferreiro.. como sabemos, o MySQL foi adquirido pela Sun e a Sun foi adquirida pela Oracle.

Pois bem, hoje foi publicada na lista Full Disclosure a exploração via Blind SQL Injection dos principais bancos de dados do site Mysql.com, e o mysql do site Sun.com também foi comprometido via SQLi.

Vale ressaltar que SQL Injection consta como 2o lugar na lista do MITRE/Sans (http://cwe.mitre.org/top25/) que divulga os 25 erros mais comuns em softwares.

Dentre os dados divulgados estão as tabelas, colunas e hashes de senhas (MD5) de usuários do site que já estão sendo crackeadas e publicadas.. O header dos dados segue abaixo:

Vulnerable Target : http://mysql.com/customers/view/index.html?id=1170
Host IP : 213.136.52.29
Web Server : Apache/2.2.15 (Fedora)
Powered-by : PHP/5.2.13
Injection Type : MySQL Blind
Current DB : web

Atribuição de Responsabilidade:

O ataque é atribuído ao duo de hackers romenos "TinKode" e "No0h".

Mais informações/repercussões sobre este ataque:

-
How Mysql.com and Sun.com got hacked<\a> Infoworld

- MySQL WebSite Hacked by (Ironically) Blind SQL Injection (HP/@Wh1t3Rabbit)

- MySQL.com and Sun hacked through SQL injection (Sophos)

- MySql.com compromised (Sucuri)

- MySQL.com compromised via SQL Injection attack. Someone should have read Chapter 6. (Securing SQL Server)

Inscreva-se no RSS Feed e receba atualizações automáticas

Brasília: SANS Mentor FOR508 - Advanced Computer Forensics Analysis and Incident Response

Sabemos que o mercado de Forense Computacional no Brasil vem amadurecendo a cada ano, mas infelizmente ainda vemos aqui e ali alguns "especialistas" divulgando ao público e à mídia informações incorretas ou atrasadas.

É por este motivo que faço questão de aproveitar este espaço para divulgar o que considero ser formação e informação de alta qualidade na área de Resposta a Incidentes e Forense Computacional.

Hoje descobri que o Marcelo Caiado, perito do MPF (e com experiência internacional em Forense Corporativa na RIM Canadá), estará ministrando em agosto na cidade de Brasília o curso  Advanced Computer Forensics Analysis and Incident Response". Como pré-requisito é preciso ter feito o curso FOR408 ou passar neste assessment do SANS. Highly Recommended!

Segue a mensagem do Marcelo sobre o assunto:

Informo que estão abertas as inscrições para o curso SANS Mentor FOR508 -Advanced Computer Forensics Analysis and Incident Response, a ser ministradoem Brasília todas as terças-feiras, das 19h às 21h, iniciando no dia 2 deagosto e finalizando no dia 4 de outubro de 2011. O valor total do curso,reduzido para o mercado local do Brasil, é de US$ 2.000,00 (o mesmo cursonos Estados Unidos sai por US$ 3.570,00).
Maiores informações podem ser obtidas no sítiohttp://www.sans.org/mentor/details.php?nid=25424 ou diretamente comigo. 

Atenciosamente,
Marcelo Beltrão Caiado, M.Sc., CISSP, GCFA, EnCE