Seamus Tuohy e a eQualitie
Este relatório abrange os ataques ocorridos entre 29 de abril e 15 de outubro de 2016. Ao longo desse período de sete meses, registramos mais de cem incidentes distintos de negação de serviço contra o site oficial do Black Lives Matter. Nossa análise mostra uma variedade de métodos técnicos utilizados nas tentativas de derrubar esse site, e a caracterização desses ataques aponta para uma mentalidade de “turba” de agentes mal-intencionados que se juntam à causa em resposta a convocatórias feitas nas redes sociais e em canais secretos. Nosso relatório destaca o uso de serviços de hospedagem sem perguntas e de “booter” utilizados por agentes mal-intencionados para realizar esses ataques. Descrevemos a tendência cada vez maior de vândalos da Internet que, em busca de um pouco de notoriedade, lançam ataques de negação de serviço contra o site do Black Lives Matter (BLM). Nossa análise documentou ataques que podiam ser realizados por apenas US$ 1 e, com acesso a documentação pública e software malicioso facilmente disponíveis, exigiam apenas habilidades técnicas básicas. Alguns dos maiores ataques contra o BLM geraram milhões de conexões sem depender de uma infraestrutura gigantesca. Em vez disso, o tráfego foi “refletido” a partir de sites legítimos do WordPress e do Joomla. Comparamos as atribuições públicas de alguns desses ataques com os dados que passam por nossas redes e apresentamos o envolvimento de supostos membros do grupo Ghost Squad Hackers nesses eventos.
Introdução
“O Black Lives Matter, membro da May First/People Link e apoiado pelo Design Action Collective, é uma organização central no movimento de resistência contra abusos, brutalidade e conduta imprópria da polícia.” O site do BLM está protegido pelo Deflect desde 15 de abril de 2016, após uma série de ataques DDoS e de hackers.
No início de julho, publicamos um boletim preliminar, com a intenção de elaborar um relatório abrangente sobre os ataques logo em seguida. Desde então, o site do BLM sofreu um número crescente de ataques de grande magnitude, que decidimos incluir em nossa análise, o que adiou a publicação. Este relatório irá explorar esses ataques, correlacionando pesquisas de fontes abertas e atribuições divulgadas publicamente com o que observamos nos dados.
A infraestrutura da Deflect Labs nos permite capturar, processar e traçar o perfil de cada ataque, analisando incidentes específicos e cruzando os resultados com um banco de dados de botnets já mapeadas. Definimos os parâmetros para comportamentos anômalos na rede e, em seguida, agrupamos (“cluster”) os IPs maliciosos em botnets por meio de algoritmos de aprendizado de máquina não supervisionado.
Ataques e atribuição
Como solução de mitigação de DDoS para o site blacklivesmatter.com, a Deflect tem acesso a todas as solicitações legítimas e maliciosas feitas a esse site. No entanto, em quase todos os casos, os ataques ocorrem por meio de máquinas infectadas ou como ataques de reflexão a partir de sites que não suspeitam de nada. Um invasor com algum nível de experiência sabe como ofuscar e disfarçar seus rastros na Internet. Portanto, é extremamente difícil atribuir uma ação a uma pessoa específica ou a um endereço IP com segurança. Contamos com nossas ferramentas analíticas, colegas do setor de mitigação e pesquisas nas redes sociais para testar nossas hipóteses. As suposições decorrentes do OSINT são então verificadas em relação aos dados em nossos sistemas e vice-versa.
A análise técnica e a pesquisa nas redes sociais indicaram que as ações contra o site do BLM foram lançadas por vários atacantes que, com frequência, agiam em conjunto. Alguns métodos, como os ataques de reflexão no Joomla e no WordPress, parecem ter sido coordenados, enquanto em outros casos ficou claro que muitos atores aderiram a um ataque mais poderoso para reivindicar parte do crédito. Esses pequenos grupos, vagamente organizados, surgem minutos ou horas após o início do ataque original e lançam uma mistura heterogênea de vários métodos de ataque, muitas vezes sem efeito. Essas ações costumam ser acompanhadas por uma enxurrada de consultas de várias soluções de monitoramento de tempo de inatividade de sites, à medida que os invasores tentam coletar “troféus” por sua participação no ataque coletivo. Além disso, observamos um agente sofisticado que foi capaz de gerar tráfego malicioso em um nível superior a qualquer outro que documentamos como alvo do BLM. Usando hospedagem à prova de falhas para coordenar seus ataques, ele não se esforçou muito para ocultar sua identidade, criando, em vez disso, uma rede complexa de contas nas redes sociais, possíveis reivindicações públicas falsas de autoria e uma atmosfera de mistério em torno de suas motivações e objetivos.
O “Esquadrão Fantasma”
Os primeiros — e únicos — ataques atribuídos publicamente começaram no final de abril, quando _s1ege, um membro declarado do grupo Ghost Squad Hackers, começou a postar no Twitter capturas de tela mostrando a desfiguração do site e relatórios de serviços de monitoramento de disponibilidade indicando que o site do BLM não estava mais acessível. A ação fazia parte da campanha #OPAllLivesMatter, provavelmente em resposta ao slogan (e posteriormente à hashtag) #AllLivesMatter, criado em 2015. Em 2 de maio de 2016, um vídeo do YouTube publicado por @anonymous_exposes_racism continha um aviso de um grupo que se identificava como Anonymous aos líderes do movimento Black Lives Matter, pedindo que eles também condenassem o racismo contra brancos.
Essa primeira série de ataques contra o BLM, que teve início em 29 de abril, durou apenas 30 minutos. Eles partiram de seis endereços IP e geraram pouco menos de 15.000 conexões. Foi utilizado um único método de ataque e poucos recursos, o que tornou essa pequena ação, na melhor das hipóteses, apenas temporariamente eficaz. Naquela noite, cinco endereços IP diferentes realizaram outro ataque contra o site do BLM, que atingiu um pico de mais de 158.000 conexões ao longo de uma hora.
Durante esse ataque, @_s1ege postou comentários no Twitter assumindo a autoria. Juntamente com fotos que mostravam que o site do Black Lives Matter havia sido temporariamente tirado do ar por esse ataque, _s1ege postou uma foto do software que estava usando, o “BlackHorizon”.
Durante esse ataque, @_s1ege postou comentários no Twitter assumindo a autoria. Juntamente com fotos que mostravam que o site do Black Lives Matter havia sido temporariamente tirado do ar por esse ataque, _s1ege postou uma foto do software que estava usando, o “BlackHorizon”.
O BlackHorizon é um clone de um software de DoS HTTP chamado GoldenEye, que foi escrito por Jan Seidl em 2014. Esse, por sua vez, era uma expansão do projeto HULK de 2012, de autoria de Barry Shteiman. Ao contrário da adaptação e expansão bem pensadas que Seidl fez do HULK, a base de código do BlackHorizon altera principalmente a arte ASCII e o nome do autor. Ao ser examinado, ficou claro que os componentes funcionais do código permaneceram quase totalmente inalterados em relação ao GoldenEye.
Várias publicações da mídia correram para entrevistar _s1ege, com a conta do Twitter @ghostsquadhack e a do Facebook GhostSquadHackers fazendo referência a essas publicações. Cerca de 30 minutos após o segundo ataque, Waqas Amir publicou um artigo no HackRead descrevendo ambos os incidentes, juntamente com sua conversa com um membro do GSH. Mais tarde naquela noite, um membro do GSH voltou a usar um bot anterior e criou um ataque que gerou bem menos de 700 conexões, antes de desistir após menos de 20 minutos.
Logo após os tuítes e a publicação no HackRead, observamos um aumento na frequência e na variedade dos ataques. Apenas uma parte deles apresentava um perfil de comportamento na rede semelhante ao daqueles atribuídos por _s1ege ao GSH. Os invasores estavam usando softwares conhecidos e podem ter convocado outras pessoas na Internet a seguirem o exemplo. Em 10 de maio, @_s1ege anuncia @bannedoffline como novo membro do grupo Ghost Squad e, dois dias depois, deixa de tuitar por completo nessa conta.
Maskirovka
O BLM começou a sofrer ataques em maior escala no dia 9 de maio. O primeiro durou pouco mais de 90 minutos e consistiu em 1.022.981 conexões provenientes de sites legítimos do WordPress. Esse não foi o primeiro ataque de pingback do WordPress contra o site do BLM, mas foi um indício de que estávamos começando a enfrentar adversários preparados para empregar recursos muito maiores do que antes.O nível de gravidade e agressividade continuou a aumentar e, em 9 de julho, testemunhamos um ataque de pingback do WordPress que gerou mais de 34 milhões de conexões ao BLM em um único dia. Os invasores não pareciam interessados em ocultar sua origem, o que nos permitiu rastrear essas atividades nos meses seguintes. Os ataques foram coordenados a partir de máquinas hospedadas em um provedor “à prova de balas” – assim chamado porque oferece servidores para aluguel sem fazer perguntas. Os incidentes associados a esses ataques foram os maiores enfrentados pelo BLM durante o período coberto pelo relatório.
No dia 25 de julho, recebemos uma assinatura do serviço de proteção Deflect de um tal “John Smith”, solicitando que incluíssemos o site http://ghostsquadhackers.org. Rastreamos essa solicitação e as conversas subsequentes com esse usuário até a conta @bannedoffline no Twitter e no Facebook, bem como até o proprietário dos seguintes domínios: ghostantiddos.com; ghostsquadsecurity.com; bannedoffline.xyz; www.btcsetmefree.org, entre outros.
Nossa análise das ações executadas a partir do provedor de hospedagem “à prova de balas” identificou vários endereços IP que foram utilizados para comando e controle. Esses endereços foram correlacionados por um provedor de mitigação que havia desafiado @bannedoffline, em um fórum de hackers, a lançar um ataque DDoS contra eles e registrou a atividade resultante. Dois endereços IP, um pertencente ao provedor DMZhosting mencionado mais adiante neste relatório e uma máquina da Digital Ocean, foram identificados em nossos registros individuais – e correlacionados a oito incidentes distintos em nosso estudo.
- 191.96.249.80 Dmzhost Limited https://dmzhost.co
- 178.62.152.134 DigitalOcean https://www.digitalocean.com
É difícil afirmar com certeza por que não houve mais atribuições públicas aos ataques ao BLM após a primeira semana de maio, considerando que a gravidade e a sofisticação aumentaram várias vezes. @bannedoffline excluiu todas as suas postagens nas redes sociais no final de setembro, pouco antes de registrarmos o maior ataque contra o site do BLM. O @bannedoffline também foi associado a um ataque de 665 Gbps (o maior ataque da época, antes das botnets Mirai) contra o site Krebs on Security. O Ghost Squad não confirmou nem negou a participação contínua de @bannedoffline em seu grupo. Os ataques atribuíveis a @bannedoffline e _s1ege — que muito bem poderiam ser a mesma pessoa — representaram menos de 20% da atividade de DDoS registrada contra o BLM.
Análise Técnica de Ataques
Os incidentes que utilizavam um método de ataque semelhante foram identificados por meio de um processo iterativo de identificação de possíveis características comportamentais que distinguem um tipo de ataque dos demais. Primeiramente, identificamos combinações de comportamentos e características que distinguiam possíveis ataques do tráfego normal. Esses perfis foram então comparados aos tipos de ataques existentes, por meio da busca por assinaturas em outros relatórios e em bases de código conhecidas desses ataques, a fim de criar um perfil do método de ataque. Nesse ponto, características secundárias do ataque foram examinadas para verificar se elas distinguiam ataques individuais. Isso variava desde o provedor de hospedagem utilizado pelos “botherders” até a coleção de sites inofensivos usados como refletores e os métodos utilizados para verificar o status do site, entre outros. Se uma ou mais dessas características se sobrepunham para um conjunto específico de ataques, esses ataques eram sinalizados para investigação mais aprofundada. Depois de agruparmos esses ataques, analisamos todo o conjunto de ataques e tentamos rejeitar qualquer característica que pudesse diferenciar claramente esse subconjunto de ataques de ataques semelhantes.
A categoria mais comum de ataques contra o site da BLM tem sido os ataques de inundação HTTP “no nível da aplicação” (camada 7). Esses bots imitam o comportamento humano ao se conectarem a um site e solicitarem uma grande quantidade de conteúdo até que o servidor entre em colapso por falta de recursos. Neste relatório, analisaremos apenas esse tipo de ataque.
A capacidade dos atacantes individuais variou consideravelmente. À medida que o site do BLM enfrentava atacantes com mais recursos e mais eficazes, a turba tornou-se um ruído de fundo persistente.
| Tipo de ataque (incluindo variantes e clones) | abril | maio | junho | julho | ago | Setembro | Outubro |
| Pingback do WordPress | 5 | 6 | 4 | 4 | 5 | ||
| Pingback do Joomla | 1 | 6 | 6 | 4 | 3 | 3 | |
| Loris lento | 2 | 5 | 3 | 1 | |||
| Inundação NoCache totalmente aleatória | 6 | 14 | 11 | 5 | 7 | 2 | 4 |
| Inundação por contornamento de cache | 1 | 1 | 2 | 2 | |||
| Inundação de scripts em Python | 2 | 2 |
Loris lento
| Aliases/Ferramentas | Slowloris, Pyloris, Torloris |
| Tipo de ataque | Ataque de negação de serviço na camada 7 |
| Vulnerabilidades | Esgotamento de conexões |
| Ofuscação | Nenhum |
| Classe de Ataque | De fonte única |
| Taxa de ataque | Baixo |
O primeiro ataque identificado contra o site do Black Lives Matter ocorreu em 18 de abril, poucos dias após a migração para o Deflect. Um único endereço estabeleceu entre 5 e 30 conexões por segundo com a página principal do BLM. Isso durou 28 segundos. No total, foram realizadas apenas 168 conexões. Normalmente, esse tipo de comportamento não levantaria suspeitas. Mas, neste caso, o agente de usuário desse cliente correspondia ao agente de usuário utilizado no código original da prova de conceito do“Slowloris – o cliente HTTP de baixa largura de banda, mas voraz e malicioso!”
O Slowloris é uma ferramenta de DoS lançada originalmente em 2009. Ele se destaca entre os outros ataques de Camada 7 que discutiremos neste relatório, pois não se concentra em inundar a rede com tráfego. Em vez disso, ele tenta esgotar todas as conexões com um servidor web, não deixando nenhuma disponível para usuários legítimos. Esse baixo número de conexões permite que o Slowloris ataque um site sem chamar a mesma atenção que uma inundação de tráfego causaria. Foram identificados 12 ataques utilizando a base de código original do Slowloris desde que o site do BLM passou a ser protegido pelo Deflect. Todos esses ataques, com exceção de um, tiveram menos de 1.000 conexões. O maior ataque do Slowloris ocorreu no dia 10 de julho, das 0h50 às 3h20 e das 6h às 7h20, estabelecendo mais de 40.542 conexões — o que demonstra claramente um uso indevido dessa ferramenta ou uma falta de compreensão de sua finalidade original.
Na versão inicial do código, o Slowloris utilizava um único agente de usuário. Atualmente, muitas das versões personalizadas do Slowloris alteraram o agente de usuário [pyloris.py] ou adicionaram ofuscação do código-fonte do cliente, selecionando aleatoriamente a partir de uma lista de agentes de usuário [slowloris.py]. Não é surpreendente ver alguém usando uma versão não modificada de uma ferramenta tão obscura, mesmo quando o servidor utilizado no site do BLM está protegido contra esse tipo de ataque. Muitos dos autores que realizam ataques DoS não estão se baseando em ferramentas existentes. Embora o Slowloris fosse elegante na época, o cenário de ataques DoS é dominado por invasores que utilizam medidas simplistas. Isso ocorre porque não é necessária uma ferramenta altamente complexa para derrubar a maioria dos sites na Internet.
Os ataques do Slowloris ao site do BLM tendem a coincidir ou ocorrer na mesma época que dois ataques de baixa complexidade do tipo “inundação HTTP básica”: [Blank] e [Python], bem como os ataques (Blank+WordPress) ao WordPress.
Ataques de inundação HTTP
Os ataques de inundação HTTP são fáceis de implementar e difíceis de identificar. Geralmente, eles tentam esgotar os recursos de aplicativos de um sistema ou a largura de banda da rede. Isso é feito seja criando uma grande quantidade de conexões com o site, seja baixando continuamente uma grande quantidade de arquivos. Como exigem apenas que o invasor crie muitas conexões legítimas com um servidor, os ataques de inundação HTTP são bastante fáceis de implementar. Como essas conexões são legítimas, pode ser muito difícil para quem está defendendo o sistema diferenciá-las das conexões de usuários reais.
Ataque simples de inundação HTTP
| Aliases/Ferramentas | Nenhum |
| Tipo de ataque | Ataque de negação de serviço na camada 7 |
| Vulnerabilidades | Nenhum |
| Ofuscação | Nenhum |
| Classe de Ataque | De fonte única |
| Taxa de ataque | Baixo |
Um exemplo simples desse tipo de ataque pode ser observado no dia 30 de abril. Por pouco menos de dez minutos, um único endereço realizou um ataque de solicitações HTTP GET de baixa sofisticação contra o site do Black Lives Matter. Durante um período de cinco minutos, esse invasor estabeleceu 1.503 conexões a partir de um único endereço, utilizando um agente de usuário do Internet Explorer. O site do BLM recebeu apenas algumas dessas conexões, pois o invasor foi bloqueado em menos de um segundo.
Python Básico
| Aliases/Ferramentas | Nenhum |
| Tipo de ataque | Ataque de negação de serviço na camada 7 |
| Vulnerabilidades | Nenhum |
| Ofuscação | Nenhum |
| Classe de Ataque | De fonte única |
| Taxa de ataque | Baixo |
Apenas algumas horas após o término do ataque HTTP Flood anterior, dois ataques diferentes começaram e cessaram. Eles ocorreram com apenas dois minutos de diferença entre si. O primeiro foi um “ataquede inundação NoCache totalmente aleatório”e estabeleceu 2.000 conexões durante os dois minutos de duração do ataque. O segundo foi um teste de um ataque de inundação HTTP ainda mais simples do que o exemplo anterior. O código por trás desse ataque foi escrito sem qualquer tentativa de fazê-lo parecer proveniente de um usuário legítimo. Durante os seis minutos de ataque, esse script estabeleceu cerca de 400 conexões. Também ocorreram 23 conexões a partir de um navegador Chrome no mesmo endereço IP durante esse período, já que o invasor atualizava freneticamente a página da web para verificar o impacto causado. Assim como no ataque anterior, levou menos de um segundo para que esse endereço IP fosse bloqueado.
Embora um ataque DoS não precise de muita sofisticação para ser eficaz, mencionamos isso aqui porque sua assinatura única indica que esse ataque foi criado por um programador inexperiente. Para explicar o quão básico é esse ataque, os pesquisadores do Deflect Labs recriaram uma versão funcional dele a seguir.
import urllib
while True:
urllib.urlopen("http://www.blacklivesmatter.com")
Esse invasor voltou algumas horas depois, usando um endereço diferente. Assim como em muitos ataques de fonte única, é provável que ele estivesse usando um proxy para ocultar o IP original de seus ataques enquanto realizava esses testes. Antes de executar o script em Python, ele realizou o mesmo ataque “Fully Randomized NoCache Flood” por cerca de um minuto e, em seguida, voltou rapidamente ao seu script em Python. O script em Python estabeleceu outras 429 conexões durante o ataque, que durou aproximadamente seis minutos. Assim como antes, ele foi interrompido em questão de segundos.
Esse comportamento de teste continuou nos dias seguintes. Houve outro pequeno ataque na manhã de 1º de maio, que estabeleceu até 700 conexões em pouco menos de 10 minutos, e outro com pouco mais de 1.000 conexões em pouco menos de 20 minutos. No final daquela semana, esse invasor havia concluído seu experimento na tentativa de criar seu próprio script. Sua natureza simples fazia com que ele fosse bloqueado automaticamente quase assim que se conectava. Em seu pico, ele conseguia criar apenas cerca de cem conexões por minuto, o que é muito pouco para uma máquina realizando um ataque DoS.
Ataque DDoS por inundação de HTTP
| Aliases/Ferramentas | Nenhum |
| Tipo de ataque | Ataque de negação de serviço na camada 7 |
| Vulnerabilidades | Nenhum |
| Ofuscação | Nenhum |
| Classe de Ataque | De várias fontes |
| Taxa de ataque | Alto |
Os ataques de inundação HTTP que descrevemos até agora nesta seção vieram apenas de uma única fonte. Nesta seção, exploraremos como uma botnet pode utilizar milhares de máquinas para realizar um ataque de inundação HTTP distribuído e como podemos identificar esses ataques em meio ao tráfego normal.
Ataques de inundação HTTP que envolvem muitas fontes (ataques DDoS) são difíceis de identificar, pois podem parecer muito semelhantes ao tráfego normal. Mas, como o site do BLM, assim como qualquer outro, apresenta padrões de tráfego que refletem o comportamento geral de seu público habitual, há alguns exemplos claros de ataques DDoS de inundação HTTP que podemos analisar.
Como era de se esperar, as pessoas nos EUA acessam o site do BLM com muito mais frequência do que outros grupos. Isso também afeta os padrões de tráfego do site. O tráfego no site do BLM segue um padrão cíclico diário. Há um pico de tráfego entre 12h e 14h (horário da costa leste dos EUA, EST). (Os números em nossas capturas de tela refletem registros de data e hora no fuso horário UTC+0.) Depois disso, o tráfego diminui até por volta das 7h (horário da costa leste dos EUA, EST), quando atinge um pico à noite e, em seguida, diminui novamente durante a madrugada.
Entre 5 e 9 de agosto, o padrão de uso por hora mudou de um padrão uniforme, como o mostrado acima, para este.
Naquela semana, entre 11h e 13h (horário da costa leste dos EUA), houve um pico de tráfego proveniente da China, Indonésia, Turquia e Eslovênia. Embora a equipe da Deflect Labs não se surpreenda com o fato de o BLM receber atenção internacional, é um pouco estranho ver isso ocorrendo simultaneamente em todo o mundo. Ao procurar por ataques de inundação HTTP com múltiplas fontes, conhecer esses padrões de uso pode facilitar muito a identificação de possíveis ataques como esse.
A anomalia que podemos observar acima foi um ataque de inundação de solicitações HTTP POST ocorrido em 8 de agosto. Considerando as dezenas de países por minuto que apresentam um número de conexões acima da média, parece plausível que esse ataque tenha utilizado uma botnet de máquinas infectadas.
Durante um período de pouco mais de uma hora, 11.514 máquinas tentaram enviar (POST) uma série de arquivos grandes para o site do BLM. Isso gerou uma enxurrada de solicitações com grande volume de dados que o site do BLM teve que processar.
Inundação NoCache totalmente aleatória
| Aliases/Ferramentas | Hulk, GoldenEye, BlackHorizon |
| Tipo de ataque | Ataque de negação de serviço na camada 7 |
| Vulnerabilidades | KeepAlive, NoCache |
| Ofuscação | Ofuscação do cliente de origem, falsificação de referência |
| Classe de Ataque | De várias fontes |
| Taxa de ataque | Alto |
Sites protegidos por serviços de mitigação de DDoS — como o Deflect — utilizam um sistema de “cache” para armazenar páginas frequentemente solicitadas e disponibilizá-las aos usuários, de modo que o servidor do site protegido não precise fazê-lo. Esse “cache” de páginas da web solicitadas recentemente permite que o Deflect limite ainda mais as solicitações feitas ao servidor protegido. Mesmo que bots simples, como os mencionados na seção anterior, consigam contornar o bloqueio, eles geralmente estão apenas recebendo respostas dos caches do Deflect com URLs solicitadas recentemente, sem causar nenhum impacto no servidor de origem.
Os provedores de ataques DoS responderam ao uso do cache criando um bot que engana o cache, fazendo-o acreditar que está solicitando uma página que nunca foi solicitada antes. Esses ataques de inundação HTTP do tipo “Cache-bypass” são bots que acrescentam uma consulta aleatória ao final de suas solicitações. Essas consultas geradas aleatoriamente fazem com que o cache considere cada solicitação como uma nova solicitação, embora os bots que estamos analisando neste relatório tenham solicitado apenas a URL principal do BLM, “blacklivesmatter.com”.
O GoldenEye é uma ferramenta de DoS da Camada 7. Ele permite que um único computador abra várias conexões com um site, cada uma delas fingindo ser um dispositivo diferente. Para isso, o GoldenEye fornece uma string de agente de usuário diferente para cada conexão. Ao longo de uma hora e meia de ataques combinados, esses 11 bots fingiram ser centenas de tipos diferentes de usuários para evitar a detecção.
Mais tarde, na noite de 30 de abril, foi tentado outro ataque envolvendo pouco menos de 11.000 conexões. Esse ataque utilizou uma versão aprimorada do “Fully Randomized NoCache Flood”. Embora o ataque comece com 9 bots utilizando algo semelhante ao código usado pelo GSH, um único endereço se junta ao ataque um minuto após o início e rapidamente supera os demais atacantes tanto em número de conexões quanto na variedade de agentes de usuário que emprega.
Se não fosse pela variedade de intensidade e métodos utilizados pelos endereços individuais, ataques como esse pareceriam envolver um único agente. Mas, como é comum em ataques contra o site do BLM, esse ataque começa lentamente com um ou dois agentes iniciais, aos quais se junta, em seguida, um pequeno grupo de “valentões que se juntam à onda”. Assim como se observou nos primeiros ataques do GSH, eles compartilham as ferramentas utilizadas em seus ataques com os demais invasores. Seja quem for esse invasor que surgiu mais tarde, ele claramente não é apenas mais um membro da equipe. Esse invasor dispõe de recursos de rede consideravelmente diferentes e, provavelmente, de um software que lhe permite causar um impacto muito maior do que todos os membros participantes da equipe GSH juntos.
Ataque DDoS por reflexão
Ataque DDoS por reflexão no Joomla!
| Aliases/Ferramentas | DAVOSET, UFONet |
| Tipo de ataque | Ataque de negação de serviço na camada 7 |
| Vulnerabilidades | Nenhum |
| Ofuscação | Nenhum |
| Classe de Ataque | Refletido |
| Taxa de ataque | Alto |
Em 2013, foi descoberta uma série de vulnerabilidades em um plugin do Google Maps para o CMS Joomla!. Uma delas permitia que qualquer pessoa fizesse com que um site Joomla! enviasse uma solicitação HTTP a sites remotos. Em junho de 2013, essa vulnerabilidade já havia sido explorada e incluída em uma estrutura de DDoS existente chamada DAVOSET (ferramenta de execução de ataques DDoS por meio de outros sites). Em 2014, essa mesma vulnerabilidade foi incluída na estrutura de DDoS UFOnet.
Cada uma dessas estruturas de DDoS possui interfaces baseadas na web, fáceis de usar, do tipo “apontar e clicar”, além de uma lista integrada de sites vulneráveis do Joomla!. Isso as torna ideais para um invasor com poucos recursos ou sem grande experiência que pretenda amplificar outro ataque. Dos 23 ataques ao WordPress realizados contra o site do BLM, apenas 7 deles não foram acompanhados por um ataque ao Joomla!.
Inicialmente, era difícil identificar ataques ao Joomla! porque a maioria das conexões não fornecia uma string de agente de usuário. Agentes de usuário vazios são relativamente comuns na Internet. Muitos bots não maliciosos, mas criados às pressas, não fornecem um agente de usuário. Assim, quando observamos inicialmente esses picos de tráfego, presumimos que fossem provenientes de outro bot DoS criado de forma descuidada.
Depois de observarmos esse bot acompanhando ataques de diversos invasores, aprofundamos a investigação e identificamos uma assinatura oculta no tráfego que nos levou ao ataque ao Joomla!. Embora a maioria dos agentes de usuário utilizados pelos sites do Joomla! para fazer essas solicitações esteja em branco, um pequeno subconjunto dessas máquinas inclui a versão da linguagem PHP que foi usada para executar a solicitação. Embora agentes de usuário em branco sejam relativamente comuns, muitos dos ataques que os incluíam eram combinados com agentes de usuário que continham versões do PHP. Dada a relativa raridade do PHP, percebemos que o aumento incomum de agentes de usuário vazios, em conjunto com outros ataques, se devia ao fato de eles estarem sendo combinados com ataques ao Joomla!
Introdução aos ataques de inundação XMLRPC no WordPress
| Aliases/Ferramentas | Pingback do WordPress |
| Tipo de ataque | Ataque de negação de serviço na camada 7 |
| Vulnerabilidades | NoCache |
| Ofuscação | Falsificação de identidade |
| Classe de Ataque | Refletido |
| Taxa de ataque | Alto |
Por padrão, o WordPress possui um recurso chamado “pingback”, criado para permitir que sites do WordPress notifiquem outros blogs quando estes criam um link para seu conteúdo. Em linhas gerais, isso funciona de maneira semelhante a uma menção no Twitter. Quando um site do WordPress publica um post que contém um link para outro site, ele envia um “pingback” para esse site com um link para o post que contém o link original. Se o site destinatário também for baseado no WordPress, ele responde ao site original para confirmar que recebeu o pingback.
Os pingbacks fazem parte dos sites do WordPress desde a versão 1.5, lançada em 2005. Foi somente em 2012 que Christian Mehlmauer divulgou uma implementação funcional de código que aproveitava esse recurso para solicitar que os sites do WordPress verificassem “pingbacks” provenientes de URLs falsificadas. Dois anos depois, em março de 2014, a Akamai publicou um artigo que descrevia um ataque de “pingback” envolvendo mais de 162.000 sites do WordPress. Em setembro de 2015, a empresa anunciou que os ataques de pingback ao WordPress representavam 13% de todos os ataques de Camada 7 que enfrentavam.
Às 22h do dia 1º de maio, teve início um ataque de pingback no WordPress direcionado ao site do Black Lives Matter. Em apenas 13 minutos, foram realizadas 181.301 conexões. À medida que esse ataque ao WordPress foi diminuindo, um ataque ao Joomla! tomou seu lugar. No momento em que o ataque ao WordPress começou, o segundo invasor passou a usar serviços online gratuitos dezenas de vezes por minuto para verificar se o site do Black Lives Matter havia ficado fora do ar. Com o início do segundo ataque, o invasor aumentou a frequência com que monitorava o estado do site. Quatro minutos após o início do ataque, quando ficou claro que ele havia sido bem-sucedido, o invasor parou de verificar o site. No total, esse ataque consistiu em cerca de 350.000 conexões em um período de menos de uma hora.
Conforme mencionado no boletim original, os ataques mais intensos contra o site do Black Lives Matter foram ataques de pingback no WordPress. O primeiro ataque em grande escala contra o site do BLM foi um ataque ao WordPress ocorrido em 9 de maio. Esse ataque gerou mais de 1.130.000 conexões em pouco menos de três horas. Foi uma combinação de mais de 1.000.000 de conexões provenientes de um ataque de pingback do WordPress com 100.000 conexões de um “Fully Randomized NoCache Flood”.
As seções a seguir do WordPress apresentarão alguns exemplos ilustrativos para mostrar como exploramos as relações entre esses bots. No entanto, não examinaremos todos os ataques. Tampouco tentaremos atribuir os ataques à sua origem.
Pingbacks do WordPress e endereços do Botherder
Embora os ataques ao WordPress funcionem de maneira semelhante aos ataques ao Joomla!, eles são muito mais fáceis de identificar. Esses ataques indicam claramente a versão do WordPress como seu agente de usuário. Como esses ataques começaram a se tornar mais comuns, um novo recurso foi lançado na versão 3.9 do WordPress. Essa versão atualizou os pingbacks para incluir o endereço IP que fez a solicitação original do pingback.
WordPress/4.6; http://host.site.tld; verificando pingback de 127.0.0.1
Chamamos esses endereços IP de “endereços botherder”. Alguns desses endereços correspondem a endereços IP endereçáveis globalmente, aos quais é possível acessar pela Internet. Outros são endereços que nunca deveriam aparecer na Internet pública. Esses endereçosbogon são endereços privados/reservados e blocos de rede que não foram atribuídos a um registro regional da Internet. O endereço bogon visto no exemplo acima é chamado de localhost. É o endereço IP usado por um computador para se referir a si mesmo.
Embora a inclusão do endereço do remetente tenha sido implementada para desanonimizar a verdadeira origem de um ataque, a maioria dos invasores é muito hábil em ocultar seu endereço IP real por meio do uso de pacotes falsificados, proxies, servidores privados virtuais (VPSs) e máquinas comprometidas para realizar as solicitações originais. Quando começamos a investigar os endereços dos “botherders”, presumimos que encontraríamos apenas endereços falsificados. Para nossa surpresa, os endereços dos “botherders” revelaram muito mais do que esperávamos. Ao agrupar os IPs dos “botherders” expostos em um ataque, conseguimos desenvolver perfis comportamentais que nos ajudaram a relacionar diferentes ataques entre si para entender quais provavelmente foram realizados pelo mesmo invasor.
A primeira coisa que analisamos foram os endereços IP dos servidores de hospedagem utilizados nos ataques do WordPress contra o site do BLM. Nossa análise desses endereços falsos revelou relações claras entre os ataques, que puderam ser identificadas ao examinarmos os endereços dos servidores de hospedagem.
A grande bola azul de endereços IP compartilhados, no lado esquerdo do gráfico de bogons acima, envolve dois pequenos incidentes ocorridos nos dias 8 e 9 de agosto. Essa enorme bola de endereços IP compartilhados é composta por mais de 500 endereços provenientes dos espaços de endereços IP privados. Especificamente, ela inclui 382 endereços do intervalo 172.16.0.0/12 e 177 endereços do intervalo 10.0.0.0/8. Intervalos de endereços privados não são totalmente incomuns em ataques de pingback no WordPress. Eles podem surgir quando o invasor está no mesmo provedor de hospedagem que os sites WordPress que está explorando e também podem ser criados quando um invasor está falsificando endereços aleatórios. O que é incomum é a clareza com que os endereços IP bogon sobrepostos ligam esses dois ataques.
Havia também endereços IP de atacantes que podiam ser rastreados globalmente e que ligavam entre si cada um dos ataques individuais contra o BLM. É provável que existam áreas com pouca sobreposição de endereços IP, pois muitos atacantes estavam claramente falsificando endereços IP. No entanto, as áreas com muitas conexões revelaram relações que valiam a pena explorar.
Uma característica comum a todos os ataques foi que, embora cada um deles tenha centenas de endereços de bots falsificados que aparecem apenas uma ou duas vezes, há também um pequeno número de endereços de bots que representam a maioria dos bots mobilizados para o ataque. Nos ataques de 8 e 9 de agosto, que podem ser observados na parte inferior do gráfico de endereços IP globalmente acessíveis, três endereços IP foram responsáveis por 95% (13.963 / 14.585) das conexões do WordPress que identificaram um bot.
Como o principal objetivo do Deflect é a mitigação de ataques DDoS, as investigações da Deflect Labs geralmente ocorrem dias ou semanas após o ocorrido. Isso significa que, muitas vezes, precisamos contar com nossos registros e com informações de inteligência de código aberto. Nesse caso, uma das primeiras coisas que analisamos foi quem era o proprietário dos três principais endereços IP dos atacantes. Esses endereços IP pertencem à Digital Ocean, um provedor de VPS com sede em Nova York. A Digital Ocean não fornece vários endereços IP por máquina; portanto, sabemos que esse ataque foi conduzido por três “droplets” distintos da Digital Ocean. O preço por hora dos droplets da Digital Ocean varia entre US$ 0,007 e US$ 0,119. Como cada um desses ataques durou menos de meia hora, o custo para executá-los ficou bem abaixo de um dólar.
Hospedagem “à prova de balas”
De longe, o maior conjunto de ataques associados ao WordPress ocorreu entre julho e outubro. Esse conjunto de ataques inclui os cinco maiores ataques registrados nesse período de quatro meses.
Entre os 206 endereços IP acessíveis globalmente utilizados nesses ataques, 5 endereços IP de servidores de spam representam 65% (41.030 / 62.488) dos endereços IP de servidores de spam identificados no ataque. Cada um desses servidores de ataque estava hospedado em um provedor de hospedagem “offshore” chamado DMZHOST. Os dois endereços IP de servidores de ataque mais conectados em nossos ataques são mencionados inúmeras vezes em diversos sites de reputação de endereços IP, fóruns e até mesmo em posts de blogs como a fonte de uma variedade de ataques semelhantes.
Provedores de “hospedagem à prova de balas”, como a DMZHOST, oferecem VPSs que se anunciam como estando fora do alcance das autoridades ocidentais. A DMZHOST oferece aos seus clientes VPSs “offshore” em um“bunker de privacidade em um datacenter seguro na Holanda”e“não armazena nenhuma informação/registro sobre a atividade do usuário”.Ao mesmo tempo, os termos de serviço da DMZHOST são igualmente concisos. “A DMZHOST não permite nada (relacionado) aos seguintes conteúdos: – DDoS – Pornografia infantil – Exploração de vulnerabilidades bancárias – Terrorismo – NÃO NTP – NÃO SPAM por e-mail”.
Conclusão
Silenciar vozes online está se tornando cada vez mais fácil e barato na Internet. Os maiores ataques apresentados neste relatório não exigiram infraestrutura cara; eles foram simplesmente refletidos a partir de outros sites para ampliar seu impacto. Começamos a ver as autoridades perseguirem e encerrarem serviços de hospedagem “à prova de balas” e de “booter” que possibilitam muitos desses ataques, mas ainda há muito a ser feito. Na era que se aproxima das botnets de IoT, quando começarmos a testemunhar ataques capazes de gerar mais de um terabyte de tráfego por segundo, a comunidade de mitigação não deve guardar suas informações sobre atividades maliciosas, mas sim compartilhá-las de forma responsável e eficiente. O Deflect Labs é um pequeno projeto que está lançando as bases para uma inteligência de código aberto, impulsionada pela comunidade, sobre a classificação e exposição de botnets. Convidamos você a entrar em contato caso queira contribuir.
O Deflect é um projeto de segurança de sites que trabalha com a mídia independente, organizações de direitos humanos e ativistas. Ele oferece mitigação de ataques DDoS, hospedagem segura e análise de ataques, de forma gratuita para organizações que se enquadrem nos critérios. Todas as nossas ferramentas são de código aberto e operamos de acordo com termos de serviço rigorosos e princípios que promovem a privacidade de nossos clientes. O Deflect é um projeto da eQualit.ie, uma organização canadense sem fins lucrativos que atua na promoção e defesa dos direitos humanos na era digital.