Nos últimos anos, um novo elemento foi introduzido no universo de amplificação de ataques de negação de serviço distribuído (DDoS) e este elemento vem acompanhado de um potencial muito maior de ataques DDoS em comparação ao que já vimos no passado. Apesar da maioria das pessoas pensar em DNS, UpNP/SDP e NTP como protocolos mais utilizados em ataques DDoS, o memcache surgiu como um protocolo igualmente potente para ser utilizado nesses tipos de ataques. O Memcache é um protocolo destinado a possibilitar o rápido armazenamento e recuperação de dados a partir de um servidor, sem a complexa sobrecarga de uma base de dados no backend. Infelizmente, foi recentemente descoberto que tal protocolo é uma excelente fonte de amplificação e reflexão para o DDoS.

Nos últimos anos, a Cloudflare  e o Github tornaram-se as primeira vítimas deste novo método de amplificação de DDoS. No caso do Github, sua telemetria de rede a partir do Akamai indicou pelo menos uma onda de ataques que alcançou mais de 1,35Tbps dentro de seus servidores:

Figure 1 – https://githubengineering.com/DDoS-incident-report/

É preciso ter em mente que parte deste tráfego não se trata do ataque em si, mas sim de sobrecarga adicional da rede (tentativas de handshakings, etc.) que, no fim das contas, também compromete o desempenho. Colocando em perspectiva, segundo o Akamai SIRT, que este ataque tinha o dobro do tamanho do que já era conhecido sobre os ataques com Mirai, em setembro de 2016.

Utilizar o memcached é realmente muito fácil, você envia uma chave e então ele retorna os dados associados a esta chave. E com o benefício adicional de ser capaz de inserir quantas consultas desejar em uma única solicitação.

Figure 2 – Criando um ataque com o memcache

Nos ataques recentes, os criminosos fazem solicitações GET para que o serviço memcache capture o máximo de dados que puder nas chaves existentes (etapas 3 & 4 na figura 2); no entanto, em muitos casos, os servidores memcache não estão protegidos, além de permitir comandos SET (ou seja, utilizar um comando para inserir dados no servidor memcache). Os agentes maliciosos podem usar este artifício para definir um tamanho máximo permitido de blob para a chave, e então realizam sua consulta (Comandos GET) para aquela chave específica (etapas 1-4 na Figura 2) a fim de maximizar o tamanho do seu ataque de reflexão contra a vítima.

O memcache pode ser instalado em protocolos TCP (de forma nativa) e UDP, mas estes ataques serão encontrados principalmente em protocolo UDP utilizando a porta 11211, uma vez que o protocolo UDP possibilita o spoofing bem mais fácil do endereço da fonte, tornando-o mais atrativo para os ataques de reflexão DDoS.

Dos 120.458 servidores memcache identificados globalmente (número atualizado no momento em que este post foi escrito), há menos de 10 mil servidores executando o memcache em UDP. É ainda mais interessante observar que quase um terço destes servidores já foram relacionados em atividade de ataque.

Atualmente, um fator chave no valor da amplificação do memcache tem a ver com os dados blob retornados. Em termos gerais, o tamanho máximo de bytes para estes dados é relativamente pequeno, mas em alguns provedores de hospedagem foi observado que sua configuração memcache, permite blobs de dados muito maiores (em alguns casos, mais de 100G), assim aumentando seu valor em um ataque de amplificação DDoS.

Dito isto, existem inúmeras ressalvas e limitações ao tamanho que estes ataques podem alcançar. Em primeiro lugar e ainda mais importante, os ataques são inibidos pelos links associados ao servidor memcache sendo utilizado para refletir o ataque. Um link de 1Gbps enviará apenas 1Gbps, independente da dimensão do blob de dados criado pelo ataque. O mesmo se aplica à placa de rede. E, por último, o protocolo permite apenas dois números de sequência de rede de oito bytes. O blob de dados precisa ser segmentado para que seja enviado pela internet – a numeração de sequência permite que o destinatário reconstrua o blob novamente (semelhante a um quebra-cabeça!). Mas com apenas dois bytes, o número máximo de pacotes que o protocolo pode devolver é 65.536 e mesmo assim, é fácil calcular que o tamanho máximo de um único pacote seja de 1428, assim o volume total pode ser somente de 93,58 megabytes, transmitidos pela velocidade do link do servidor no qual está sendo refletido. Ou, em outras palavras, como um colega muito mais esperto indicou – o comando GET pode ser muito grande, mas assim torna-se deficiente devido às limitações do sequenciamento do pacote. O que também levanta o questionamento: como o memcached lida com os blobs de dados que exigem um sequenciamento maior que seu padrão permite, uma vez que o manuseio destes pacotes não aparenta estar especificado no protocolo. Seria maravilhoso saber as respostas para essas perguntas.

Mas então, no fim das contas, seria isso o fim do mundo? Será que a internet chegou ao fim da linha? Não. Apesar de estarmos apenas começando a entender o potencial técnico deste novo vetor de ataque, mesmo com os ataques de amplificação NDP, SSDP e DNS, ainda não vivenciamos uma onda constante de ataques DDoS em grande escala e é muito improvável que este seja o caso também para o memcached.  No entanto, será que veremos um crescimento no tamanho dos ataques DDoS quando acontecerem? Provavelmente sim. Por isso, assim como em outros ataques de negação de serviço, veja o que pode ser feito:

• Leia sobre ataques memcache (ambos o Arbor e o 360 Netlab têm excelentes análises destes ataques).
• Garanta que suas redes tenham um bom monitoramento de tráfego (tanto de entrada como de saída!) usando as ferramentas de invasão da rede  (como DDI e TippingPoint)
• Tenha mais de um provedor de Links, assim você pode contar com outros links caso os primeiros fiquem congestionados.
• Garanta a implementação na sua rede de antispoofing (tal como BCP38 e 84) para impedir que pacotes de spoofing, como os usados nos ataques DDoS de reflexão, não se aproximem da sua rede!

Como parte da pesquisa deste vetor de ataque, vários membros da comunidade de segurança nos auxiliaram. Gostaria de agradecer essas pessoas, especialmente ao Damien Menscher do Google pelo auxílio no entendimento do protocolo e interação como tráfego de ataque, e ao John Matherly do Shodan pelo auxílio na avaliação do impacto global.

Natasha Hellberg, Pesquisadora Sênior de Ameaças FTR

Colaboração de William Gamazo Sanchez, DSLabs