Como funciona o tipo de ataque DDoS sofrido pelo GitHub
No dia 28 de Fevereiro de 2018, GitHub sofreu o maior ataque DDoS já registrado na história até então. E aqui quero falar sobre os detalhes técnicos por trás desse tipo de ataque.
Importante: Não é a intenção deste artigo incentivar você a fazer algo parecido. Isto é um crime, certamente irão descobrir quem você é, e você poderá ser preso. O intuito aqui é didático, apenas.
O ataque
Por cerca de 9 minutos, os servidores do GitHub foram bombardeados com uma enxurrada de requisições que chegou a receber 1,35 terabits por segundo no ápice do ataque, através de 126,9 milhões de pacotes por segundo.
Apesar de nunca ter sido registrado um ataque tão grande de DDoS na história até este momento, GitHub ficou fora do ar por meros 5 minutos e instável nos próximos 4 minutos. Se isto não é incrível, eu não sei o que é.
Ok, mas como funcionou este ataque?
DDoS
Distributed Denial-of-Service (DDoS) é o nome dado a um ataque em que o servidor não aguenta responder tantas requisições ao mesmo tempo e fica indisponível para que outros não possam acessá-lo. Na prática, imagina que você tem um blog hospedado num servidor simples e barato da Digital Ocean, que por ser barato possui pouca memória RAM e um processador não muito bom. Você sabe que quando uma pessoa acessa seu blog a página aparece muito rápido. Mas quando você utiliza um programa para simular 100 pessoas acessando seu blog ao mesmo tempo, as coisas começam a ficar lentas. E isto é horrível, porque se outras pessoas tentarem acessá-lo, provavelmente vão pensar que seu site é realmente lento ou que está com algum problema.
Não parece um grande problema, né? Mas é, principalmente se você depende do seu site para ganhar dinheiro. Principalmente, se isto levar seus clientes para o concorrente. Principalmente se… bem, você entendeu. Ter seu site fora do ar pode te prejudicar de várias formas.
Porém, a maioria dos sites muito grandes são hospedados em servidores muito poderosos e muito bem configurados, que aguentam uma carga enorme de requisições ao mesmo tempo. Logo, não será você enviando requisições simultâneas através do seu terminal que vai derrubar um site como o GitHub.
E por que não?
Vamos fazer contas
Sabe esse cabo azul de internet que você pluga do roteador ao seu computador? Ele transmite um máximo de 10 gigabits de dados por segundo, cerca de 1,5 gigabytes por segundo.
"Mas meu computador é conectado no wifi", você diria. Pois bem, se você tiver um ótimo roteador que utiliza o padrão wireless 802.11ad, usando 5GHz e que custa ao redor de 320 dólares, você pode chegar a 70 gigabits por segundo, cerca de 8,75 gigabytes por segundo (o meu roteador atual, com 5GHz chega ao máximo de 75 Megabytes por segundo).
"Mas eu tenho um cabo de fibra ótica aqui em casa conectado ao meu roteador", você me diz. Cabos de fibra ótica permitem uma velocidade de transmissão de até 100 terabits por segundo, ou cerca de 12,5 terabytes (12.500 gigabytes) por segundo. O GitHub sofreu no ápice do ataque um bombardeamento de cerca de 168,75 gigabytes por segundo. Cheque-mate? Não.
Além de todas estas velocidades serem teóricas (ou seja, no melhor do mundos), você tem alguns gargalos entre a requisição que sai do seu computador até chegar no site que você atacaria, e o maior destes gargalos é o seu provedor de internet. Qual velocidade de internet você contratou? Se no contrato estava escrito 50Mbps, significa que mesmo que você tenha um cabo de fibra ótica saindo do seu computador até o roteador, o máximo que você consegue baixar é cerca de 6,25 megabytes por segundo. É só você olhar a velocidade do seu torrent. Mas esta é a taxa de download. É provável que sua taxa de upload seja ainda mais baixa, e é esta taxa que você precisa para enviar dados para alguém. Parecia tão mais fácil, né?
Pois é, é praticamente impossível derrubar um site deste nível a partir de apenas um computador. E se a gente juntar vários computadores mandando requisições ao mesmo tempo, ou seja, um ataque distribuído? Bem, aí pode dar certo.
E seja para prejudicar ou simplesmente para inflar o ego de alguém, sites sofrem ataques distribuídos de negação de serviço o tempo todo e é muito difícil se proteger deles. E os atacantes sabem disso.
Mas tem um problema: como conseguir tantos computadores para enviar requisições ao mesmo tempo para o servidor que queremos derrubar? Bem, existem algumas formas de fazer isso. Pode ser que você tenha acesso a milhares de computadores em uma rede de alta velocidade, uma universidade, por exemplo. Ou você desenvolveu um malware que infectou e controlou vários computadores por aí e ao seu sinal todos eles vão disparar a requisição ao mesmo tempo. Esta, talvez, seja a solução mais popular até tempos atrás, mas é cada vez mais difícil encontrar vulnerabilidades em milhares de computadores em redes de alta velocidade que anti-vírus não irão detectar. E pra tentar contornar essa dificuldade, os atacantes passaram a utilizar outra técnica há muito tempo conhecida, o IP Spoofing.
IP Spoofing
Esta é uma técnica simples em que você envia um requisição para um servidor mas altera o IP do remetente, no caso o seu, por outro IP. Isto faz com que o servidor que está recebendo a requisição pense que quem está o chamando na verdade é outra "pessoa", e quando ele for responder àquela requisição, ele vai responder àquela "pessoa" que não é a real.
Fazendo uma analogia, imagine que você quer sacanear seu amigo e assina a newsletter de um site de jardinagem. Você vai usar o email dele ao invés do seu, e o site vai responder ao seu amigo e não a você.
Mas qual o propósito disto? Desta forma, eu posso fazer uma requisição de dados a um servidor e alterar o IP remetente desta requisição pelo IP do site que eu quero atacar. Desta forma, não vou precisar invadir computador nenhum para enviar estas requisições para mim. Do meu computador eu posso requisitar dados de vários sites diferentes e pedir para todos eles entregarem as respostas para o mesmo local, o servidor que eu quero derrubar.
Na prática, fazer um IP Spoofing é simples. Existem muitas ferramentas open-source que permitem você fazer isto. Você pode inclusive utilizar o "iptables" para configurar uma espécie de roteador que receba sua requisição, altere o IP do remetente e dê prosseguimento a esta requisição até ela chegar no zumbi.
Algo como:
Mas uma pergunta vem em mente, qual a diferença? Se eu tenho que enviar requisições para estes servidores "zumbis" não seria mais fácil enviar as requisições direto para a vítima? Isto nos leva ao próximo tópico, que é o amplification attack, ou ataque de amplificação.
Amplification attack
Se você enviar as requisições direto para a vítima, voltará ao problema descrito lá em cima da largura de banda, onde você não consegue enviar mais que certa quantidade de dados ao mesmo tempo. Mas, se você utilizar zumbis que se encontram em redes de alta velocidade, você pode fazer requisições bem pequenas, que sejam rápidas para você fazer e que produzam respostas enormes, pois a banda de rede dos zumbies é muito maior que a sua e você não precisará invadir computador algum.
Tá, mas e na prática, como se faz isto sem invadir o computador?
DNS Lookup
Uma das formas mais populares é requisitando um DNS Lookup de algum domínio utilizando a técnica de IP Spoofing. Ou seja, você envia uma requisição muito pequena para um servidor DNS, que certamente estará em uma rede de alta velocidade, pedindo todas as informações possíveis de um domínio e este enviará uma resposta bem maior para a vítima.
Uma das formas de se requisitar um DNS Lookup é com o comando "host". Você pode testar aí no seu terminal executando: "host github.com".
Claro que existem diferentes comandos e formas para fazer este tipo de requisição retornar uma mensagem muito maior do que a que você viu. Porém, parecia não ser grande o suficiente para o que alguns atacantes gostariam de fazer.
Logo, o problema era, "como criar requisições menores e mais rápidas que retornassem respostas muito maiores em direção a vítima?".
Eles pensaram em uma ideia brilhante: ao invés de fazer DNS Lookup, fariam requisições para outro tipo de serviço chamado Memcached, que, dependendo da configuração utilizada pelo servidor zumbi, aceitaria requisições através de pacotes UDP, com uma mensagem muito pequena e retornaria uma quantidade exorbitante de dados de resposta em direção a vítima.
Memcached
Em termos gerais, Memcached é um software open-source utilizado por milhões de sites para armazenar dados na memória RAM com o intuito de substituir um banco de dados escrito no disco (MySQL, Postgresql, MongoDB…) em certas requisições que este site precisa consultar dados em alta velocidade.
Por exemplo, este artigo que você está lendo agora não possui nenhum tipo de dado que fique sendo alterado o tempo todo. E, de alguma forma, é muito custoso para um site ter que procurar este artigo em um banco de dados como o Postgresql toda vez que alguém acessar esta URL para trazer sempre o mesmo texto. Seria muito melhor se os dados deste artigo estivessem armazenados também na memória RAM do servidor, afinal consultar dados na memória RAM é muito mais rápido do que consultar dados no HD.
O Memcached é executado como um serviço e é acessado através de uma porta, por padrão a 11211. O que significa que se o computador que está rodando o serviço do memcached estiver exposto na internet e não filtrar quem está acessando seu serviço, qualquer pessoa que também estiver conectada na internet pode acessar este serviço utilizando o IP do computador através da porta 11211. Da mesma forma como acessar o site hospedado naquele computador que está rodando na porta 80 ou 443.
"Isso significa que se o Medium utiliza memcached e eu souber o IP do servidor que está rodando este serviço, eu posso acessar os dados deste artigo direto através da porta 11211?" Sim, meu caro Watson! Exatamente isto! "E se eu posso acessar o artigo, eu posso utilizar a técnica de IP Spoofing para o Medium retornar o artigo inteiro na direção da vítima?" Perfeito Watson! Você entendeu completamente a ideia! "Logo, eu posso usar o Medium e mais outros milhares de servidores para direcionar o ataque a minha vítima ao mesmo tempo! Yey!"
E o melhor, o Memcached responde a alguns comandos incrivelmente pequenos e também aceita conexões TCP e UDP, a não ser que os servidores configurem para que aceitem apenas um dos dois protocolos. Significa que se você encontrar um servidor rodando memcached que aceite pacotes UDP, você consegue enviar requisições pequenas e obter respostas rápidas e muito grandes.
Por que utilizar UDP? Porque além de ser menor, é um protocolo que não se preocupa com erros de entrega e também não estabelece conexão, o que faz com que seja muito mais rápido o transporte.
E como encontrar estes servidores? Primeiro você seleciona uma lista de IPs e depois scaneia a porta deles. Se estiver com a porta 11211 aberta aceitando UDP, bang. Você coloca na lista.
Depois de coletar muitos IPs com memcached expostos, você envia multiplas requisições para eles e direciona suas respostas para a vítima. Foi exatamente isto que fizeram com o GitHub.
E como resolver isto?
Como citei lá em cima, ataques DDoS são muito difíceis de se defender. E a defesa contra estes ataques não devem partir somente das vítimas diretas, como neste caso o GitHub. Na verdade, todas as pessoas que expõem servidores na internet devem ter cuidado ao configurar seus serviços.
Neste caso deste ataque utilizando memcached com UDP, a cloudflare, empresa que expôs os detalhes desta ameaça antes do GitHub sofrer seu ataque, afirma que é responsabilidade de todo mundo cuidar para que seus servidores memcached não aceitem requisições UDP. Fazendo com que seus serviçoes aceitem apenas TCP faz com que o transporte seja muito mais lento e evite um ataque em massa. Outros detalhes sobre como mitigar esta ameaça podem ser lidos no artigo linkado acima.
Claro que muitos detalhes sobre como se executar um ataque deste nível foram omitidos aqui. Por exemplo, se você fizer exatamente o que está descrito neste artigo, os servidores zumbis saberão que você está acessando diretamente a porta 11211 deles e isto não é normal. Vão monitorar você. Então, sério, não reproduza.
Também, porque não sou especialista em segurança e a intenção deste artigo não é ensinar a derrubar sites. Isto é algo que eu realmente espero que você não faça, e se for para fazer, faça em um laboratório próprio com o intuito didático e que não coloque ninguém e nenhum servidor em risco.
Espero que você tenha aprendido algo com este artigo e se tiver alguma dúvida sobre qualquer etapa, deixe um comentário aqui embaixo.
E se curtiu o artigo, não deixe de clicar no "Clap" aqui na esquerda. Isso ajuda o artigo alcançar outras pessoas. :)
Grande abraço!
