Comodo, Diginotar, About.US, StartSSL, GlobalSign.. (CA/SSL) e NetNames (DNS) - ataques confirmam fragilidades conhecidas

[ Update 2011-11-29 ]


Uma análise detalhada do comprometimento de outra autoridade certificadora (desta vez a americana About.US) - foi publicada no blog eromang ontem.

Algumas informações:

O comprometimento ocorreu desde (pelo menos) 15 de setembro.. Uma vulnerabilidade do tipo RFI (Remote File Inclusion) foi explorada e um web php shell chamado "STUNSHELL" foi instalado em centenas de outros sites (sua listagem é possível através de um simples google dork presente no artigo do eromang. 

Mais detalhes no post abaixo:

http://eromang.zataz.com/2011/11/28/about-us-domain-names-registrar-owned/


[ Update 2011-10-31 ]

(At least) 4 web authentication authorities breached since June:

http://www.theregister.co.uk/2011/10/27/ssl_certificate_authorities_hacked/

(Além do ComodoGate, temos a Diginotar, StartSSL, GlobalSign, About.US, )

Em maio de 2010, publiquei por aqui um artigo entitulado "Root DNS, CA e AS - uma questão de (des)confiança". 


1) CA/SSL - Diginotar

Pois bem, nos últimos dias algumas das vulnerabilidades descritas neste artigo foram demonstradas em dois ataques reais - um a autoridade certificadora holandesa Diginotar e outro a empresa de registro de domínios (registrar) britânica NetNames. 

[ Update: 2011-09-15 ]

• Para testar se seu S.O. / browser está ou não confiando em certificados emitidos pela Diginotar, siga este link: https://www.balienet.nl/ <= a resposta esperada é que o certificado não é confiado / foi revogado - ex:"sec_error_revoked_certificate" no Firefox.

• No dia de ontem o governo holandês removeu a acreditação da Diginotar para emissão de "Qualified Certificates", que segundo uma diretivada União Européia possibilitam a utilização de certificados para assinatura digital com o mesmo valor legal de uma assinatura.

• Para uma lista de outros sites para testar se seu browser ainda confia na Diginotar nesta planilha do Google Docs  (aos poucos alguns vão tendo seus certificados substituídos)

• Um excelente resumo da ópera (incluindo atualizações nos comentários) pode ser encontrado no diário do ISC/Sans.

[ Post Original: 2011-09-05 ]

Em um caso parecido com o que ficou conhecido como "ComodoGate" (nosso post sobre o caso, aqui), uma Autoridade Certificadora "raiz" holandesa (Diginotar) - foi invadida  - há pelo menos um mês  -  e desde então foram emitidos mais de 500 certificados SSL fraudulentos (lista no formato .csv) - incluindo serviços como o Google (38), Mozilla (18), Microsoft (7) - além da agência de inteligência americana e israelense - CIA (25) e Mossad - do TorProject (14), Twitter, Facebook, Yahoo, Skype, entre outros..

A empresa atingida administra várias CAs (Certification Authorities), que foram configuradas sobre um mesmo Domínio Windows - facilmente comprometido (segundo o hacker a senha do Administrador do Domínio foi "fácil de quebrar": Pr0d@dm1n). Dezenas de CAs foram afetadas, e as seguintes CAs foram utilizadas para a geração de certificados fraudulentos:

• DigiNotar Cyber CA
• DigiNotar Extended Validation CA
• DigiNotar Public CA - G2
• DigiNotar Public CA 2025
• Koninklijke Notariele Beroepsorganisatie CA
• Stichting TTP Infos CA

Um efeito colateral do ataque foi deixar inoperantes alguns serviços do governo holandês que dependiam de criptografia SSL.

Como já informamos aqui no post anterior, toda a movimentação aconteceu depois de um usuário avançado iraniano questionar sobre um certificado "esquisito" e seu alerta no Chrome - em um fórum de suporte do Google - incluindo um dump do certificado suspeito - txt / zip (.cer e .jpg). Veja também o post do blog de Segurança do Google sobre o assunto, motivado por este heads-up..

Assim como no caso do ComodoGate, desde o início apareceram evidências que apontavam mais uma vez para o governo Iraniano, que estaria emitindo estes certificados fraudulentos para podem monitorar (através de ataques man-in-the-middle) as comunicações criptografadas com SSL trafegados pelo povo iraniano a partir da monitoração dos provedores de internet deste país (Estamos falando de 300 mil endereços IPs únicos afetados por este ataque). Assim como a China, o governo Iraniano controla fortemente a Internet no país.

