Os maiores ataques de negação de serviço (DDoS) da História - 600Gps, 500Gbps, 400Gbps e 300Gbps

Update 17/10/2020:

Ataque da China ao Google de 2.54Tbps (em 2017).

https://www.zdnet.com/google-amp/article/google-says-it-mitigated-a-2-54-tbps-ddos-attack-in-2017-largest-known-to-date/

Ataque: 600Gbps (a se confirmar): 

  [ Update - 03/01/2016 ]

Hacktivistas do grupo "New World Hacking" atacaram o site de Donald Trump e o da BBC, utilizando a estrutura da AWS (cloud da Amazon) e alegam ter efetuado ataques de Negação de Serviço superiores a 600Gps: 

http://www.zdnet.com/article/attackers-targeting-bbc-donald-trump-amazon-web-services/

 [ Update - 20/11/2014 ]

Ataque: 500Gbps (a se confirmar):  

 

O governo Chinês é o principal suspeito dos maiores ataques de negação de serviço já registrados na história, com a impressionante marca de 500Gpbs. Sites independentes de notícias de Hong Kong estão sendo alvo de ataques continuados durante os últimos meses, em paralelo aos protestos "Hong Kong Occupy Central" que ocorrem nas ruas da cidade-estado.

Os ataques estão alcançando esta força através da utilização de ataques de reflexão (DRDoS) em milhares de servidores de DNS. Para se ter uma idéia, o número de requisições forjadas de DNS que estão sendo feitas por segundo durante estes ataques chega a 250 milhões - o mesmo valor das requisições válidas feitas por segundo na Internet do mundo todo.

Mais informações:

http://www.forbes.com/sites/parmyolson/2014/11/20/the-largest-cyber-attack-in-history-has-been-hitting-hong-kong-sites/

Ataque: 400Gbps (confirmado):

[ Update - 13/02/2014 ]

Como sabemos, Ataques Distribuídos de Negação de Serviço (DRDoS) são um problema conhecido há anos e o DNS é o protocolo mais tradicionalmente utilizado para se perpetrar este tipo de ataque - mas o DNS não está sozinho, e nem é mais o mais perigoso.

Há alguns anos, tive a oportunidade de ser um dos revisores das primeiras versões de um material muito interessante sobre o assunto, chamado "Recomendações para Evitar o Abuso de Servidores DNS Recursivos Abertos" - criado e mantido pelo CERT.BR (Cristine Hoepers, Klaus Steding-Jessen, Nelson Murilo, Rafael R. Obelheiro): http://www.cert.br/docs/whitepapers/dns-recursivo-aberto/

Uma lista de openresolvers de DNS pode ser encontrada em: http://openresolverproject.org/

Hoje em dia ferramentas automatizadas como o "DNS Flooder" possibilitam que ataques deste tipo sejam efetuados com muita facilidade: http://www.prolexic.com/knowledge-center-ddos-threat-advisory-dns-flooder.html

