Ao longo dos últimos dias, vimos um grande aumento em um obscuro vetor de ataque de amplificação - usando o protocolo memcached , vindo da porta UDP 11211.
3829936641_f112ed1665_bCC 2.0-SA PELA imagem por David Trawin

No passado, nós falamos muito sobre amplificação ataques que acontecem na internet. Nossos últimos dois posts no blog foram:

Amplificações SSDP que cruzam 100 Gbps . Curiosamente, desde então, fomos alvo de um ataque SSP de 196Gbps.
Estatísticas gerais sobre vários ataques de amplificação que vemos .
A idéia geral por trás de todos os ataques de amplificação é a mesma. Um invasor capaz de spoofing de IP envia solicitações forjadas para um servidor UDP vulnerável. O servidor UDP, sem conhecer o pedido, é forjado, prepara educadamente a resposta. O problema acontece quando milhares de respostas são entregues a um host de alvo desavisado, abrandando seus recursos - mais tipicamente a própria rede.

spoofing-1

Os ataques de amplificação são efetivos, porque muitas vezes os pacotes de resposta são muito maiores do que os pacotes de solicitação. Uma técnica cuidadosamente preparada permite que um invasor com capacidade de spoofing IP limitada (como 1Gbps) possa lançar ataques muito grandes (atingindo 100s Gbps) "amplificando" a largura de banda do atacante.

Memcrashed
Os ataques de amplificação obscuros ocorrem o tempo todo. Muitas vezes, vejo pacotes "chargen" ou "call of duty" atingindo nossos servidores.

No entanto, a descoberta de um novo vetor de amplificação, que permite amplificação muito grande, raramente acontece. Este novo memocaching UDP DDoS está definitivamente nesta categoria.

O DDosMon do Qihoo 360 monitora os vetores de ataque de amplificação e este gráfico mostra recentes ataques de memcached / 11211:

memcached-ddosmon

O número de ataques de memcached foi relativamente plano, até que começou a aumentar apenas alguns dias. Nossos gráficos também confirmam isso, aqui estão os ataques em pacotes por segundo nos últimos quatro dias:

memcached-pps

Embora os pacotes por segundo não sejam impressionantes, a largura de banda gerada é:

memcached-gpb

No pico, vimos 260Gbps de tráfego de UDC Memconached de entrada. Isso é enorme para um novo vetor de amplificação. Mas os números não mentem. É possível porque todos os pacotes refletidos são muito grandes. É assim que parece no tcpdump:

$ tcpdump -n -t -r memcrashed.pcap udp and port 11211 -c 10
IP 87.98.205.10.11211 > 104.28.1.1.1635: UDP, length 13
IP 87.98.244.20.11211 > 104.28.1.1.41281: UDP, length 1400
IP 87.98.244.20.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 5.196.85.159.11211 > 104.28.1.1.1635: UDP, length 1400
IP 46.31.44.199.11211 > 104.28.1.1.6358: UDP, length 13

A maioria dos pacotes tem tamanho de 1400 bytes.
Fazer a matemática 23Mpps x 1400 bytes dá 257Gbps de largura de banda, exatamente o que o gráfico mostra.

Memcached UDP?
Fiquei surpreso ao saber que o memcached faz UDP, mas lá você vai! A especificação do protocolo mostra que é um dos melhores protocolos a serem usados ​​para amplificação ! Há verificações absolutamente zero, e os dados vai ser entregue ao cliente, com uma velocidade impressionante! Além disso, o pedido pode ser pequeno e a resposta enorme (até 1 MB).

Lançar um ataque desse tipo é fácil. Primeiro, o invasor implora uma grande carga útil em um servidor Memcached exposto. Em seguida, o atacante falsifica a mensagem de solicitação "get" com o Source IP de destino.
Synthetic run com Tcpdump mostra o tráfego:

$ sudo tcpdump -ni eth0 port 11211 -t
IP 172.16.170.135.39396 > 192.168.2.1.11211: UDP, length 15
IP 192.168.2.1.11211 > 172.16.170.135.39396: UDP, length 1400
IP 192.168.2.1.11211 > 172.16.170.135.39396: UDP, length 1400
...(repeated hundreds times)...

15 bytes de solicitação provocaram 134KB de resposta.
Este é um fator de ampliação de 10.000x! Na prática, vimos um resultado de 15 bytes no resultado de uma resposta de 750 kb (é uma amplificação de 51,200x).

IPs de origem
Os servidores vulneráveis ​​de memcached estão em todo o mundo, com maior concentração na América do Norte e na Europa. Aqui está um mapa dos IPs de origem que vimos em cada um dos nossos 120 pontos de presença:

memcached-map2

Curiosamente, nossos datacenters em EWR, HAM e HKG vêem números desproporcionalmente grandes de IPs de ataque. Isso ocorre porque a maioria dos servidores vulneráveis ​​está localizada em grandes provedores de hospedagem. Os números AS dos IPs que vimos:

