Relatório de ataques DoS/DDoS contra sites protegidos pelo Deflect entre 7 e 22 de outubro de 2023
INTRODUÇÃO
A violência que assolou Israel e Gaza nas últimas semanas também se espalhou pelo espaço digital. Desde imagens horripilantes de assassinatos em nossas telas de computador até discursos de ódio em todas as plataformas de mídia social. A infraestrutura da Deflect tem sido, há muitos anos, um espaço seguro para grupos de direitos humanos, meios de comunicação e instituições civis israelenses e palestinos. A equipe do Deflect continua a aplicar os princípios e os termos de serviço do nosso projeto para garantir que a rede não seja usada como plataforma para promover violência ou ódio. Também buscamos a permissão explícita de nossos clientes antes de divulgar sua associação com o Deflect e de relatar ataques que visam silenciá-los.
Desde 7 de outubro de 2023, a Deflect registrou seis ataques significativos do tipo DoS/DDoS contra organizações de direitos humanos israelenses (btselem.org), que culminaram em 54 milhões de eventos de ataque contra nossos servidores de borda. Também registramos 11 ataques DoS/DDoS significativos contra o site de notícias palestino (palestinechronicle.com), com um total de 7 milhões de acessos maliciosos em diversas formas de ataque.
COBERTURA
Este relatório abrange apenas os registros HTTP/HTTPS da camada L7. Pode haver mais tráfego de ataque abaixo da camada L7, mas isso não é abordado neste relatório. Portanto, não fornecemos informações sobre o volume de tráfego (como 1 GB de tráfego por segundo).
Um ataque com uma “taxa de bloqueio” mais alta pode subestimar a magnitude original do ataque. Pois, após o bloqueio do Deflect, o IP atacante será bloqueado no nível do firewall, impedindo que quaisquer outras solicitações provenientes desse IP cheguem ao nosso servidor.
Sites com parâmetros técnicos diferentes podem apresentar comportamentos distintos no registro de logs. Um site em que o JS Challenger esteja constantemente ativado, desafiando todas as solicitações, mas que não bloqueie por firewall os IPs que falharem em muitos desafios, pode resultar em um maior volume de tráfego de ataque registrado nos logs.
METODOLOGIA
Para distinguir os ataques do tráfego normal, utilizamos a seguinte metodologia:
Identifique se houve um pico no tráfego total ou no registro de bloqueios durante um intervalo de 24 horas.
Limite a busca a esse intervalo de tempo para identificar anomalias, que geralmente incluem:
Excesso de solicitações em determinada URL (como a raiz /)
Excesso de solicitações com o mesmo User-Agent provenientes de endereços IP diferentes
Distribuição uniforme do User-Agent e do método HTTP que é perfeita demais para ser verdade
String de consulta exclusiva excessiva (como ?v={rand}) para evitar o cache
Verifique se os IPs com maior tráfego acionaram alguma de nossas regras de limitação de taxa.
Verifique com o sistema Baskerville, um sistema de aprendizado de máquina que detecta tráfego anômalo.
ATAQUE: BTSELEM.ORG
Parâmetros: JS Challenger: Ativado / Resultado em caso de falha no desafio ou atingimento do limite de tentativas: Sem banimento
#
Data
Início (+0)
Duração (s)
Solicitação HTTP
RPS
IP exclusivo
Proibições exclusivas
Taxa de proibição
B1
9 de outubro de 2023
20:37:51
997
52.497.380
52.644
245
165
67,35%
B2
13/10/2023
15:37:26
2665
291.192
109
1
1
100,00%
B3
16/10/2023
15:02:08
123
146.066
1.186
1.833
1.416
77,25%
B4
16/10/2023
22:32:55
483
1.068.436
2.211
3.611
2.403
66,55%
B5
18/10/2023
0:03:12
141
165.171
1.168
3.133
2.755
87,93%
B6
20/10/2023
13:24:30
181
133.930
739
2.606
2.281
87,53%
Gráfico A: Visualização do registro de bloqueios do Deflect / Banjax do ataque #B1
O ataque #B1 é considerado o mais potente registrado neste relatório. Ele atingiu uma média de 52.644 solicitações por segundo (RPS). Os seis principais endereços IP de origem enviaram, em média, 3 milhões de solicitações em um período de 10 minutos. Os invasores empregaram uma estratégia de “inundação aleatória sem cache” (Randomized Nocache Flood), utilizando strings de consulta variadas para contornar o cache. Notavelmente, observou-se que a mesma string de consulta estava sendo usada por diferentes endereços IP de várias localidades ao redor do mundo.
O ataque #B2 teve origem em um único endereço IP: 46.210.30.130. No entanto, uma aparente configuração incorreta na ferramenta do invasor fez com que todas as suas solicitações fossem rejeitadas pelo nosso servidor.
O ataque #B3 apresentava strings de user-agent com pequenas variações nos números de versão, mantendo uma estrutura básica consistente. No entanto, elas não eram totalmente únicas; detectou-se que a mesma string de user-agent estava sendo usada por 37 endereços IP diferentes.
O Ataque #B4 adotou uma estratégia semelhante à do Ataque #B3, mas apresentou um leque mais amplo de agentes de usuário e teve como alvo específico o endpoint /hebrew, em vez do diretório raiz do site (/).
Gráfico B: Reação de Baskerville ao ataque #B4
O Ataque #B5 seguiu as mesmas táticas observadas no Ataque #B3, mas utilizou um conjunto diferente de user-agents.
O ataque #B6 compartilhou três strings de User-agent idênticas entre os 2.606 endereços IP.
ATAQUE: PALESTINECHRONICLE.COM
Parâmetros: Js Challenger: Desativado / Resultado do limite de taxa de acertos: Bloqueio pelo firewall
#
Data
Início (+0)
Duração (s)
Solicitação HTTP
RPS
IP exclusivo
Proibições exclusivas
Taxa de proibição
P1
8 de outubro de 2023
8:26:53
515
88.014
171
1.879
917
48,80%
P2
8 de outubro de 2023
14:42:26
925
86.991
94
1
1
100,00%
P3
9 de outubro de 2023
10:16:30
299
364.241
1.218
1.632
1.445
88,54%
P4
9 de outubro de 2023
22:34:09
154
1.198.752
7.764
1
1
100,00%
P5
10/10/2023
13:11:02
739
230.643
312
2.002
1.721
85,96%
P6
10/10/2023
17:06:39
668
2.869.176
4.294
708
532
75,14%
P7
12/10/2023
20:27:52
272
711.511
2.613
1.506
867
57,57%
P8
12/10/2023
20:57:58
248
738.380
2.977
1.142
938
82,14%
P9
13/10/2023
0:32:16
181
458.354
2.533
828
746
90,10%
P10
13/10/2023
9:25:37
177
291.291
1.648
759
710
93,54%
P11
21/10/2023
16:31:55
117
269.027
2.305
2.228
1.347
60,46%
Gráfico C: Visualização do registro de bloqueios do Deflect / Banjax do ataque #P6
Os ataques #P2 e #P4 foram perpetrados por um único endereço IP. Ambos tiveram como alvo a porta HTTP 80 e não seguiram o redirecionamento 301 para HTTPS. As solicitações 301 excessivas só passaram a ser bloqueadas a partir de 14 de outubro.
O ataque #P6 foi executado principalmente a partir de um único endereço IP, que, da mesma forma, não respeitou os redirecionamentos 301 emitidos pelo Deflect.
Os ataques #P7, #P8, #P9 e #P10 apresentaram semelhanças em sua abordagem; todos utilizaram uma string de user-agent distribuída uniformemente, o que sugere que foram observadas strings de user-agent idênticas em vários endereços IP.
CORRELAÇÃO DE ATAQUES
Observamos sobreposições significativas nos endereços IP dos atacantes em vários ataques DDoS aos sites palestinechronicle.com e btselem.org, o que sugere tentativas coordenadas por parte dos autores dos ataques. Aqui estão as conclusões:
Os ataques #P9 e #P10 compartilharam aproximadamente 50 endereços IP de ataque em comum.
Os ataques #P7 e #P8 tiveram cerca de 30 endereços IP de ataque idênticos.
Vale destacar que os ataques #P7, #P8, #P9 e #P10 parecem ter origem na mesma fonte de ataque, o que é comprovado por uma forte sobreposição dos endereços IP de origem.
Os ataques #P3 e #P6 tinham seis endereços IP em comum. Já os ataques #P1 e #P5 também compartilhavam seis endereços IP idênticos. A recorrência de endereços IP compartilhados em ataques distintos sugere uma possível, embora fraca, conexão com uma fonte comum de ataque ou entidades afiliadas.
Os ataques #B4, #B5 e #B6 tinham 32 endereços IP de ataque em comum, o que sugere que eles possam ter vindo da mesma fonte de ataque.
Houve também endereços IP que atacaram ambos os sites:
Os endereços IP 186.121.235.66, 187.141.184.235, 201.91.82.155 e 36.91.45.11 tiveram como alvo tanto o #B3 quanto o #P6.
Endereços IP 186.121.235.66, 187.141.184.235, 201.91.82.155, 36.91.45.11, 123.126.158.50, 223.112.53.2, 5.95.66.74, 79.107.146.14 e 190.90.8.74 atacaram tanto o #B3 quanto o #P3.
Dos 13 endereços IP que tiveram como alvo o ataque #B1, três também atacaram o ataque #P6 e seis tiveram como alvo o #P3.
PRINCIPAIS IPs DE ATAQUE
Esta é uma lista de endereços IP com número excessivo de solicitações registradas no Deflect, associados a conteúdo impróprio (ver # para o ID do ataque correspondente).
#
IP
AS
Contagem de solicitações
B1
198.50.121.146
iWeb Technologies Inc.
3.936.297
B1
202.134.19.50
Empresa de Infraestrutura de Telecomunicações CMC
3.077.579
B1
209.126.124.140
HEG US Inc.
2.908.415
P6
104.199.133.2
Google LLC
2.802.394
B1
185.191.236.162
Rack Sphere Hosting S.A.
2.751.354
B1
200.30.138.54
MILLICOM CABLE EL SALVADOR S.A. de C.V.
2.502.015
B1
103.74.121.88
Corporação para o Financiamento e a Promoção da Tecnologia
2.480.702
P4
91.227.40.198
Data Invest sp. z o.o. S.K.A.
1.198.752
B1
113.125.82.11
Cloud Computing Corporation
848.330
B1
37.211.21.205
Ooredoo Q.S.C.
831.118
B1
173.212.197.82
Contabo GmbH
662.370
B1
212.92.204.54
A1 Hrvatska d.o.o.
589.828
B1
193.41.88.58
Universidade Nacional Taras Shevchenko de Kiev
542.676
B1
109,70,189,70
JSC Elektrosvyaz
497.125
B1
186.121.235.66
AXS Bolívia S.A.
417.661
B1
93.180.220.67
Intertelecom Ltda.
417.072
B1
177.126.129.43
Net Aki Internet Ltda
399.074
B2
46.210.30.130
Cellcom Fixed Line Communication L.P.
291.192
P2
223.233.84.97
Bharti Airtel Ltd., Serviços de Telemídia
86.991
P7
23.247.35.2
Redes Globais de Frag
28.408
P9
209.17.114.78
Network Solutions, LLC
25.476
P10
209.17.114.78
Network Solutions, LLC
12.392
CONCLUSÃO
De 7 a 22 de outubro de 2023, sites israelenses e palestinos foram alvo de ataques cibernéticos coordenados e graves, com o objetivo de sobrecarregá-los e derrubá-los. Esse tipo de ataque, conhecido como ataque de Negação de Serviço Distribuída (DDoS), funciona como um engarrafamento que obstrui uma rodovia, impedindo que usuários comuns acessem o site.
Magnitude dos ataques: O site israelense de direitos humanos sofreu ataques que resultaram em 54 milhões de solicitações na web, enquanto o site de notícias palestino registrou 7 milhões de solicitações na web. Pense nisso como milhões de ligações indesejadas sobrecarregando uma linha direta.
Táticas e técnicas: Os invasores se adaptaram e utilizaram diversos métodos para contornar as defesas do Deflect. Alguns tentaram variar as solicitações de ataque de maneira sutil para enganar os conjuntos de regras manuais. Outros adotaram uma abordagem mais direta, enviando rapidamente um grande número de solicitações. Em alguns casos, os invasores tentaram disfarçar suas solicitações maliciosas, fazendo com que parecessem visitas normais de usuários.
Padrões de ataque em comum: Percebemos que muitos dos ataques a ambos os sites pareciam ter origem nas mesmas fontes ou grupos. É como identificar o mesmo grupo de desordeiros causando perturbações em vários lugares. Especificamente, os métodos e até mesmo alguns dos endereços de internet (IPs) utilizados nos ataques eram comuns aos dois sites.
Eficiência das defesas: Nossas medidas de proteção — pense nelas como guardas de segurança ou filtros — funcionaram bem na maioria dos casos. Elas conseguiram identificar e bloquear essas solicitações maliciosas, evitando interrupções significativas. No entanto, os invasores são persistentes e continuam tentando vários métodos para contornar nossas defesas.
Nos últimos tempos, nosso sistema de proteção, o Deflect, tem se mostrado um robusto guardião dos sites sob sua supervisão. Utilizando técnicas sofisticadas, que incluem o poder do aprendizado de máquina, ele tem diferenciado com precisão entre tráfego normal e malicioso. Isso não apenas garantiu que esses ciberataques fossem efetivamente frustrados, mas também manteve o serviço ininterrupto dos sites em questão. Isso é uma prova da capacidade do Deflect de lidar com ataques cibernéticos complexos e agressivos, salvaguardando a essência e o funcionamento ininterrupto das plataformas online e, assim, apoiando a liberdade de expressão na internet.
Este foi um mês movimentado para as ferramentas de mitigação do Deflect, com o Banjax bloqueando quase 12 milhões de solicitações maliciosas lançadas por 108.294 bots diferentes. Devido à guerra na Ucrânia, muitas pessoas recorreram aos sites de mídia ucranianos protegidos pelo Deflect em busca de informações. Ao longo do mês, a Deflect atendeu 1.128.751.920 solicitações (quase o dobro do mês anterior), das quais 283.570.50 vieram da Ucrânia — cerca de 20% do nosso tráfego global. 1.277.053 ucranianos acessaram sites protegidos pelo Deflect — o que também atesta a estabilidade da Internet naquele país.
Público ucraniano em março, por cidade
O maior ataque registrado neste mês foi contra o informator.ua — um site de notícias de abrangência nacional na Ucrânia, com foco na região de Donbas.
No dia 31 de março, entre 07h45 e 08h50 GMT+0 , cerca de 1.300 endereços IP únicos foram bloqueados pelo Deflect ao atacarem o site informator.ua com as solicitações GET /ru?8943563843054274 e POST /ru?829986440416200, utilizando técnicas de cache-busting. Esses bots eram originários do Brasil, dos EUA, da Indonésia, da Índia, de Bangladesh e de muitos outros países; cerca de 1.000 deles parecem ser roteadores MikroTik infectados. Várias centenas eram servidores web comprometidos e proxies SOCKS. Houve uma interrupção parcial neste site por cerca de uma hora, pois o Deflect não conseguiu mitigar esse ataque com rapidez suficiente para garantir que nenhuma solicitação maliciosa atingisse o servidor de origem. O sistema Baskerville não reagiu como esperado (isso já foi corrigido). Habilitamos o Challenger para este domínio a fim de garantir que possamos mitigar futuros ataques sem causar problemas para a origem. Nosso sistema de agregação e análise de logs foi afetado pelo volume total de solicitações e ficou fora de sincronia por um curto período de tempo.
Os invasores geraram mais de 300.000 solicitações por minuto. Como você pode ver, uma quantidade significativa de bots tinha origem nos Estados Unidos. Esse é mais um lembrete importante para que você aplique as atualizações de segurança em seus sistemas de computador e outros dispositivos conectados à Internet. Caso contrário, pode ser o seu próprio sistema que esteja atacando sites ucranianos também!
Principais IPs únicos bloqueados por fornecedor
912 MikroTikRouter
232 Desconhecido
51 UbuntuServer
44 Torrouter
33 DebianServer
16 WindowsServer
6 WindowsSystem
6 RedHatServer
4 CentOSLinuxServer
Principais IPs únicos bloqueados por serviço
875 MikroTik
232
49 Ubuntu-ssh
44 Cabeçalho HTTP do roteador de saída do Tor
33 Cabeçalho SSH do Debian
13 Informações SNMP do MikroTik
10 Servidor FTP do MikroTik
8 MikroTikPPTPserver
7 WindowsRDPServer
7 MSIISheader
6 WindowsNetBIOS
6 RedHatDNSheader
5 MikrotikRouterOSconfigurationpage
4 ApacheCentOS
2 WindowswithMSHTTPAPIWebServer
por client_url:
199940 /ru
102142 /ru/categoria/negócios/login
37312 /ru/negociações-entre-a-ucrania-e-a-rússia-em-istambul-resultados
3 /ru/post-anterior/45573
Mais uma vez, a rede Deflect cresceu em tamanho e público em 2021. Além do trabalho continuamente excelente de nossos clientes, o que mais se destacou para a equipe da Deflect encarregada do monitoramento da rede e da mitigação de ameaças foi a crescente sofisticação e “precisão” do Baskerville, que superou os conjuntos de regras criados por humanos para a biblioteca de limitação de taxa de solicitações do kit de ferramentas de mitigação Banjax. Sim, a máquina está superando os humanos na Deflect. Não vamos nos aprofundar na natureza filosófica dessa realidade, mas sim compartilhar com vocês algumas estatísticas e ataques interessantes que testemunhamos este ano.
O ano em números
Número de solicitações válidas atendidas
10.152.911.060
Número de leitores únicos (IP) válidos
77.011.728
Total de solicitações bloqueadas – Banjax
3.326.915
Total de solicitações contestadas pelo Baskerville
2.606.927
% dos clientes da Deflect que também utilizam a hospedagem eQpress
34 %
Tempo total de indisponibilidade total do Deflect
0
Menor tempo de atividade entre todos os clientes da Deflect
99,8%
Aumento na porcentagem de clientes em relação ao ano anterior
21,62%
Maior botnet, em número de bots
19.333
Número de eventos DDoS significativos
103
Ataques desviados
Como é um ataque
Em 4 de novembro de 2021, um ataque DDoS contra um meio de comunicação vietnamita (também hospedado na EQPress) teve início por volta das 16h50 UTC. Entre 2.000 e 2.500 endereços IP únicos foram bloqueados, originários dos Estados Unidos, Canadá, Alemanha, França e outros países. Esses bots enviaram cerca de 825 mil solicitações GET / e GET https://website.com// durante esse ataque. A maioria dos IPs envolvidos foi detectada como proxies, e muitos deles revelaram um IP no cabeçalho X-Forwarded-For. A instância do WordPress subjacente recebeu até 5.000 solicitações por segundo, forçando o servidor da EQPress a enviar até 30 megabits por segundo de respostas HTML. Graças ao cache do FasctCGI e ao reforço geral da configuração, o cluster da rede de hospedagem dispunha de recursos suficientes para atender às solicitações até que todos os bots fossem bloqueados, sem quaisquer problemas significativos para o próprio site ou para os sites vizinhos.
O Baskerville detectou esse ataque e enviou comandos de desafio para mais de 2.200 endereços IP.
Sistema de classificação de semáforos de Baskerville
Esse ataque teve como alvo um site independente de jornalismo investigativo das Filipinas. O ataque teve início em 15 de novembro e se estendeu pelas duas semanas seguintes. Grande parte do tráfego do ataque não foi detectada pelo Deflect, visando o data center de hospedagem com inundações de tráfego nas camadas L3/L4.
Quase 4.000 endereços IP únicos enviaram mais de 70 milhões de solicitações “GET /” e “GET /?&148294400498e131004165713TT117859756720Q106417752262N” contra o site, utilizando técnicas de `cache busting` com parâmetros aleatórios na string de consulta. Os invasores também recorreram ao uso de User-Agents falsificados nas cadeias de solicitação. Obviamente, esse ataque foi adaptado para contornar as defesas de cache do Deflect. Muitos dos endereços IP participantes eram proxies, possivelmente revelando o remetente original por meio do cabeçalho X-Forwarded-For.
Infelizmente, esse ataque não foi totalmente contido de forma rápida e causou várias horas de indisponibilidade para os usuários reais. Após ativar manualmente os mecanismos avançados de proteção do Deflect e ajustar a configuração da origem, o site voltou a funcionar normalmente.
Uma organização zambiana de defesa da democracia sofreu dois ataques entre os dias 8 e 9 e 11 e 12 de agosto. Parece que, quando os invasores voltaram pela segunda vez, não haviam aprendido a lição e tentaram uma técnica semelhante, utilizando uma botnet quase idêntica.
Servidores de diferentes países (principalmente Estados Unidos, Alemanha, Rússia e França) estavam enviando mais de 16 milhões de solicitações GET / e /s=87675957 (com números aleatórios para contornar o cache) durante a primeira onda de ataques. Durante o incidente seguinte, mais de 137 milhões de solicitações maliciosas foram registradas e bloqueadas.
A maioria desses endereços IP é conhecida como servidores comprometidos que poderiam ser usados como proxies e roteadores MikroTik. Foram utilizados 383 cabeçalhos User-Agent distintos, todos eles variações do Google Chrome. Também podemos observar cerca de 400 nós de saída da rede TOR que foram utilizados nesse ataque.
Milhões de acessos por minuto
O primeiro ataque não foi totalmente mitigado devido ao seu perfil, e parte do tráfego conseguiu atingir o servidor de origem, resultando em várias horas de indisponibilidade parcial para visitantes reais durante diferentes fases desse ataque. O segundo ataque foi totalmente mitigado, pois já tínhamos atualizado nossos perfis de mitigação.
O serviço Deflect foi desenvolvido com base nos princípios de defesa em profundidade para manter seu site online, independentemente do tráfego recebido. Nossos pontos de borda da rede estão localizados em data centers de vários provedores ao redor do mundo. Cada ponto de borda da rede Deflect armazena em cache recursos estáticos de páginas da web e é capaz de responder com grande rapidez a uma grande quantidade de solicitações simultâneas. À medida que o tráfego chega ao ponto de borda, dois módulos distintos estão sempre atentos a bots maliciosos e ataques. Um deles é o Baskerville — que utiliza previsões de anomalias baseadas em aprendizado de máquina. Temos uma página dedicada explicando como isso funciona. O outro é o Banjax — uma lista selecionada de padrões de expressões regulares com limites de taxa associados. Isso nos permite, por exemplo, bloquear instantaneamente endereços IP que enviam solicitações com user agents de uma lista de scanners de vulnerabilidades. Ou podemos bloquear endereços IP que solicitam um endpoint /search/ oneroso com muita frequência, ou que enviam uma quantidade excessiva de solicitações POST ou GET para a rede. É simples, mas muito eficiente.
O Banjax foi originalmente programado em C++ e criado como um plug-in do Apache Traffic Server (ATS). Essas escolhas iniciais dificultaram a adoção por terceiros (que não utilizavam o ATS). Ao refatorar o Banjax, decidimos usar Go — uma linguagem mais moderna que ainda oferecia todas as funcionalidades necessárias e facilitava a manutenção da biblioteca a longo prazo. Portanto, agora temos o prazer de apresentar o Banjax-Go, desenvolvido para a década de 2020 e funcionando perfeitamente em conjunto com os sistemas de cache Baskerville e Deflect ou como um módulo independente em sua configuração do nginx.
Portanto, as decisões que o Banjax pode tomar são: Permitir, Bloquear ou Solicitar confirmação. As listas de decisões são preenchidas a partir do arquivo de configuração (útil para criar listas de permissão ou bloqueio de IPs conhecidos como bons ou ruins), a partir dos resultados das regras de limitação de taxa por expressões regulares (portanto, violar uma regra pode resultar em um Bloqueio, um Desafio ou até mesmo uma Permissão), e a partir de mensagens recebidas em um tópico do Kafka (é assim que o Baskerville se comunica com o banjax-next).
Além de bloquear solicitações (no nível HTTP) ou bloquear endereços IP (no nível do iptables/netfilter), o Banjax também oferece suporte ao envio de uma página HTML de “desafio” que contém um desafio básico de senha (útil como uma linha extra de defesa nas seções de administração) ou um desafio de prova de trabalho (útil para bloquear bots que não conseguem executar JavaScript, ao mesmo tempo em que permite o acesso de navegadores da web).
Uma das principais preocupações ao abandonar o C++ era o desempenho — durante um ataque, o Banjax frequentemente precisa processar milhares de solicitações por segundo, em cada nó de borda. Realizamos uma série de testes sintéticos para avaliar o desempenho do Banjax-Go. Utilizamos uma série de cenários de pior caso, com base em nossas experiências anteriores com o Deflect. Nosso objetivo era processar 1.000 endereços IP únicos por segundo em uma máquina virtual comum (um droplet da Digital Ocean).
Primeiramente, testamos o iptables diretamente para verificar com que rapidez ele consegue processar solicitações diretas — excluindo 2.000 regras — sem a interferência de nenhum outro sistema. Chegamos aos seguintes resultados:
Em seguida, testamos a rapidez com que o Banjax-Go é capaz de processar diferentes tipos de solicitações comuns (novamente, nas condições do pior cenário possível):
Cada solicitação gera um desafio: 800 solicitações/segundo
Todas as solicitações são encaminhadas para o servidor de origem sem nenhum armazenamento em cache: 1.200 solicitações/segundo
Cada solicitação passa pelo sistema e recebe uma versão em cache de uma página da web: 2.800 solicitações/segundo
Ao mesmo tempo, decidimos atualizar nosso mecanismo de cache, passando do Apache Traffic Server para o Nginx. Esses e muitos outros módulos farão parte do nosso lançamento do Deflect-Core — um produto do projeto que esperamos apresentar até o final da primavera. Por enquanto, nossos esforços estão concentrados no kit de ferramentas de mitigação banjax-next.
Seja você o proprietário de um site de mídia independente que conta histórias que ninguém mais conta, uma organização sem fins lucrativos ou comunitária que informa seus membros sobre recursos e eventos disponíveis, ou uma empresa de qualquer porte, garantir que seu site permaneça protegido e online é de extrema importância.
Compreender a diferença entre vulnerabilidade indireta e direta
Muitos ataques indiretos à segurança cibernética — malware, phishing, trojans, violações de dados e ransomware — podem ser evitados por meio da conscientização dos funcionários de uma organização e da adoção de melhores práticas em relação a clicar em links suspeitos ou baixar arquivos de fontes não confiáveis.
No entanto, seu site também pode ser alvo de ataques DDoS diretos. É por isso que sua segurança deve ser gerenciada por uma equipe de suporte técnico dedicada em que você confie, que compartilhe seus valores de transparência, privacidade e responsabilidade social.
O que é um ataque DDoS?
Ao contrário dos ataques que dependem de que as pessoas cliquem em links suspeitos em seus e-mails ou baixem arquivos de sites não confiáveis, os ataques DDoS são ataques diretos à infraestrutura de TI de uma organização.
Um ataque DDoS (negação de serviço distribuída) é como a corrida aos supermercados no início da pandemia, quando os clientes se amontoavam e bloqueavam a porta na ânsia frenética por aquele último rolo de papel higiênico. Só que, quando todo esse tráfego atinge seu site, não se trata de clientes — são bots. E o principal objetivo deles é sobrecarregar seu site e tirá-lo do ar. Sem proteção, seu site pode ficar incapacitado por um ataque e ser desativado completamente.
Meu site não vai ser alvo de ataques porque somos muito pequenos
Um ataque DDoS pode acontecer com qualquer pessoa, independentemente do tamanho do seu site ou do número de visitantes. Na verdade, muitos sites pequenos, especialmente meios de comunicação independentes e organizações de base, são particularmente vulneráveis a ataques porque suas vozes muitas vezes se opõem a um governo poderoso, a forças armadas ou a um consenso popular. Em alguns casos, esses sites são alvo de grupos de ódio, como aconteceu quando protegemos o Black Lives Matter contra ataques que ocorreram mais de 100 vezes por dia em seu site durante sete meses em 2016.
Uma boa pergunta a se fazer: alguém gostaria de silenciar a sua voz? Se a resposta for sim, você provavelmente já sabe da importância da proteção contra ataques DDoS. Oferecemos o mesmo nível de proteção para organizações sem fins lucrativos e sites de mídia independentes que oferecemos aos clientes comerciais. Saiba mais sobre nossa proteção gratuita para grupos qualificados aqui.
Não há muitos ataques DDoS, então provavelmente não vou precisar de proteção
De acordo com um relatório técnico recente divulgado pela CISCO, os ataques DDoS vêm se tornando cada vez mais intensos e frequentes a cada ano. Em 2018, ocorreram 7,9 milhões de ataques DDoS e, até 2023, estima-se que esse número dobre para 15,4 milhões.
As empresas mais conhecidas não são melhores quando se trata de proteção contra ataques DDoS?
Não. A Deflect tem capacidade para garantir a proteção de qualquer site, e nossa experiência na mitigação de ataques a alguns dos sites mais vulneráveis em países de todo o mundo nos tornou especialistas na área.
Segundo Ali Reza, “a IPOS se beneficiou diretamente da experiência e do profissionalismo da Deflect quando nosso site principal foi alvo de um ataque sem precedentes. Na época, os serviços de empresas semelhantes, incluindo a CloudFlare e o Google PageSpeed, não conseguiram proteger a enquete de acompanhamento eleitoral da IPOS contra um grande ataque DDoS durante as eleições presidenciais de 2013 no Irã. No entanto, a Deflect conseguiu configurar rapidamente uma rede de distribuição de conteúdo (CDN) para receber o tráfego do domínio principal da IPOS e repelir o ataque.”
Meu setor não será alvo de ataques. São os bancos e os governos que, na maioria das vezes, são alvo de ataques DDoS
Embora bancos e governos tenham de fato sido alvo de ataques DDoS, nenhum setor está imune a esses ataques. De acordo com o relatório “ Global DDoS Threat Landscape” de 2019, elaborado pela Imperva, ocorreram ataques na maioria dos setores, incluindo entretenimento adulto, jogos, notícias, sociedade, estilo de vida, varejo, viagens e jogos de azar. Se o seu site não estiver nesses setores, isso não significa que você esteja a salvo de um ataque DDoS.
Motivos para ataques DDoS
Conforme destaca o mesmo relatório, as motivações para os ataques DDoS são diversas e podem incluir:
Concorrência comercial — um concorrente pode contratar uma botnet para derrubar seu site.
Extorsão — os sites de comércio eletrônico dependem especialmente do tempo de atividade de seus sites para gerar receita. Isso os torna particularmente suscetíveis à extorsão, sob a promessa de que não atacarão o site.
Hacktivismo — sites políticos, de mídia ou corporativos podem ser alvo de hacktivistas como forma de protesto contra suas ações.
Vandalismo — usuários insatisfeitos ou infratores aleatórios costumam atacar serviços de jogos ou outros clientes de grande visibilidade.
A essa lista, gostaríamos de acrescentar:
Censura — esses ataques podem ser cometidos por indivíduos, governos ou forças armadas contra grupos por causa de seus movimentos sociais, ambientais, de direitos humanos ou políticos, com o objetivo de silenciar suas vozes. Como você pode imaginar, fora da América do Norte, alguns dos ataques mais frequentes contra os povos e grupos mais vulneráveis, como nosso cliente ARNO, em Mianmar, são desse tipo.
Proteção transparente, confiável e ética
Mas eu já estou protegido por um dos caras mais populares, e “de graça”.
Grandes provedores costumam alegar que oferecem proteção contra ataques DDoS “gratuitamente”. Para prestar esse serviço, no entanto, muitos firmam acordos com investidores de capital de risco, e a contrapartida por essa proteção “gratuita” é a privacidade dos seus dados, que podem ser compartilhados ou vendidos.
Antes do escândalo da Cambridge Analytica, muitos de nós costumávamos rolar a tela sem pensar e concordar com todos os termos e condições, mas, para a mídia independente, organizações sem fins lucrativos e comunitárias, bem como empresas, os dados devem sempre ser mantidos em segurança e privacidade. Ao escolher quem irá protegê-lo contra ataques DDoS, leia as políticas com atenção para descobrir se você está abrindo mão de algo em troca de proteção “gratuita”. Nossa proteção para organizações sem fins lucrativos, ONGs e mídia independente é realmente gratuita.
Preços de desvio
Na Deflect, sempre oferecemos nossos serviços gratuitamente a organizações sem fins lucrativos e grupos de mídia independentes que se enquadram nos critérios, sem comprometer a privacidade dos seus dados. Nossos princípios, política de privacidade e condições são transparentes. Para sites comerciais, nossa estrutura de preços é transparente. Ao contrário da maioria dos nossos concorrentes, cobramos com base no número de IPs únicos mensais que acessam seu site, e não por visitas múltiplas a partir de um mesmo IP ou pelo tráfego proveniente de ataques.
Existem outras restrições à proteção “gratuita” oferecida por alguns de nossos concorrentes. Em mais de uma ocasião, clientes que estavam protegidos por nossos concorrentes nos procuraram após sofrerem um ataque e foram informados de que precisavam fazer o upgrade para um serviço premium ou cancelar a assinatura, justamente no momento em que estavam mais vulneráveis.
Nós, da Deflect, nos consideramos a empresa número 1 do mundo em proteção ética de segurança cibernética. Temos mais de 10 anos de experiência protegendo as vozes mais vulneráveis e mais atacadas da mídia independente e sem fins lucrativos em todo o mundo, em mais de 80 países.
Além do nosso compromisso com políticas transparentes e com a privacidade, temos uma política clara contra o ódio e o incitamento à violência. Para nós, isso é óbvio. Se o seu site violar essa política, você será convidado a sair.
Somos socialmente responsáveis. Para cada cliente comercial pagante que protegemos, podemos estender as mesmas proteções gratuitamente a grupos importantes que, de outra forma, não teriam condições de arcar com os custos da proteção ou que poderiam ser excluídos da proteção “gratuita” oferecida por nossos concorrentes, pois o trabalho que realizam os torna mais vulneráveis a ataques.
Caso tenha mais dúvidas ou queira obter mais informações sobre os programas da Deflect para organizações sem fins lucrativos, empresas ou parceiros, entre em contato conosco enviando uma mensagem aqui ou escrevendo para terry@deflect.network para questões relacionadas a organizações sem fins lucrativos e para garfield@deflect.network para programas voltados a empresas e parceiros.
– Ataques que não sejam DDoS
Qualquer vetor que não exija um grande fluxo de tráfego poderia ser
roteado de forma eficaz pelo Tor. Isso abrange a maioria dos ataques, com a
exceção notável dos ataques DDoS. Se eu estivesse tentando realizar um ataque de verdade, e não
apenas um DoS, para desviar a atenção — eu usaria o Tor.
– Funções de C&C
Provavelmente não observaríamos isso, mas nem é preciso dizer que o Tor
pode ser usado para se comunicar com o C&C de uma botnet. É isso que eu
faria.
– Monitoramento da disponibilidade do site e outras funções relacionadas a DDoS
Antes e durante um ataque, deve ser interessante monitorar a
disponibilidade do site alvo. O Tor poderia ser útil aqui… talvez eu
o usasse para monitorar o site atacado.
– Navegação regular por usuários do Tor
Em qualquer tentativa de monitorar o tráfego do Tor para nos alertar sobre um
ataque iminente, é preciso ter cuidado para filtrar o tráfego normal tanto quanto
possível. Algoritmos de aprendizado de máquina (ML) ou de significância provavelmente seriam os mais adequados
para essa tarefa. O Sniffles também pode fornecer informações: um aumento no tráfego do Tor
para portas diferentes de 80/443 pode ser suficiente sem a necessidade de
cálculos adicionais.
– Ações para uma pesquisa mais detalhada:
o Instalar a licença do Elastic Graph, que chegou hoje, para facilitar
a análise de significância o Colocar o Sniffles em operação e ver o que podemos observar
(após um ataque subsequente, ou seja, monitorado) o Aplicar análise de significância
ou outra análise aos padrões de tráfego do Tor nas proximidades e fora delas
de um ataque
ESTUDO DE CASO: BLM
A primeira imagem mostra, na parte superior, os bloqueios do Banjax para blacklivesmatter.com e,
na parte inferior, o tráfego via Tor para blacklivesmatter.com, ambos nas
últimas 8 semanas.
Mais uma vez, a segunda imagem mostra os bloqueios do Banjax para blacklivesmatter.com na
parte superior e o tráfego via Tor para blacklivesmatter.com na parte inferior, mas
com zoom em um período de aproximadamente 1 semana antes e 1 semana depois do
grande pico nos bloqueios.
Algumas observações:
– Parece haver um aumento acentuado no tráfego do Tor próximo ao
incidente
– O tráfego via Tor continua por muito tempo depois que o ataque parece ter
terminado: talvez estejamos diante de uma coincidência, ou talvez outro
ataque esteja sendo planejado/preparado, ou talvez ambos.
– O número de IPs banidos é duas ordens de magnitude maior do que o
número de acessos via Tor (note que IPs únicos são uma métrica mais ou menos inútil
para o tráfego via Tor, e também que o total de acessos *provenientes* dos
IPs banidos acima será bem maior do que o número de IPs banidos
)
– O número de IPs bloqueados é, de fato, muito maior do que o número de
nós de saída do Tor.
Advertências:
– O BLM não está conosco há muito tempo
– Apenas um site foi analisado aqui, de forma superficial
– Estamos analisando o tráfego para as portas 80/443, que não é filtrado por
nossos provedores
CASO RÁPIDO 2: www.btselem.org
Um pequeno aumento nos bloqueios, correspondendo a um grande pico no tráfego
via Tor. Em seguida, um grande aumento nos bloqueios, sem aumento correspondente
no tráfego via Tor. O ataque parece ter diminuído ou ter sido
bloqueado com sucesso; então, ocorre outro ataque menor — desta vez
com um aumento simultâneo no tráfego via Tor. É difícil tirar
conclusões, mas não é inconsistente com a teoria de que uma correlação
possa existir. Uma lição clara deste exemplo, SE uma correlação for
comprovada ou presumida, é que o tempo entre um pico de sondagens via Tor e
um DDoS efetivo irá variar.
GRÁFICOS AGREGADOS INÚTEIS:
Sem a separação por host HTTP (ou qualquer outro critério), os dados se transformam
em ruído inútil.
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.
Capítulo 2 – Contexto
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:
Seja rápido o suficiente para que valha a pena
Ser capaz de se adaptar às mudanças nos padrões de tráfego
Fornecer informações úteis (uma previsão e uma pontuação para cada endereço IP)
Fornecer previsões confiáveis (período de experiência e feedback)
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.
Capítulo 3 – Baskerville descobre
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.
Rotulagem
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.
Um exemplo do resultado do procedimento de rotulagem
Métricas de desempenho
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.
O desempenho de dois modelos diferentes diante de dois ataques distintos
Características categóricas
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.
Amostragem estratificada
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.
Armazenamento
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.
Arquitetura
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.
A Deflect responde à emergência da COVID-19 com serviços gratuitos
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:
Disponibilidade: à medida que a demanda por seu conteúdo cresce, nossa infraestrutura global garantirá que seu site permaneça acessível e rápido
Segurança: proteção do seu site contra bots maliciosos e hackers
Hospedagem: para sites WordPress existentes ou novos
Análises: visualize estatísticas em tempo real no painel do Deflect
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.
Descobrimos uma infraestrutura utilizada para lançar e coordenar ataques contra a mídia independente e ativistas de direitos humanos do Uzbequistão
A campanha está em andamento desde o início de 2016, utilizando ataques na web e de phishing para coibir e explorar seus alvos
Não temos indícios de quem esteja por trás dessa campanha, mas a lista de alvos aponta para um novo agente de ameaças que tem como alvo ativistas e a mídia do Uzbequistão
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.
Contexto: Direitos Humanos e Vigilância no Uzbequistão
Emblema do Uzbequistão (Wikipedia)
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.
Uma nova campanha de phishing e ataques à web
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:
O Fergana News é um importante site independente de notícias em russo e uzbeque que cobre os países da Ásia Central
Eltuz é um meio de comunicação online independente do Uzbequistão
A Centre1 é uma organização de mídia independente que cobre notícias da Ásia Central
A Palestine Chronicle é uma organização sem fins lucrativos que atua na área de direitos humanos na Palestina
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.
Um ano de ataques cibernéticos contra a sociedade civil
Por meio do DNS passivo, identificamos três endereços IP utilizados pelos invasores nesta operação:
O endereço 46.45.137.74 foi utilizado em 2016 e 2017 (o período exato não está claro; Centro de Dados de Istambul, AS197328)
O endereço 139.60.163.29 foi utilizado entre outubro de 2017 e agosto de 2018 (HostKey, AS395839)
O endereço 51.15.94.245 foi utilizado entre setembro de 2018 e fevereiro de 2019 (Scaleway, AS12876)
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
Uma grande campanha de phishing
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
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.
Cronograma da campanha
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.
Análise de infraestrutura
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:
O endereço 46.45.137.74 foi utilizado em 2016 e 2017
O endereço 139.60.163.29 foi utilizado entre outubro de 2017 e agosto de 2018
O endereço 51.15.94.245 foi utilizado entre setembro e fevereiro de 2019
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:
O site pochta[.]top provavelmente se faz passar pelo site https://www.pochta.ru/, do Correio Russo
Não encontramos nenhuma informação sobre vzlom[.]top e fixerman[.]top. “Vzlom” significa “invadir” em russo; portanto, o site poderia ter hospedado ou se passado por um site de segurança.
Um estranho nexo da criminalidade cibernética
É 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áriosoutros 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.
Desativar servidores é difícil
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.
Conclusão
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 OceanLotus, 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.
Contramedidas contra esses ataques
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 outrosrelató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.
Apêndice
Agradecimentos
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.
Utilização de Aprendizado de Máquina para Identificar Ataques Cibernéticos
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.
Como isso funciona?
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.
Treinamento de um modelo
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.
Reprodução dos ataques
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).
Colocando o Baskerville em ação
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.
E agora?
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.
Consideração final: viés na IA
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.