Existem outros protocolos UDP que também são (ou podem) ser utilizados para perpetrar ataques de DRDoS. Uma listagem recente é a seguinte (fonte: Alerta de 17/01/2014 do US-CERT: http://www.us-cert.gov/ncas/alerts/TA14-017A): DNS , NTP ,SNMPv2 ,NetBIOS, SSDP, CharGEN, QOTD, BitTorrent, Kad, Quake, Steam

O número 2 da lista acima (NTP - Network Time Protocol) foi utilizado em um ataque de 400Gb/s DRDoS ocorrido esta semana, que está sendo considerado o maior do mundo.

Detalhes sobre o "maior ataque de Denial of Service da história" no blog da Cloudflare (obrigado ao Anchises pelo link): http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack

Versões do server NTP do ntp.org anteriores a 4.2.7p26 estão vulneráveis e precisam ser corrigidas com urgência: http://support.ntp.org/bin/view/Main/SecurityNotice#DRDoS_Amplification_Attack_using

Advisory recente do US-CERT sobre ataques DDoS utilizando NTP para reflexão: http://www.us-cert.gov/ncas/alerts/TA14-013A

NTP Scanning Project - http://openntpproject.org/

O RIPE/NCC publicou recentemente um artigo do Jonh Christoff do Team Cymru (parceiro da Apura), chamado ""https://labs.ripe.net/Members/mirjam/ntp-reflections

Um relatório interessante sobre o assunto (e correlatos) foi publicado pela Arbor recentemente:

http://www.arbornetworks.com/resources/infrastructure-security-report (Só o infográfico mostrando o tamanho dos ataques em uma linha do tempo pode ser visto em: http://pages.arbornetworks.com/rs/arbor/images/AttackSize_final_white.pdf

Ataque: 300Gbps (confirmado):

[ Update - 28/04/2013 ]

Aproximadamente um mês depois dos ataques, o principal suspeito de orquestar os ataques foi preso na Espanha, enquanto viajava em uma van que servia de "escritório móvel". Trata-se de Olaf Kamphuis, holandês de 35 anos e se auto-entitulou  "ministro das telecomunicações e relações exteriores da República de CyberBunker".

[ Post Original - 28/03/2013 ]

A "grande mídia" começou a cobrir com mais frequência incidentes relacionados à cibersegurança, e hoje várias fontes publicaram notícias sobre os efeitos de ataques que foram motivados pela briga entre duas empresas holandesas, a SpamHaus (que mantém listas para bloqueios de spam) e a CyberBunker (cb3rob) que hospeda vários spammers e possui como um de seus clientes a WikiLeaks.

• New York Times: Firm Is Accused of Sending Spam, and Fight Jams Internet
• BBC: Global internet slows after 'biggest attack in history'
• CNN: Massive cyberattack hits Internet users / What you need to know about the world’s biggest DDoS attack
• Washington Post: Ripple effects across Web as spam-blocking group Spamhaus hit by record-smashing cyberattack

Como o assunto começou a ser também comentado aqui no Brasil, resolvi escrever este breve post sobre o caso em pauta.

Ataques Distribuídos de Negação de Serviço (Distributed Denial of Service - DDOS) são uma realidade - e um problema - na Internet há muito tempo. Eles ocorrem diariamente, mas geralmente não tem um efeito noticiável nas redes e computadores que não são alvos ou origem dos ataques distribuídos. O mais importante é antes de mais nada deixar claro que um ataque de negação de serviço não "invade" os computadores e redes afetados, mas impede que eles se comuniquem, tendo um efeito desastroso na disponibilidade de serviços online.

O ataque não foi o maior ataque já ocorrido na internet (entre outros exageros que foram publicados), mas por ser o maior DDOS já ocorrido, tem importância única e merece destaque. Um outro ponto importante a  se cosiderar é que existe uma dificuldade significativa na atribuição de responsabilidade em ataques de negação de distribuídos, especialmente pelo volume de origens utilizadas (usualmente botnets ou farms de servidores em nuvem) e pela possibilidade de se forjar (spoofar) os endereços de origem em certos tipos de ataque (mais informações abaixo). Infelizmente nem todas as redes configuram adequadamente seus equipamentos para evitar este tipo de "falsificação" do endereço de origem.

Este tipo de ataque é também muito utilizado por hacktivistas para protestar contra empresas ou contra o governo (há  inclusive uma tentativa de legalizar deste tipo de ataque como protesto nos Estados Unidos e na Inglaterra). Há também quem julgue que este tipo de ataque é uma forma de censura, por "calar" o inimigo à força. 


As legislações de vários países consideram este tipo de ataque um crime, incluindo a nova legislação que cobre os chamados "crimes eletrônicos", que entrará em vigor na semana que vem em Brasil.  

Lei n° 12.737 :


Art. 3o  Os arts. 266 e 298 do Decreto-Lei no 2.848, de 7 de dezembro de 1940 - Código Penal, passam a vigorar com a seguinte redação:  

“Interrupção ou perturbação de serviço telegráfico, telefônico, informático, telemático ou de informação de utilidade pública 

Art. 266.  ........................................................................ 

§ 1o  Incorre na mesma pena quem interrompe serviço telemático ou de informação de utilidade pública, ou impede ou dificulta-lhe o restabelecimento.  

§ 2o  Aplicam-se as penas em dobro se o crime é cometido por ocasião de calamidade pública.” (NR)  


Existem várias técnicas diferentes que podem ser utilizadas para efetuar um ataque do tipo DDOS, incluindo a utilização de Botnets (criadas ou alugadas), a utilização de "Booters" como no caso recente ataque ao site do BrianKrebs, a utilização de ferramentas com o consentimento do usuário para ataques de grupos (como o Hoic/Loic), entre outros. Entre todas elas, a mais eficiente foi a utilizada neste caso.

[ Ataques de Negação de Serviço Distribuídos utilizando Servidores DNS Recursivos Abertos ]

No caso em pauta (a briga entre duas empresas holandesas), de um lado temos a SpamHaus  - responsável por lutar contra os spammers, através de blacklists utilizadas por grande parte dos servidores de email do mundo para evitar spams de redes reconhecidamente problemáticas, e de outro o CyberBunker (também conhecida como cb3rob)- empresa de hospedagem que é um paraíso para spammers e outros cibercriminosos - seus termos de uso só banem a pornografia infantil e o terrorismo, o resto vale!

A CyberBunker (e outros participantes coordenados em uma operação chamada #OpStopHaus / site) estava se sentindo incomodado pela frequente inclusão de suas redes nas listas negras da SpamHaus, e decidiu reagir de forma bastante ruidosa.  A CyberBunker e seus aliados alegam que a SpamHaus na verdade apenas finge lutar contra o spam, mas o que fazem é censura e que usam "táticas mafiosas" (este link inclui vídeo da CyberBunker falando sobre os ataques).

Um ponto importante sobre a transnacionalidade deste tipo de problema (/incidente/crime) - no ataque em pauta, o principal suspeito (CyberBunker), ao ser perguntado sobre a investigação que está sendo feita por vários países que consideram o ataque ilegal, o porta voz da empresa disse que todos que efetuaram (não necessariamente quem planejou) os ataques não estão em países onde ataques de DDoS são ilegais - CyberBunker entrevistada (no final deste vídeo).

O ataque massivo de DDOS teve como o alvo o site da SpamHaus e se iniciou no dia 18 de março, mas nos dias subsequentes ele cresceu muito, a ponto de gerar lentidão na comunicação de algumas redes em diferentes lugares do mundo. Os ataques que inicialmente se direcionavam à SpamHaus (dia 19, 75Gbs) foram progredindo para seus fornecedores de conectividade (upstream providers) e chegaram até as redes que formam a infraestrutra de conectividade da internet (IX - internet exchange). Na imagem abaixo, divulgada pela CloudFlare, é visível o efeito do ataque no London Internet Exchange (também foram afetados os IX de Amsterdam, Frankfurt e Hong Kong. No pico do ataque o trhoughput foi de 300Gbps (300 Gigabytes por segundo).

No dia 20, a empresa chegou a comemorar a resolução do problema com o post The DDoS That Knocked Spamhaus Offline (And How We Mitigated It) - detalhes abaixo (as ênfases foram incluídas por mim): 


"In the Spamhaus case, the attacker was sending requests for the DNS zone file for ripe.net to open DNS resolvers. The attacker spoofed the CloudFlare IPs we'd issued for Spamhaus as the source in their DNS requests. The open resolvers responded with DNS zone file, generating collectively approximately 75Gbps of attack traffic. The requests were likely approximately 36 bytes long (e.g. dig ANY ripe.net @X.X.X.X +edns=0 +bufsize=4096, where X.X.X.X is replaced with the IP address of an open DNS resolver) and the response was approximately 3,000 bytes, translating to a 100x amplification factor.

We recorded over 30,000 unique DNS resolvers involved in the attack. This translates to each open DNS resolver sending an average of 2.5Mbps, which is small enough to fly under the radar of most DNS resolvers. Because the attacker used a DNS amplification, the attacker only needed to control a botnet or cluster of servers to generate 750Mbps -- which is possible with a small sized botnet or a handful of AWS instances. It is worth repeating: open DNS resolvers are the scourge of the Internet and these attacks will become more common and large until service providers take serious efforts to close them."

Ou seja a CloudFlare - ao redirecionar os pacotes que tinham como endereço os IPs do alvo (SpamHaus) para múltiplos IPs espalhados em vários continentes, aliviou o efeito do ataque e permitiu uma melhor conectividade para as redes próximas ao alvo, mas (potencialmente) afetou as demais redes para onde o tráfego foi redirecionado. Isto normalmente nem é percebido para ataques menores, mas este ataque de 300Gbps, foi diferente.

Para o ataque foram utilizados 30.000 servidores DNS "open resolvers". Segundo o Open Resolver Project, já foram mapeados quase 27 milhões de servidores DNS open resolvers na Internet. Curiosamente, nas últimas 12 horas, o CyberBunker está indisponível mas o SpamHaus continua online.

Algumas fontes de notícias tem exagerado nos efeitos deste ataque à SpamHaus, aumentando sua importância para a internet como um todo - alguns estão o chamando de "bomba nuclear digital", entre outros exageros. De qualquer forma, se considerarmos que o último maior ataque DDoS foi de cerca de 10Gbps, é um ataque significativo, sim - e certamente efeitos colaterais foram sentidos.

Vale lembrar que ataques DDOS em servidores de DNS raiz já tiveram um efeito (este sim, devastador) por duas vezes na história da internet - em 2002 e 2007.

Um vídeo muito interessante sobre ataques de negação de serviço distribuídos utilizando amplificação de DNS foi feito pelo Team Cymru (também parceiro da Apura):




[ Mitigação / Defesa ]

Além dos serviços de mitigação comerciais existentes - O que mais podemos fazer antes de um ataque de negação de serviço para se preparar para ter resiliência durante a execução dele? 

I - Cheat Sheet - Neste mês publicamos por aqui as Metodologias de Resposta a Incidentes publicadas pelo CERT da Société Générale, incluindo o "IRM-4 : Distributed Denial of Service" (PDF)

II - O pessoal da Whitehat Security publicou um "DDoS RunBook" (formato .docx)  para auxiliar as empresas a se prepararem para este tipo de incidente de segurança, criando um plano de resposta. Se você faz parte de um time de segurança da informação ou CSIRT, recomendo.

III - RFC 5358-  Preventing Use of Recursive Nameservers in Reflector Attacks

IV - US CERT - Alert (TA13-088A) DNS Amplification Attacks

V - Em 2007 eu tive a oportunidade de fazer sugestões e revisar um excelente documento produzido pelo CERT.BR, entitulado "Recomendações para Evitar o Abuso de Servidores DNS Recursivos Abertos". O documento foi atualizado esta semana devido aos ataques em pauta - vale a leitura.


A descrição dos passos do ataque pode ser vista nos parágrafos e imagem abaixo:

"Uma das técnicas de DDoS utilizadas atualmente envolve a exploração de servidores DNS recursivos abertos, para gerar grandes quantidades de tráfego de resposta DNS para uma vítima cujo endereço IP está sendo forjado.

Um dos problemas fundamentais explorado nesses ataques é o fato do sistema de DNS utilizar UDP (Internet User Datagram Protocol) como protocolo principal de comunicação. Como este protocolo não requer o estabelecimento de uma sessão entre o cliente e o servidor e não possui métodos de autenticação, fica facilitada a ação de forjar a origem de uma consulta DNS.

1 - O atacante publica um registro muito grande, em geral TXT, em um servidor DNS sob seu controle (muitas vezes esse pode ser um servidor previamente comprometido pelo atacante).

2 - O atacante, de posse de uma lista de servidores DNS recursivos abertos, envia a estes servidores centenas ou milhares de consultas pelo registro publicado no passo 1, forjando o endereço IP da vítima, ou seja, colocando o endereço IP da vítima como endereço de origem da consulta (2a). Deste modo, o atacante faz com que as respostas sejam enviadas para a vítima e não para a máquina que fez as consultas. Na primeira consulta recebida por um servidor recursivo este vai buscar a resposta no servidor controlado pelo atacante (2b), nas demais consultas a resposta será enviada diretamente do cache do servidor recursivo aberto.

Em diversos casos documentados as consultas feitas à lista de servidores abertos foram realizadas por uma grande quantidade de bots, o que em geral aumenta ainda mais o volume de tráfego sendo enviado para a vítima.

3 - A vítima recebe as respostas DNS, que costumam gerar uma amplificação de aproximadamente 10 a 80 vezes o tráfego inicial de consultas, pois, para uma consulta média de aproximadamente 50 bytes, podem ser retornados cerca de 4.000 bytes de resposta para a vítima."

Para solucionar o problema dos servidores DNS recursivos abertos é necessário separar os servidores autoritativo e recursivo e atribuir políticas de acesso diferentes a cada um. Isto pode ser feito de duas maneiras:

Colocando os servidores DNS em computadores diferentes, com configurações e políticas de acesso diferentes; ou Utilizando o conceito de views (visões ou vistas) do BIND 9 (Berkeley Internet Name Domain versão 9).

Para a lista completa de sugestões de mitigação para servidores DNS (BIND9 e Microsoft DNS), veja as instruções técnicas diretamente o site do CERT.BR.

VI - Uma dica valiosa para empresas/órgãos preocupados em não participar deste tipo de ataque por possuir servidores mal configurados em suas redes é fornecida no documento do CERT.BR (I) . Trata-se do serviço disponibilizado pelo "DNS Factory" - http://dns.measurement-factory.com/cgi-bin/openresolverquery.pl, onde qualquer um pode solicitar que a lista dos Open Resolvers sobre sua responsabilidade sejam enviadas para os emails de contato (RFC 2142) das redes em questão. (Uma alternativa interessante ao DNS Factory é o DNSInspect).

VII - Dicas importantes de mitigação utilizando DNS rate limit podem ser vistas no site da CloudShield: "3 Ways to Use DNS Rate Limit Against DDoS Attacks" 

VIII - A Radware publicou um "DDoS Survival Handbook" - muito útil também.

IX - O Team Cymru possui uma página sobre configuração segura de DNS e  publicou um interessante documento sobre o histórico dos ataques de DDOS: http://www.team-cymru.com/ReadingRoom/Whitepapers/2010/ddos-basics.pdf

[ Outras leituras recomendadas sobre o tópico - além das já linkadas no post ]

Português:

• O ‘maior ataque cibernético’ e outro grande exagero da imprensa  - excelente cobertura do assunto feita pelo Altieres, que me mandou a URL assim que publiquei o artigo - mais que recomendado)
• O maior ataque de todos os tempos... da última semana - ótimo post do Anchises sobre o assunto. (e  update)

Espanhol:

• CloudFlare, Batman esta en la ciudad  - Davi Barroso

Inglês:

• Chronology of a DDoS: SpamHaus (Cisco)
• When spammers go to war: Behind the Spamhaus DDoS (ArsTechnica)
• Q&A: Massive denial of service attack hits SpamHaus (LastWatchDog)
• Spamhaus DDoS Attacks Triple Size of Attacks on US Banks (ThreatPost)
• Spamhaus DDoS grows to Internet-threatening size (ArsTechnica)
• Distributed Denial of Service (DDoS) Attacks/tools (Dittrich)
• DDoS Attack Doesn't Spell Internet Doom: 7 Facts (InformationWeek)
• Looking at the SpamHouse DDoS from a BGP perspective (BGPMon)

DNSSEC - Antes tarde do que nunca

[ Update 22/03/2014 ]

Três anos depois, parece que o "nunca" ganhou do "antes tarde"?

DNSSEC Has Failed

O autor do artigo acima tem razão em alguns pontos, especialmente o que tange a complexidade da implementação adequada do DNSSEC ("To enable DNSSEC we have a “tutorial” by Olaf Kolkman which spans a whopping sixty-nine pages. DNS engineers can get trainings, which always take multiple days.")

[ Update 20/11/2011 ]

Seguem alguns sites que podem ser usados para verificar o status de implementações de DNSSEC (incluindo delegações / cadeia de autenticações / etc.. )

1. Sandia Laboratories: http://dnsviz.net/
2. IIS.SE: http://dnscheck.iis.se
3. Verisign: http://dnssec-debugger.verisignlabs.com/

[ Update: 31/05/2010 ]

Atenção administradores de DNS Recursivos brasileiros - reproduzo abaixo informações de configuração DNSSEC postadas no GTS por Frederico Neves do registro.br incluindo a nova KSK key da zona .br:

Senhores(as),

Conforme a nossa "Política de publicação e administração de chaves DNSSEC" [1], desde 31/05/2010 estamos utilizando uma nova chave KSK para a zona .br. A nova chave com key id 41674 juntamente com exemplos de configuração para BIND e UNBOUND pode ser obtida abaixo [3] ou em nosso site [2].

A chave em uso desde 24/06/2008, com key id 18457, deixará de ser utilizada a partir de 26/07/2010.

Se você administra servidores DNS recursivos que estejam com DNSSEC habilitado, não se esqueça de atualizar a chave do .br na configuração de seu servidor. A substituição da chave ancorada em seu servidor DNS pela nova KSK do .br deve ser feita antes do final do período de rollover, que se encerra em 26/07/2010.

É esperado que este seja o último rollover manual uma vez que a raiz será assinada em breve e as próximas trocas de chaves serão efetuadas de forma automática.

Atenciosamente,
Frederico Neves

[1] http://registro.br/info/dnssec-policy.html
[2] https://registro.br/ksk/index.html
[3]
*DNS RR
br. IN DNSKEY 257 3 5 (
AwEAAblaEaapG4inrQASY3HzwXwBaRSy5mkj7mZ30F+h
uI7zL8g0U7dv7ufnSEQUlsC57OHoTBza+TQIv/mgQed8
Fy4XGCGzYiHSYVYvGO9iWG3O0voBYy/zv0z7ANfrA7Z3
lY51CI6m/qoZUcDlNM0yTcJgilaKwUkLBHMAp9NJPuKV
t8A7OHab00r2RDEVjiLWIIuTbz74gCXOVfAmvW07c8c=
) ; key id = 41674


*BIND trusted-keys config
trusted-keys {
br. 257 3 5
"AwEAAblaEaapG4inrQASY3HzwXwBaRSy5mkj7mZ30F+h
uI7zL8g0U7dv7ufnSEQUlsC57OHoTBza+TQIv/mgQed8
Fy4XGCGzYiHSYVYvGO9iWG3O0voBYy/zv0z7ANfrA7Z3
lY51CI6m/qoZUcDlNM0yTcJgilaKwUkLBHMAp9NJPuKV
t8A7OHab00r2RDEVjiLWIIuTbz74gCXOVfAmvW07c8c=";
};


*UNBOUND trust-anchor config
trust-anchor: "br. DS 41674 5 1 EAA0978F38879DB70A53F9FF1ACF21D046A98B5C"

[ Update: 06/05/2010 ]

A mudança de chave para o DNSSEC do último dos 13 root DNS servers foi ontem. A partir de agora todos respondem com uma versão assinada da root zone. A validação das assinaturas ainda não é possível pois as chaves públicas só serão disponibilizadas durante uma cerimônia (txt ICANN) em julho desde ano.

Mais informações:

http://www.h-online.com/security/news/item/DNSSEC-on-all-root-servers-994744.html

Posts Relacionados:

• Root DNS, CA e AS - uma questão de (des)confiança
• (mais uma) Falha no protocolo DNS descoberta
• Telefônica sofre ataques de negação de serviço (DDOS)
• Trojan DNSChanger - v4

[ Post Original: 21/01/2010 ]

Na próxima semana a Verisign iniciará a configuração do DNSSEC para os domínios .com e .net (2 root servers). O processo envolverá inicialmente todas as empresas e entidades responsáveis pelos 13 root servers e esta fase inicial deve durar até julho deste ano.

O DNS - Domain Name Service - (udp/tcp 53) é um dos protocolos mais importantes da Internet - por ser responsável por resolver os endereços IP aos quais os computadores devem se conectar, a partir de um banco de dados distribuído. É ele que permite que você somente precise se lembrar de nomes simples para acessar utilizar a internet (www.google.com - em vez de 72.24.204.99 ou 2001:4860:0:1001::68 para ipv6).

As RFCs 282 e 283 definiram a implementação DNS em 1982, e depois várias outras detalharam ou alteraram especificações relacionados ao protocolo e/ou serviço DNS - e podem ser verificadas no seguinte link: http://www.dns.net/dnsrd/rfc/.

Num exemplo claro de que as mudanças nem sempre são rápidas quando se trata de segurança - o DNSSEC foi primeiramente proposto em 1997, na RFC 2065.

Em resumo, as extensões DNSSEC oferecem 3 novos record types que trazem mais segurança ao protocolo e indiretamente aos serviços da internet e à sua navegação:

1) processo de distribuição de chaves (KEY/DNSKEY),

2) a certificação da origem de dados (SIG/RRSIG) e,

