[Segurança] Ataques de subdomain takeover

Imagina que você vai no cartório e no Correios e registra que existe uma casa na Rua José das Couves, número 51. Mas tem um detalhe: esse número não existe na rua! Aí um espertinho descobre isso, vai lá na rua e constrói uma casa e bota a plaquinha de número 51 na porta. Você tem o endereço, seus amigos mandam carta para você (faz de conta, né, porque hoje em dia ninguém manda carta), a sua compra na loja de e-commerce vai para esse endereço, mas a casa é de outra pessoa. Em vez de isso tudo chegar para você, o “espertinho” é quem fica com a sua correspondência.

Esse exemplo é bem tosco, criado por um amigo, o Julio Carvalho, que também me indicou alguns dos links que usei nesse post. Tudo isso para ilustrar o significado de um ataque de...

Subdomain Takeover

Em português, seria algo como "sequestro de subdomínios".

Esse é um ataque que acontece com frequência, aonde uma empresa cria um subdomínio apontando para algum serviço online, mas esse serviço não está ativo ou o serviço existente foi desativado. Esse subdomínio, portanto, aponta para lugar nenhum. O atacante, então, vai nesse serviço e cria uma entrada com o nome da empresa, conseguindo que o subdomínio válido aponte para um serviço malicioso. Tais casos frequentemente acontecem com serviços em nuvem oferecidos por terceiros, como o GitHub e com os serviços de bucket S3 da AWS. Nesses dois casos, por exemplo, o atacante descobre que o domínio está errado e cria um repositório com conteúdo malicioso no GitHub ou na AWS – mesmo que usando uma conta própria nesses serviços.

Com esse tipo de ataque, um ciber criminoso pode criar uma página de phishing, um site falso ou um repositório em nome da empresa, mas que esteja hospedando um conteúdo malicioso – só para citar 3 exemplos de consequências indesejáveis para as empresas.

De fato, com a popularização dos serviços de computação em nuvem e repositórios de dados em nuvem, esse ataque ganhou força. É o caso da Amazon Simple Storage Service (Amazon S3), o serviço de armazenamento de dados da Amazon.

No caso da AWS, o ataque de subdomein takover explora a forma que a AWS trabalha com a nomenclatura dos buckets S3. É possível criar uma URL virtual para identificar e dar acesso ao seu bucket, utilizando o formato https://bucketname.s3.Region.amazonaws.com (por exemplo, "ttps://suaempresa.s3.us-west-2.amazonaws.com"), que é equivalente a URL https:// s3.Region.amazonaws.com/bucketname.

Nesse caso, um atacante pode descobrir que sua empresa tinha uma URL cadastrada no DNS, via CNAME, apontando para um bucket desativado. Assim, ele pode “sequestrar” o seu bucket na AWS criando outro bucket com o nome (bucketname) equivalente ao previamente cadastrado pela sua empresa (por exemplo, “suaempresa”) dentro da “amazonaws.com”. Quem cair numa página que tenha esse link ou quem acessar diretamente o link (por exemplo, "ttps://suaempresa.s3.us-west-2.amazonaws.com" oi "https:// s3.us-west-2.amazonaws.com/suaempresa") vai cair numa URL com o nome da sua empresa, mas o conteúdo será malicioso.

O segredo para prevenir esse ataque é, principalmente, ter uma gestão muito cuidadosa dos seus registros DNS, aqueles que apontam o nome (URL) de um site ou serviço para o serviço em si. E também o monitoramento frequente dos seus ativos na nuvem e dos seus registros no DNA, para garantir que os seus domínios continuam válidos. Normalmente esse cadastro de subdomínios é feito pelos campos CNAME do DNS.

Para saber mais:

• Esses artigos explicam esse ataque: #dicadoJulio
• What Are Subdomain Takeovers, How to Test and Avoid Them? - Ele tem até um exemplo de como identificar um subdomínio problemático em vários serviços online (AWS, Bitbucket, GitHub, Gitlab, Heroku, Wordpress, etc);
• How To Avoid Hostile Subdomains Takeovers
• How an unclaimed AWS S3 bucket escalates to subdomain takeover
• Documentação da AWS:
• Accessing a bucket
• Virtual Hosted-Style Requests 

[Segurança] Mais ainda sobre os ataques de DNS refletido

O pessoal do Linha Defensiva publicou um artigo legal sobre o que são os e aproveitaram para se juntar a galera que tem criticado a cobertura exagerada que a imprensa tem dado ao caso do ataque de DDoS ao Spamhaus. Vale a pena a leitura:

"O ‘maior ataque cibernético’ e outro grande exagero da imprensa"