Não são somente evidências - há uma confirmação. O usuário ichsunx2 - do Twitter, se responsabilizou pelo ataque, divulgado neste link do pastebin - usando a conta - já conhecida - "ComodoHacker" (outras 2 entradas foram adicionadas no dia 6).

Detalhe: como pode ser visto no nosso post sobre o ComodoGate, o usuário que se responsabilizou pelo incidente com a Comodo foi o "ichsunx". Ele chega a afirmar que possui acesso administrativo a quatro autoridades certificadoras.. Mais uma vez é utilizada a expressão "Janam Fadaye Rahbar”, que significa “Eu vou sacrificar minha alma pelo meu líder" - em persa. Mais informações sobre o hacker podem ser vistos nesta reportagem no NY Times.

O objetivo parece ser o mesmo de antes, possibilitar ao governo iraniano a monitoração de comunicação criptografada com SSL. Sobre a escolha da CA a ser atacada, o hacker iraniano chega a citar um incidente militar ocorrido há 16 anos atrás, durante a guerra da Bósnia, chamado de massacre de Srebrenica (no qual 30 soldados holandeses foram trocados por 8000 muçulmanos bósnios - que foram assassinados pelos sérvios.)

Um vídeo que mostra as requisições efetuadas com certificados fraudulentoss do Google nos últimos dias pode ser visto nesta animação feita pela FoxIT (Youtube) - Fica claro o país com mais máquinas afetadas - Irã (os pontos fora do país são principalmente nós de saídas do TOR e conexões VPN e via proxy). Isto foi possível devido a checagem de revogação (OSCP) feita por browsers modernos assim que é feita uma conexão a um site protegido pelo protocolo HTTPS.

Além da leitura de emails do GMail (e de poder resetar senhas de outros serviços(*) , um atacante pode ter obtido acesso a todos os outros serviços da empresa (Docs, Google+, Latitude, etc..), pois foi possível obter o "cookie de login" do google..

Normalmente os usuários podem configurar se confiam ou não em uma "root CA" - conforme descrito neste link par o caso em pauta, usando o browser Firefox. Para dicas de como fazer isto no Windows, veja aqui.

A resposta das empresas que desenvolvem browsers e sistemas operacionais que tem listas de CA's a serem confiadas - e por extensão certificados por ela assinados também o são -  foi variada: o Google, a Mozilla e Microsoft responderam revogando certificados e até mesmo a entrada da Diginotar em updates de segurança. Já a Apple até o momento deixa seus usuários a mercê sem uma atualização ou mesmo comentário sobre o assunto.

Pra quem usa Firefox, recomendo fortemente a utilização de um plugin que proporcione um maior controle quanto à confiança de autoridades certificadoras. Sugestões: Covergence , Certificate Patrol e CA-Knockout.  

 Para mais detalhes sobre as fragilidades do sistema atual e alternativas - veja a palestra de Moxie MarlinSpike na última Black Hat (Youtube -  "SSL And The Future Of Authenticity")


Mais informações relevantes já publicadas no post supra-citado:

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.

O CERT do governo holandês (GOVCERTNL) publicou informações sobre o incidente, incluindo o fato de ter tomado a frente da gestão da empresa comprometida. Vale a pena ler o relatório preliminar sobre o incidente - veja este PDF (FoxIt).



2) DNS - NetNames:

No tocante a ataques relacionados a DNS, nada tão sério quanto a modificação de registros DNS feita pelo governo chinês e comentada neste post - mas uma lembrança da importância de se manter segura a administração e configuração de servidores DNS.

Um grupo de defacers turco chamado TurkGuvenligi alterou a configuração de resolução DNS de vários domínios:  - redirecionando acessos dos seguintes sites para uma página do grupo:

• www.telegraph.co.uk
• www.vodafone.com
• www.acer.com
• www.ups.com
• nationalgeographic.com
• www.theregister.co.uk

Todos os sites são administrados pelo registrar NetNames - a empresa informou que foi vítima de um ataque de SQL Injection na sua interface administrativa. Devido à natureza do DNS, mesmo depois da correção das entradas que foram alteradas, foi necessário esperar a propagação dos endereços IPs corretos ocorrer por vários servidores DNS espalhados pelo mundo até que os sites voltassem a responder corretamente.

Observação - o grupo TurkGuvenligi é o mesmo que fez um 'defacement' no site da Microsoft Brasil há dois meses atrás.