3) a certificação de transações e requisições (NXT/NSEC).

Ou seja, o DNSSEC pretende proteger a integridade dos dados DNS e garantir que as informações estão vindo da origem correta:

1) os domínios da internet podem se assegurar que eles que somente eles são os responsáveis pelas informações de resolução dos sites que possuem, e

2) usuários - que ao navegar automaticamente fazem resoluções DNS - podem verificar que o resultado obtido veio de uma origem confiável.

Por estes motivos, o DNSSEC é considerada a melhor solução para melhorar a segurança deste serviço fundamental e eliminar o problema de envenenamento de caches DNS (DNS cache Poisoning) - que como sabemos é um ataque muito comum e efetivo hoje.

Em 2007, eu tive a oportunidade de revisar um paper publicado pelo CERT.BR que trata entre outras coisas - de DNS Poisoning - segue o link: http://www.cert.br/docs/whitepapers/dns-recursivo-aberto/.

Além disto publicamos em 2008 uma série de updates sobre a falha descoberta por Dan Kaminski que facilita as explorações de DNS Poisoning utilizando birthday attack. (desde então ele faz uma campanha defendendo a adoção do DNSSEC).

Os efeitos de ataques em servidores DNS são inúmeros, incluindo:

1) Ataque de Negação de Serviço Abusando de Servidores DNS Recursivos Abertos - detalhes aqui.