Eles também criaram um diagrama bem caprichado para explicar o ataque que foi realizado ao Spamhaus, que enviou pacotes com o endereço IP das vítimas (com IP spoofing) direcionados a servidores DNS recursivos que estavam abertos a qualquer requisição vinda da Internet:



Para quem é responsável pela administração de servidores DNS, vale a pena dar uma olhada no paper do CERT.br com "Recomendações para Evitar o Abuso de Servidores DNS Recursivos Abertos". O paper é de 2007 e eles acabaram de atualizar.

Enfim, como diriam os Titãs:

"Não importa contradição
O que importa é televisão
Dizem que não há nada que você não se acostume
Cala a boca e aumenta o volume então"

Para saber mais (aproveitando algumas dicas do Alberto, da Lucimara e do Evandro Hora):

• Meu post sobre os ataques de DDoS ao Spamhaus: "[Segurança] O maior ataque de todos os tempos... da última semana"
• Pequeno artigo o site CSO Online: "Spamhaus DDoS: History's biggest attack... since the last one"
• Artigo do The Guardian, respeitado jornal britânico: "How a cyberwar was spun by shoddy journalism"
• Paper "DNS Amplification Attacks"
• Paper "Denial of Service Attacks using Nameservers"
• RFC 5358 / BCP 140: Preventing Use of Recursive Nameservers in Reflector Attacks
• The Open DNS Resolver Project: Projeto com informações sobre o problema de DNS recursivo aberto. É possível pesquisar se eles identificaram um na sua rede. Segundo o site, em 24/3/2013 haviam 25 milhões de servidores vulneráveis.
• White paper de 2006 da Verisign: "Anatomy of Recent DNS Reflector Attacks from the Victim and Reflector Point of View"

[Segurança] O maior ataque de todos os tempos... da última semana

É impossível ver uma notícia como "Organização antispam sofre maior ataque cibernético da história" sem lembrar desta música dos Titãs:

"A melhor banda de todos os tempos da última semana
O melhor disco brasileiro de música americana
O melhor disco dos últimos anos de sucessos do passado
O maior sucesso de todos os tempos entre os dez maiores fracassos"

Segundo informações publicadas no blog da CloudFare, uma empresa que fornece serviço de proteção contra ataques de DDoS, o Spamhaus sofreu uma série de ataques de DDoS que atingiu um pico de 300 Gbps(gigabits por segundo). Até então, o maior ataque conhecido de DDoS tinha chegado a míseros 100 Gbps.
(veja nota adicional no final do post)
Segundo o G1, com 300 Gbps é possível transferir 37 filmes com qualidade DVD ou 55 CDs de música, em qualidade total, em apenas um segundo.

O Projeto Spamhaus é uma organização global sem fins lucrativos dedicada ao rastreamento de Spammers, com o objetivo de identificar redes de origem de mensagens de SPAM e colocá-las em uma "black list" para prevenir o envio de SPAM. A lista da Spamhaus é utilizada por diversos provedores e empresas para diminuir o SPAM recebido por seus usuários.

O ataque contra o Spamhaus começou desde o dia 18 de março, e foi lançado aparentemente pelo Anonymous com o nome de "OpStopHaus". A operação foi divulgada como um protesto contra a publicação de endereços IP pertencentes a provedores, operadoras e redes não conclusivamente ligados ao SPAM. Além disso, o Anonymous alega que o Spamhaus pratica chantagem e extorsão aos ISPs afetados por SPAM, para obrigá-los a proibir o envio de SPAM em suas redes. Coincidência ou não, a operação surgiu depois que a Spamhaus bloqueou o provedor holandês "Cyberbunker", um provedor que promete hospedar qualquer conteúdo que não seja pedofilia e terrorismo. Segundo a Spamhaus, o Cyberbunker estaria sendo utilizado por spammers para enviar e-mails indesejados. Este tipo de provedor é conhecido como "bullet proofing host", pois oferece serviço de hosting para qualquer tipo de conteúdo (incluindo sites criminosos), com a promessa de dificultar qualquer ação policial contra o site.

Segundo o post detalhado disponibilizado pela CloudFare sobre o início dos ataques, os ataques de DDoS contra o Spamhaus foram realizados na camada 3, e a principal técnica utilizada foi o de "DNS reflection", que consiste em enviar vários pedidos de acesso ao arquivo de zona de servidores DNS usando um endereço IP de origem falsificado igual ao da vítima, que irá receber um grande número de respostas para a vítima. No início os ataques eram de 10 Gbps, depois alcançaram um volume médio de tráfego de 75 Gbps vindo de 30 mil servidores DNS, representando uma taxa de amplificação de 100 vezes (ou seja, para cada byte que os atacantes enviavam, a vítima recebia 100 bytes).

