[ 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.
- 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
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.
- 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.