2) "falso-deface": pois o usuário ao digitar o endereço do site - e resolver o endereço IP no servidor DNS que sofreu o envenenamento - será redirecionado para outro servidor sobre controle do hacker (como foi o caso do Twitter no final de 2009)

3) golpes de phishing em massa ( ou pharming ): ou seja, sem utilização de código malicioso no cliente, que tem o seu servidor de DNS envenenado redirecionando sites de instituições financeiras para outro endereço IP - controlado pelo hacker - era muito comum no Brasil de 2002 a 2005 e ainda é existente por aqui e pelo mundo.

Com relação ao DNSSEC, sabemos que este tipo de alteração em um serviço tão fundamental da internet deve idealmente envolver todos os administradores de DNS's.

Quem já cansou de esperar por 13 anos - desde a primeira RFC que tratou do assunto - pode estar entre os "early adopters" ou - é claro - esperar mais 6 meses - quando todos os root servers estarão OK - para iniciar o trabalho de assinar as zonas, e gerenciar as chaves criptográficas envolvidas nas comunicações entre os resolvers e os servers.

Os passos naturais para tanto são: geração das chaves criptográficas (pública e privada), update do arquivo de zona, configuração de resolver c/ forwarding, publicação da zona e verificação da nova zona assinada.

A tendência natural é que grandes sites adotem o DNSSEC mais rapidamente, para garantir uma maior segurança para eles próprios e para os seus usuários.