┌─ips─┬─srcASN──┬─ASName───────────────────────────────────────┐
│ 578 │ AS16276 │ OVH │
│ 468 │ AS14061 │ DIGITALOCEAN-ASN - DigitalOcean, LLC │
│ 231 │ 0AS7684 │ SAKURA-A SAKURA Internet Inc. │
│ 199 │ 0AS9370 │ SAKURA-B SAKURA Internet Inc. │
│ 165 │ AS12876 │ AS12876 │
│ 119 │ 0AS9371 │ SAKURA-C SAKURA Internet Inc. │
│ 104 │ AS16509 │ AMAZON-02 - Amazon.com, Inc. │
│ 102 │ AS24940 │ HETZNER-AS │
│ 081 │ AS26496 │ AS-26496-GO-DADDY-COM-LLC - GoDaddy.com, LLC │
│ 074 │ AS36351 │ SOFTLAYER - SoftLayer Technologies Inc. │
│ 065 │ AS20473 │ AS-CHOOPA - Choopa, LLC │
│ 049 │ AS49981 │ WORLDSTREAM │
│ 048 │ AS51167 │ CONTABO │
│ 048 │ AS33070 │ RMH-14 - Rackspace Hosting │
│ 045 │ AS19994 │ RACKSPACE - Rackspace Hosting │
│ 044 │ AS60781 │ LEASEWEB-NL-AMS-01 Netherlands │
│ 042 │ AS45899 │ VNPT-AS-VN VNPT Corp │
│ 041 │ 0AS2510 │ INFOWEB FUJITSU LIMITED │
│ 040 │ 0AS7506 │ INTERQ GMO Internet,Inc │
│ 035 │ AS62567 │ DIGITALOCEAN-ASN-NY2 - DigitalOcean, LLC │
│ 031 │ 0AS8100 │ ASN-QUADRANET-GLOBAL - QuadraNet, Inc │
│ 030 │ AS14618 │ AMAZON-AES - Amazon.com, Inc. │
│ 030 │ AS31034 │ ARUBA-ASN │
└─────┴─────────┴──────────────────────────────────────────────┘
A maioria dos servidores memcached que vimos foram provenientes da AS16276 - OVH, AS14061 - Digital Ocean e AS7684 - Sakura.
No total, vimos apenas 5.729 IPs originais de servidores memcached. Esperamos ver ataques muito maiores no futuro, já que o Shodan informa 88.000 servidores abertos de memcached:

memcached-shodan

Vamos consertá-lo?
É necessário corrigir isso e evitar novos ataques. Aqui está uma lista de coisas que devem ser feitas.

Usuários Memcached
Se você estiver usando o memcached, desative o suporte UDP se você não estiver usando. Na inicialização de memcached, você pode especificar --listen 127.0.0.1para ouvir apenas o localhost e -U 0desativar o UDP completamente. Por padrão, o memcached escuta em INADDR_ANY e é executado com o suporte UDP ENABLED . Documentação:

https://github.com/memcached/memcached/wiki/ConfiguringServer#udp
Você pode testar facilmente se seu servidor é vulnerável executando:

$ echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -q1 -u 127.0.0.1 11211
STAT pid 21357
STAT uptime 41557034
STAT time 1519734962
...
Se você ver a resposta não vazia (como a acima), seu servidor é vulnerável.

Administradores de sistema
Certifique-se de que seus servidores memcached sejam firewall da internet! Para testar se eles podem ser acessados ​​usando UDP eu recomendo o ncexemplo acima, para verificar se o TCP está fechado, execute nmap:

$ nmap TARGET -p 11211 -sU -sS --script memcached-info
Starting Nmap 7.30 ( https://nmap.org ) at 2018-02-27 12:44 UTC
Nmap scan report for xxxx
Host is up (0.011s latency).
PORT STATE SERVICE

11211/tcp open memcache
| memcached-info:
| Process ID 21357
| Uptime 41557524 seconds
| Server time 2018-02-27T12:44:12
| Architecture 64 bit
| Used CPU (user) 36235.480390
| Used CPU (system) 285883.194512
| Current connections 11
| Total connections 107986559
| Maximum connections 1024
| TCP Port 11211
| UDP Port 11211
|_ Authentication no

11211/udp open|filtered memcache
Provedores de serviços de internet
memocached-reflector

Para vencer esses ataques no futuro, precisamos corrigir protocolos vulneráveis ​​e também falsificação de IP. Enquanto IP spoofing for permitido na internet, teremos problemas.Ajude-nos rastreando quem está por trás desses ataques. Não devemos saber quem tem servidores problemáticos em memcached, mas quem lhes enviou consultas em primeiro lugar . Não podemos fazer isso sem sua ajuda!

Desenvolvedores
Por favor, por favor: pare de usar o UDP.
Se você deve, não habilite-o por padrão. Se você não sabe o que é um ataque de amplificação, proíbo que você nunca digite SOCK_DGRAMem seu editor.

Estivemos por esta estrada tantas vezes. DNS, NTP, Chargen, SSDP e agora memcached. Se você usar o UDP, você sempre deve responder com um tamanho de pacote menor do que o pedido. Caso contrário, seu protocolo será abusado. Lembre-se também de que as pessoas se esquecem de configurar um firewall. Seja um bom cidadão. Não invente um protocolo baseado em UDP que não tenha autenticação de qualquer tipo.

Isso é tudo
É alguém adivinhar o quão grande os ataques de memcached se tornarão antes de limpar os servidores vulneráveis. Já havia rumores de amplificações de 0.5Tbps nos últimos dias, e isso é apenas um começo.
Finalmente, você está OK se você é um cliente Cloudflare. A arquitetura Anycast do Cloudflare funciona bem para distribuir a carga em caso de grandes ataques de amplificação e, a menos que seu IP de origem esteja exposto, você está a salvo de Cloudflare.

Prólogo
Um comentário (abaixo) aponta que a possibilidade de usar o memcached para DDoS foi discutida em uma apresentação de 2017 .

Atualização
Recebemos uma palavra do Digital Ocean, OVH, Linode e Amazon que abordaram o problema do memcached, suas redes não deveriam ser vetores em futuros ataques.



Segunda, Março 5, 2018





« Voltar