公告 - HOSTCURITIBA - Hospedagem Security
Memcrashed - Grandes ataques de amplificação da porta UDP 11211
Jan 2021 Dec 2020 Nov 2020 Oct 2020 Aug 2020 Jul 2020 Apr 2020 Feb 2020 Jan 2020 Oct 2019 較舊的公告... 查看 RSS Feed
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.
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:
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:
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:
│ 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:
Você pode testar facilmente se seu servidor é vulnerável executando:
Se você ver a resposta não vazia (como a acima), seu servidor é vulnerável.
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:
11211/tcp open memcache
| 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
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!
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.
É 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.
Um comentário (abaixo) aponta que a possibilidade de usar o memcached para DDoS foi discutida em uma apresentação de 2017 .
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.