Mais informações:

Para acompanhar a evolução da adoção do DNSSEC pelos root servers, acesse http://www.root-dnssec.org/. Para detalhamentos técnicos, visite a seção de documentos:

Este é o timeline previsto:

• December 1, 2009: Root zone signed for internal use by VeriSign and ICANN. ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK.
• January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). The DURZ contains unusable keys in place of the root KSK and ZSK to prevent these keys being used for validation.
• Early May, 2010: All root servers are now serving the DURZ. The effects of the larger responses from the signed root, if any, would now be encountered.
• May and June, 2010: The deployment results are studied and a final decision to deploy DNSSEC in the root zone is made.
• July 1, 2010: ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys – The signed root zone is available.

É claro que sobra muito espaço ainda para melhoria no DNSSEC e algumas questões precisam ser mais bem trabalhadas, como ataques "Man-in-the-middle" com spoofing, a questão da necessidade de se confiar no resolver, ataques de negação de serviço e dados não encriptados, por exemplo.

Obviamente as preocupações tradicionais de segurança continuam valendo para o DNSSEC - e as principais são manter o serviço instalado de forma adequada e no último patch level possível.

Recentemente foi divulgada uma falha na implementação do DNSSEC pelo BIND (advisory aqui) - que já foi corrigida. As versões atualmente recomendas são: 9.4.3-P5, 9.5.2-P2 or 9.6.1-P3.