Segundo um post mais recente da CloudFare, em 19 de março, o ataque de DDoS aumentou de tamanho e atingou cerca de 90 Gbps. No dia 21 de março o ataque oscilou entre 30 e 90 Gbps atingiu 120 Gbps em 22 de março. Quando os atacantes perceberam que não podiam derrubar o serviço da CloudFlare, eles começaram a atacar os provedores de link Internet deles, os provedor de backbone Tier 1 que fornecem conectividade para um dos provedores Internet da CloudFare e até mesmo gateways que fazem a conectividade entre os bckbones da Internet, conhecidos como Internet Exchange (IX). Um dos provedores de backbone Tier 1 atacados reportou que os ataques alcançaram 300 Gbps de tráfego. Na medida que estes ataques tem aumentado, vários provedores de backbone foram congestionados, principalmente na Europa, afetando centenas de milhões de pessoas.

Ainda que 300 Gbps de tráfego seja um volume impressionante, o ataque só foi possível pois juntou uma combinação perfeita de técnica de ataque e alvo: o ataque na camada 3 usando amplificação de requisições DNS, foi direcionado aos provedores globais de backbone, que tem links com um tamanho tal a ponto de ser atingido por 300 Gbps de dados. Provedores pequenos teriam caído muito antes. Entretanto, da mesma forma que os ataques DDoS pularam de 100 Gbps em 2010 para 300 Gbps nesta semana, nada impede que um atacante com motivação e uma botnet grande o suficiente realize outros ataques maiores no futuro, e em breve este título de "maior ataque da história" poderá passar para outro.





Notas:

• O Sandro Suffert publicou um excelente post sobre o assunto: "O Maior ataque de negação de serviço (DDOS) da História - 300Gbps"
• Na verdade os ataques DDoS já superaram a barreira dos 100 Gbps mesmo antes deste ataque ao Spamhaus. Segundo estatísticas divulgadas pelo Gartner, os ataques a bancos americanos realizados recentemente durante a Operação Ababil atingiram um tamanho total de 190 Gbps, sendo que o maior ataque contra um único banco foi de 110 Gbps. Nestes ataques, os atacantes usaram apenas 3.200 dos 9.200 bots que tinham. Ou seja, a coisa poderia ter sido pior. (adicionado em 28/3)
• O pessoal do Gizmodo fez uma crítica bastante interessante sobre esta história toda. Eles apontaram corretamente que 300 Gbps é um volume de tráfego que não faz nem cócegas perto da quantidade trafegada pelos grandes provedores de backbone, e por isso, não há razão para tantos relatos pseudo-apocalípticos. Eles também questionaram se houve realmente algum impacto por causa destes ataques e criticaram o fato de todas as informações disponíveis terem sido divulgadas pela CloudFare, uma empresa que vende serviços de proteção contra DDoS e, portanto, tem interesse em causar o pânico entre prováveis clientes. Por outro lado, o Richard A Steenbergen publicou uma resposta bem interessante para a Gizmodo, afirmando que o principal impacto foi causado pelo ataque direcionado aos routers IX, e embora os provedores de backbone estejam acostumados a tratar volume de tráfego na ordem de terabytes por segundo, ele não costumam ter uma banda de 300 Gbps "sobrando", pois seria muito caro manter este recurso ocioso. (adicionado em 28/3)
• Criei um post adicional sobre este assunto: "[Segurança] Mais ainda sobre os ataques de DNS refletido" (adicionado em 28/3)

[Segurança] Domínios brasineiros adotam o DNSSEC

O Registro.br anunciou que ativou o uso de DNSSEC (DNS Security Extension) para os domínios com.br e org.br. O uso de DNSSEC para estes domínios é opcional, porém é altamente recomendável.

O DNSSEC traz grande benefício para a comunidade Internet (sites e usuários) pois garante a autenticidade das informações publicadas nos servidores de nome de domínio. Durante o processo de resolução de nomes, o DNSSEC utiliza algoritmos criptográficos para garantir a origem e a integridade da informação recebida. Por isso, esta tecnologia é reconhecida como sendo a única solução efetiva disponível para a proteção contra ataques de DNS cache poisoning (poluição de cache), que é muito utilizado para redirecionar usuários e comunicações para sites falsos.

A página do anúncio no Registro.br possui várias informações adicionais para que os administradores saibam como utilizar este recurso. Para saber mais sobre DNSSEC, o site www.dnssec.net é uma ótima referência, com artigos, apresentações, informações técnicas, listas, etc.