Uma excelente discussão e o status da implementação do DNSSEC no Brasil dado pelo Frederico A C Neves do Registro.BR você pode verificar neste vídeo "DNSCurve X DNSSEC" - do FISL 10 (Obrigado Zucco pela dica nos comentários!).

Trojan Zlob/DNSChanger altera configurações de routers

[ Update: 09/07/2012 ]


Há mais de quatro anos começamos a escrever por aqui algumas informações relacionadas ao DNSChanger (este foi o primeiro post deste blog).

Como hoje (09/07/2012) foi o dia em que o FBI deixou de resolver as requisições feitas por máquinas e roteadores que tiveram suas configurações de DNS alteradas pelo DNSChanger, vale a pena adicionar alguma informação por aqui:


- Um excelente vídeo resumindo toda a história de uma forma extremamente didática foi publicado pela Sophos recentemente:
http://nakedsecurity.sophos.com/2012/07/06/dnschanger-how-not-to-lose-your-internet-connection-on-july-9/

- O real impacto foi realmente bastante pequeno (civom certeza nem um pouco pequeno para os que foram afetados efetivamente, mas longe do exagero divulgado pelo mídia "especializada").

1. http://www.pcmag.com/article2/0,2817,2406855,00.asp?kc=PCRSS05079TX1K0000992
2. http://www.itnews.com.au/News/308075,dnschanger-shutdown-misses-internet-doomsday.aspx
3. http://news.cnet.com/8301-1009_3-57468797-83/dnschanger-apocalypse-like-y2k-but-even-snoozier/

Os apocalípticos podem buscar agora um outro final do mundo para esperar, talvez o dos Maias, talvez o bug do ano 2038 (http://en.wikipedia.org/wiki/Year_2038_problem)..

[ Update: 01/12/2011 ]


O FBI e o Internet Storm Center (ISC) do Sans Institute monitoraram as consultas DNS aos antigos servidores do DNSChanger - e contabilizaram mais de 2 milhões de resoluções de sistemas infectados com o malware.

Mais infomações:

http://threatpost.com/en_us/blogs/two-million-requests-infected-systems-week-after-ghost-click-takedown-120111



[ Update: 09/11/2011 ]


O FBI anunciou hoje a operação "Ghost Click"- em que foram apontados seis cidadãos estonianos e um russo, acusados de ligação com o malware DNSChanger -Veja o press release do FBI sobre o caso.


Recomendo também a leitura, no blog do Brian Krebs, de um excelente artigo sobre o assunto: "Biggest Cybercriminal Takedown in History"


Falando em DNS - enquanto isto, no Brasil (via @assolini): 

"Hackers atacam roteadores e provedores para redirecionar sites"
http://g1.globo.com/tecnologia/noticia/2011/11/hackers-atacam-roteadores-e-provedores-para-redirecionar-web.html

Isto acontece, ao menos - desde 2002 - mas devido ao redirecionamento de sites muito acessados como Google e Hotmail, a repercursão deste caso específico tem sido bem grande.


Observação: comentamos sobre o DNSChanger em junho de 2008 (no primeiro post deste blog) - veja abaixo:




[ Update - 12/04/2008 ]



O primeiro post deste blog - em 13 de junho deste ano - foi sobre um trojan chamado "DNSChanger" que tentava acessar com senhas padrão o gateway (modem/AP/router) da rede interna e automatizava a exploração da rede local da vítima, além de reconfigurar os endereços DNS atribuídos automaticamente e assim possibilitar o controle da navegação e phishing/pharming em uma nova dimensão.

Pois bem, passados 6 meses, estamos no 48.0 post deste blog e uma nova variante do DNSChanger está chamando a atenção da comunidade de segurança, por sua inovação.

De uma forma geral, estes trojans que buscam alterar as configurações de DNS das máquinas locais ou da rede do usuário, têm agido até o momento com um três dos seguintes modus operandi:

1. Modificar o arquivo Hosts do Windows Modify (%SYSROOT%\windows32\drivers\etc\hosts)
2. Modificar a entrada de registro incluindo um DNS server malicioso (HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\NameServer)
3. Explorar vulnerabilidades do tipo "cross-site request forgery" em routers (ou via força bruta como nosso post de junho aponta) para sobrescrever a configuração DNS das máquinas na rede local

A novidade está na nova técnica utilizada por este trojan, que permite que todos os equipamentos IP (indepentende de sistema operacional) que estejam configurados para obter endereçamento automaticamente sejam afetados pela alteração de DNS.

É instalado na máquina infectada um driver (ArcNet NDIS) que irá a partir deste momento atuar como um servidor DHCP falso, e vai concorrer com o servidor real na distribuição dos endereçamentos da rede local - e - como você já deve ter imaginado - quando ele atribui o endereço ele também fornece ao equipamento os IPs de servidores DNS falsos para que a navegação das máquinas seja controlada por ele.

Dois pontos interessantes levantados pela Mcafee/Sans:

1 - o número de equipamentos afetados com este tipo de abordagem é maior, já que não há limitação por sistema operacional.

2 - a detecção da causa-raiz da alteração do DNS das máquinas afetadas é muito difícil (você teria que analisar o tráfego de rede para identificar os endereços MAC dos pacotes "DHCP Offer" para identificar onde a máquina infectada está..)

Os DNS falsos utilizados na variante analisada são:

• 85.255.112.36
• 85.255.112.41

Como mitigação (deste ataque específico), o SANS Institute recomenda bloquear o range 85.255.112.0 – 85.255.127.255 no seu gateway de borda.

A Mcafee informa também que o driver legítimo "ArcNet NDIS Protocol Driver" que é utilizado pode ser encontrado no caminho a seguir: (%SYSROOT%\system32\drivers\ndisprot.sys)

Além dos links de referência já citados, a Symantec publicou uma análise do trojan contendo as modificações efetuadas no sistema afetado.



[ Post Original: 13/06/2008 ]


Trojan Zlob/DNSChanger altera configurações de routers

Em uma demonstração de criatividade do hacker criador do trojan, depois de se instalar na workstation windows, ele tenta acessar com senhas padrão o gateway (modem/AP/router) da rede interna.

É um novo paradigma interessante e perigoso pois automatiza a exploração da rede local da vítima, além de reconfigurar os endereços DNS atribuídos automaticamente e assim possibilitar o controle da navegação e phishing/pharming em uma nova dimensão.

O assunto é ainda mais interessante pois segundo a TrendMicro, há possibilidade do ZLOB ser financiado pela organização "cyber-criminosa" RBN (Russian Business Network)...

Outras informações:

• Washington Post
• DarkNet
• ExtremeSecurity (lista contramedidas)

DNS Vuln + "Evilgrade" = Pandemônio em updates de aplicações em todos os computadores da sua rede.

[ Update: 08/12/2011 ]


Algumas empresas já foram ou ainda são famosas por não responder adequadamente (e tempestivamente) a vulnerabilidades (não só "0-days", mas também as identificadas há anos e publicamente conhecidas e exploradas).

A Microsoft ainda está neste grupo, porém cada vez mais nos mostra que melhorou sua postura em relação a segurança. Já a Oracle/Sun e a Adobe são duas empresas que estão na maioria dos computadores do mundo (Java, Adobe Reader e Flash) e que infelizmente não tem tido uma resposta rápida o bastante..


Um exemplo é que o caso que ocorreu há quase 5 anos e que discutimos aqui no post original abaixo, que envolve o "Evilgrade" - depois de muito tempo, a Apple corrigiu em novembro deste ano as falhas que permitiam ataques no processo de atualização  do Itunes, por exemplo..

Já a Oracle/Sun... Ontem, o pessoal da Infobyte publicou em seu blog um post chamado "Pwning Java update process 2007-Today".

Resumindo: a Apple demorou mas a Oracle/Sun não corrigiu adequadamente a falha e ficou por isto.. Ou seja, além das falhas recentes como a CVE 2011/3544 - Java Rhino - o processo de atualização do Java continua vulnerável (5 anos!) ao "Evilgrade (Evil + Upgrade)' - mais detalhes no post original abaixo:


[ Post Original: 08/08/2008 ]

O que pode ser pior que seus usuários internos terem as aplicações windows desatualizadas? Que tal eles atualizarem com um executável escolhido por um hacker?

Alerta: Um dos ataques mais perigosos utilizando a vulnerabilidade DNS descoberta por Dan Kaminski está detalhado (inclusive em vídeo.)

No final de 2007, os argentinos da Infobyte lançaram o "Evilgrade" - FrameWork a la Metasploit que facilita muito ataques que objetivam instalar códigos malicisosos através da falsificação (spoofing DHCP, ARP ou DNS) - dos updates de aplicações como Java, Winamp, Winzip, OpenOffice, Itunes, Mac OS X ...

Agora, para piorar a situação, um vídeo com detalhes - comando a comando - da utilização do módulo do Metasploit de exploração da DNS Vuln (auxiliary/spoof/dns/bailiwiked+host) + Evilgrade para executar este ataque foi disponibilizado: http://www.infobyte.com.ar/demo/evilgrade.htm

Caso você (ou quem deveria) não tenha atualizado seus servidores DNS's internos, corra... é um ataque de simples execução com as ferramentas descritas e com potencial destrutivo de grande alcance (todas as máquinas servidas por este DNS interno) e o atacante pode escolher o que rodar, enganando o usuário que estará "atualizando" seus aplicativos...

Além de garantir que o DNS utilizado pelas estações e servidores sujeitos à updates sob sua responsabilidade estão atualizados, são sugeridas algumas outras contramedidas contra este tipo de ataque de spoofing de updates:

• Use ferramentas de controle de aplicações como o NSI da Secunia e plataformas de distribuição de software para instalação de updates, bloqueando as URLs de update vulneráveis ao ataque
• Utilize tecnologias de segurança em LAN como 802.1x / port security
• Use entradas ARP estáticas - especialmente para gateways

Mais info: aqui, aqui e aqui.

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.

Root DNS, CA e AS - uma questão de (des)confiança

[ Update - 27/05/2010 ]


Sobre o ítem II abaixo - ROOT CA's - hoje tomei conhecimento de um experimento interessante feito por Nasko (do site http://netsekure.org).

Da lista inicial de mais de 100 certificados raiz instalados nos navegadores Internet Explorer, Chrome (ambos lêem isto da lista do Windows) e no Firefox, apenas 10 foram realmente necessários depois de um mês de navegação intensiva.

Recomendado também são os demais posts do NetSekure, incluindo um sobre como remover os certificados raiz "confiáveis" do Windows.


[ Post Original - 12/04/2010 ]


Uma das bases psicológicas da segurança é a confiança. Por mais matemática e tecnologia que sejam continuamente aplicadas, muitos dos protocolos e sistemas que garantem o funcionamento "seguro" da infraestrutura de Internet são baseados neste princípio de delegação de segurança (confiança) em diferentes níveis, como por exemplo:

I) Domain Name System (DNS)

II) Certificados raiz SSL (ou Root CAs)

III) Autonomous Systems (ASs)

Vários incidentes recentes - descritos abaixo - chamam a nossa atenção para a fragilidade da dependência no modelo de confiança - e especialmente na implementação deste.

I) DNS

O DNS (Domain Name System) é um sistema hierárquico para resolução de nomes. Existem 13 root servers (A->M).

O ataque de redirecionamento de navegação através do controle da resolução de nome (DNS) pode ser feito de diversas formas, incluindo dns cache poisoning, a edição de arquivo hosts (muito usada em ataques de phishing), e a alteração ou criação de entradas nas tabelas de resolução de servidores DNS comprometidos, por exemplo.

Como sabemos, alguns países controlam a Internet usando técnicas similares às descritas. A China é um exemplo: ela obriga os provedores que atuam no país a redirecionar a resolução de nomes de sites proibidos (como YouTube, Twitter e FaceBook) para sites chineses onde o governo tem total controle do conteúdo.

Há poucos dias, o DNS raiz I - i.root-servers.net - começou a resolver endereços alterados chineses mesmo para clientes em países ocidentais, como o Chile e os Estados Unidos.

Depois do problema a empresa sueca NetNod - responsável pelo servidor DNS raiz "I" - deixou de fazer anúncio de rotas a partir desta instância do servidor DNS raiz localizada na China.

Mais tarde a empresa explicou que a instância do servidor I que roda na China é exatamente igual aos demais root servers e que as entradas de DNS alteradas foram inseridas em trânsito pelo governo Chinês. Este tipo de situação poderia ser evitada se os clientes utilizassem o DNSSEC.

Recentemente publicamos um post sobre o DNSSEC - que traz melhorias significativas de segurança no uso do serviço DNS e que já começou a ser implementada.

II - SSL/TLS

Outra implementação falha de confiança hierárquica é o baseado na utilização de certificados digitais assinados por "certificados raiz".

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 por https no navegador - gerando uma sensação de confiança que muitas vezes pode não corresponder à realidade.

Um paper (pdf) recentemente publicado por Christopher Soghoian e Sid Stamm mostra que a interceptação de comunicações SSL pode ser mais comum do que se pensa.

Qualquer um que possa obter um certificado falso - de qualquer autoridade certificadora confiada pelo S.O ou navegador - pode criar um website "seguro" com qualquer endereço. Os navegadores não emitirão nenhum aviso e aceitarão o certificado como se fosse legítimo. Mais detalhes aqui.

O vendor PacketForensics comercializa um appliance para interceptação de tráfego SSL que executa as ações descritas acima. Porém proxies SSL podem também ser criados usando ferramentas open-source como o nginx ou o httpd da apache.

Portanto, a questão importante para o sucesso da interceptação não é necessariamente o vendor usado e sim quão "bem falsificado" será o certificado. E em última instância, se você pode obter um (legalmente via mandado judicial ou ilegalmente via hacking) de uma das várias Autoridades Certificadores aceitas pelos navegadores.

Os autores do paper desenvolveram um plugin para Firefox chamado CertLock que gera um aviso caso seja detectada uma tentativa de forjar um certificado SSL e controla / avisa o usuário qual AC assinou um determinado certificado.

Minha opinião sobre o assunto - você não deve assumir que uma comunicação é segura a não ser que você tenha real controle sobre as chaves privadas envolvidas na comunicação.

Além disto, não se esqueça que existem computadores envolvidos na comunicações e portanto programas especialmente criados para monitoração de computadores podem ser utilizados - inclusive pelas Forças da Lei - quando autorizadas - (vide o software CIPAV usado pelo FBI)

III - Autonomous Systems

A RFC 1930, seção 3 descreve o funcionamento dos AS (Autonomous Systems). De forma simplificada - desde a criação da Internet na década de 60, houve um enorme crescimento das tabelas de roteamento, o que trouxe a necessidade de protocolos de roteamento hierárquicos. Os roteadores desde então são divididos em regiões chamadas Autonomous Systems. (ex: AS4230 - Embratel - gráfico de peering).

No começo deste mês um Provedor da China Telecom fez um hijack de uma parte considerável da Internet. Trata-se do AS23724 - gráfico de peering).

Apesar de ser responsável por apenas 40 prefixos, este AS começou a anunciar quase 40.000 prefixos que não eram de sua responsabilidade - em um ataque conhecido como BGP hijack ou prefix hijack.

Resultado? Sites como dell.com, cnn.com, www.amazon.de, www.rapidshare.com, www.geocities.jp, entre outros foram afetados diretamente.

Uma situação semelhante havia ocorrido em fevereiro de 2008 quando um provedor paquistanês fez hijack dos prefixos utilizados pelo Youtube.

O acesso ao site Youtube foi também afetado em 2007, no caso do vídeo na praia de Daniela Cicarelli - quando alguns AS´s brasileiros acataram a decisão judicial do Tribunal de Justiça do Estado de São Paulo e redirecionaram para 'null/0' todo o tráfego destinado ao Youtube.

Estamos acostumados a considerar a "boa fé" de usuários - que clicam em links, abrem anexos suspeitos, passam informações confidenciais a qualquer interlocutor - como um elo fraco da Segurança da Informação.

Os três exemplos citados (DNS, CA/SSL e AS/BGP) mostram que as fragilidades baseadas no modelo de confiança pré-existente são sérios e influenciam negativamente também a segurança da infraestrutura da Internet.