Mais de 300 relés de saída da rede Tor foram sequestrados por invasores no início de outubro e usados para redirecionar conexões SSH a servidores que roubavam senhas, segundo um pesquisador.
Os relés de saída são a última etapa de um circuito Tor, por onde o tráfego deixa a rede em direção ao destino. As senhas só poderiam ter sido capturadas se o usuário tivesse se conectado a servidores SSH pelo Tor entre 1º e 5 de outubro e aceitado a chave do servidor de interceptação.
O Tor Project começou a sinalizar os relés em 4 de outubro. No dia seguinte, nenhum deles permanecia no consenso, a lista de relés usada pelos clientes Tor. No pico da operação, em 4 de outubro, os relés com a política de saída dos invasores respondiam por 7,46% da capacidade de saída do Tor, medida pelo peso no consenso. A estimativa consta de uma análise de dados públicos dos diretórios do Tor, publicada na lista de discussão tor-relays.
O pesquisador, que publica sob o nome kaba, examinou cerca de 3.000 relés de saída do Tor em 2 de outubro e identificou 333 que redirecionavam conexões SSH para os mesmos 12 servidores de interceptação. Já a análise dos dados de diretório contabilizou 377 relés operados por 59 responsáveis que adotaram a política de saída dos invasores entre 1º e 4 de outubro. O documento ressalta que isso indica “uma correspondência de política, não uma prova de comprometimento”.
Como os relés sequestrados interceptaram conexões SSH
Um relé de saída só encaminha tráfego para as portas permitidas por sua política de saída. Os invasores alteraram essa política nos arquivos de configuração torrc dos relés para liberar a porta 22, usada pelo SSH. Com isso, habilitaram o protocolo em 342 relés que antes o bloqueavam. Outros 24 relés, que nem sequer atuavam como relés de saída, passaram a fazê-lo.
“Parece que o invasor está obtendo acesso a máquinas baseadas em Linux e, quando elas não estão atuando como relés de saída, altera o arquivo torrc para transformá-las em relés de saída e viabilizar o ataque ao SSH”, escreveu a equipe de integridade da rede do Tor Project em um aviso a operadores de relés, em 5 de outubro. Os dados de diretório indicam que a maioria dos relés afetados já atuava como relé de saída.
A mesma alteração fechou as portas de e-mail criptografado IMAPS e POP3S e, na maioria dos relés, abriu as portas que permitem tráfego sem criptografia, POP3 e IMAP.
Um cliente Tor só escolhe um relé de saída que permita a porta de destino. Assim, esses relés deixaram de transportar e-mail criptografado e passaram a encaminhar conexões SSH, Telnet e, na maioria dos casos, tráfego de e-mail sem criptografia. A análise afirma que os dados disponíveis não revelam por que as portas de e-mail criptografado foram fechadas.
Com a porta 22 liberada, uma conexão SSH que passasse por um desses relés era encaminhada a um dos 12 servidores de interceptação, em vez de chegar ao destino, descobriu kaba. O servidor de interceptação apresentava sua própria chave de host. Quem já conhecia a chave verdadeira do servidor recebia do OpenSSH um aviso de que a identificação do host remoto havia mudado. Quem se conectava pela primeira vez via a solicitação habitual para aceitar uma nova chave.
Na varredura de 2 de outubro, cerca de uma dúzia de relés apresentava uma chave de host falsa. Os outros 300 ou mais redirecionavam as conexões pelos mesmos servidores, sem alterar a chave.
Quem aceitasse a chave e digitasse uma senha a entregava ao servidor de interceptação. Como ele se conectava ao servidor verdadeiro, a sessão continuava funcionando. Os invasores podiam acompanhar todos os comandos e, usando a senha roubada, iniciar uma sessão separada para verificar a disponibilidade do sudo e executar um instalador em Perl codificado em base64. No honeypot de kaba, o instalador tinha o mesmo formato do comando usado para instalar o Ebury, um backdoor que se esconde no OpenSSH, em um dos servidores de um operador de relé, conforme descrito adiante.
Uma conexão SSH autenticada por chave não poderia ser retransmitida dessa maneira. No protocolo de autenticação SSH, a assinatura do cliente inclui um identificador exclusivo para cada sessão. Portanto, uma assinatura criada para a sessão com o servidor de interceptação não funciona contra o servidor verdadeiro. O servidor de interceptação ainda poderia aceitar uma autenticação por chave e exibir um terminal falso, mas não conseguiria usá-la para acessar o servidor real.
Uma senha, por outro lado, é enviada dentro da sessão criptografada e pode ser lida pelo servidor na outra ponta. Nesse caso, a outra ponta era o servidor de interceptação.
Quem pode ter sido afetado e o que fazer
Para ser afetado, era necessário conectar-se a um servidor SSH pelo Tor entre 1º de outubro e a tarde de 5 de outubro, passar por um dos relés sequestrados, ter a conexão interceptada em vez de encaminhada ao destino, aceitar a chave de host do servidor de interceptação e entrar com uma senha. Não há uma estimativa do número de vítimas.
Se você aceitou uma chave de host desconhecida ou alterada ao usar o Tor nesse período, considere roubada a senha digitada, troque-a e verifique se há sinais do Ebury no servidor, listados adiante. Um cliente OpenSSH que aceita uma chave a salva no arquivo known_hosts.
O servidor que interceptou a conexão de kaba usava uma chave ED25519 com a impressão digital SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E. Os outros servidores de interceptação podem ter usado chaves diferentes.
Como o ataque foi descoberto e interrompido
Kaba encontrou o ataque na manhã de 2 de outubro, quando uma conexão SSH pelo Tor exibiu um aviso de alteração da chave. Em seguida, usou o exitmap, uma ferramenta de varredura também utilizada pela equipe de integridade da rede do Tor Project, para iniciar uma conexão SSH entre dois de seus servidores, passando por cada relé de saída, um de cada vez.
Uma das pontas verificava se a chave de host estava correta; a outra, se a conexão vinha do relé ou de um servidor de interceptação. Kaba enviou os resultados à equipe de integridade naquela noite.
A equipe também detectou a mudança de política por meio de seu próprio monitoramento. Em 4 de outubro, entrou em contato com Zimmer, responsável pela família de relés Quetzalcoatl, o maior grupo afetado. Zimmer confirmou que não havia feito a alteração, pediu que os relés fossem marcados como maliciosos e interrompeu o Tor no servidor que os hospedava.
As autoridades de diretório começaram a votar pela aplicação das sinalizações BadExit e MiddleOnly aos relés afetados às 18h UTC daquele dia. Às 21h, as sinalizações já constavam do consenso. A sinalização BadExit instrui os clientes Tor a nunca usar um relé como saída.
Na manhã de 5 de outubro, uma reinicialização automatizada atingiu 55 servidores da Quetzalcoatl, ainda com a política alterada. Não se sabe quem a iniciou. Segundo o aviso do Tor Project, as autoridades de diretório já estavam rejeitando os relés afetados da rede. Zimmer escreveu que os dois relés que havia interrompido também foram recusados quando tentaram voltar.
Às 17h UTC de 5 de outubro, nenhum relé com a política dos invasores constava do consenso. A análise dos dados de diretório não encontrou nenhum de volta até 9 de outubro. Naquele momento, 41 relés, nove deles da Quetzalcoatl, ainda publicavam a política, mas não apareciam na lista da rede.
A contagem de relés com a sinalização “Exit” no Tor Metrics caiu cerca de 370 entre 3 e 5 de outubro, em linha com o número de relés afetados. Até 18 de outubro, o total ainda não havia se recuperado.
Ebury e como os invasores conseguiram acesso
Zimmer relatou o que ocorreu em seus servidores em uma análise posterior, publicada na lista de discussão em 7 de outubro. Dois deles executavam o Ebury versão 1.8.3: um servidor de gerenciamento da Contabo, que funcionava como porta de entrada da VPN da família e servidor intermediário SSH, e um servidor virtual privado da FranTech chamado Switzerland2, que hospedava dois relés de saída.
O Ebury é um backdoor e ladrão de credenciais voltado ao OpenSSH, ativo desde 2009, segundo a ESET. Em 2024, a empresa estimou que o malware havia infectado 400.000 servidores, dos quais mais de 100.000 continuavam infectados no fim de 2023.
Em 28 de agosto, o invasor acessou o servidor de gerenciamento na primeira tentativa, usando a senha da conta do operador. Em menos de cinco minutos, obteve acesso de administrador, instalou o Ebury e, pouco mais de uma hora depois, chegou ao Switzerland2 e instalou o malware também nesse servidor.
“A causa principal foi nossa: a mesma senha era usada para o acesso SSH, o sudo e a frase secreta do backup, estava armazenada em texto sem criptografia nos dois servidores e a autenticação SSH por senha continuava habilitada no servidor de gerenciamento exposto à internet”, escreveu Zimmer. Não se sabe como o invasor obteve a senha.
Os acessos feitos pelo backdoor do Ebury não deixam registros. Em 2 de outubro, os arquivos de configuração dos relés foram alterados sem que houvesse registros de acesso, comandos sudo ou tarefas agendadas. Os dois relés publicaram a política dos invasores às 9h34 UTC. Ela permaneceu ativa por cerca de 52 horas em dois relés que movimentavam aproximadamente 3,4 TiB por dia.
Uma reinicialização de rotina em 4 de outubro encerrou as ferramentas ocultas do invasor, mas o Ebury voltou imediatamente.
As “chaves mestras offline” da família, escreveu Zimmer, “não estavam offline: havia cópias no backup da estação de trabalho armazenado no servidor de gerenciamento, criptografadas com a senha que o invasor já tinha”. Ele retirou de operação todos os relés e a ponte da família e apagou os dois servidores.
Nesse caso, o Ebury consistia em um único arquivo de biblioteca com setuid, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, para o qual apontava o link simbólico libkeyutils.so.1. A biblioteca distribuída oficialmente não havia sido modificada. Por isso, dpkg -V e debsums não a detectavam, e o sshd, o sudo e o PAM passavam pelas verificações de seus pacotes. A versão 1.8.3 é mais recente do que os indicadores públicos da ESET, que chegam até a versão 1.8.2. O programa de detecção publicado pela empresa, consultado em 21 de outubro, não lista um nome de soquete para essa versão.
Marc-Etienne M. Léveillé, coautor do relatório da ESET sobre o Ebury publicado em 2014 e autor do relatório de 2024, deixou a empresa desde então. Léveillé afirmou que a versão 1.8.3 existe pelo menos desde junho de 2026 e publicou uma versão atualizada do programa de detecção que a identifica. “Dado o número de servidores infectados pelo Ebury entre 2009 e 2023, 400.000, é muito provável que existam outros relés Tor comprometidos”, escreveu.
A principal questão ainda em aberto é como os invasores conseguiram acesso às máquinas dos outros 58 operadores. Entre os relés listados em 1º de outubro, 71 dos 101 hospedados na FranTech Solutions, rede por trás da marca de hospedagem BuyVM, adotaram a política dos invasores. Em outros provedores, isso ocorreu com 13 de 9.054 relés, segundo a análise dos dados de diretório.
Quarenta relés de 21 operadores mudaram de política em um intervalo de cinco minutos e meio em 1º de outubro. A maioria das alterações ocorreu após uma recarga de configuração. Para os autores da análise, isso sugere que um único invasor já tinha acesso às 40 máquinas.
A principal hipótese de Léveillé é que a senha tenha sido capturada em um acesso feito a partir de uma máquina já infectada pelo Ebury. Outra possibilidade é o comprometimento de um provedor de hospedagem. Segundo ele, a ESET já encontrou provedores cujos servidores de gerenciamento estavam infectados pelo Ebury e cujos clientes acabaram com máquinas virtuais contaminadas.
Kaba contabilizou 26 dos 27 servidores comprometidos fora da família Quetzalcoatl na FranTech/BuyVM e perguntou na lista de discussão: “Será que eles comprometeram esses servidores no nível do provedor de hospedagem?”
O comprometimento da própria Quetzalcoatl passou pelo servidor de gerenciamento da Contabo. Já 225 dos 273 relés afetados da família estavam em outras redes.
Não se sabe quem está por trás da campanha nem quantas das máquinas afetadas executavam o Ebury. Zimmer examinou dois de seus servidores, enquanto os dados de diretório mostram apenas a política adotada. Outros operadores relataram ao Tor Project sinais como um processo falso com o nome em letras maiúsculas CRON e regras NAT que redirecionavam a porta 22. Os servidores de Zimmer não apresentavam nenhum desses sinais, e ainda não está claro se os casos estão ligados ao mesmo invasor.
Nos relés de Zimmer, as mudanças nas portas significavam que qualquer consulta de e-mail só poderia ocorrer sem criptografia, segundo ele. Durante a maior parte do período, um processo oculto chamado snf também estava ativo no Switzerland2. Não se sabe o que ele fazia.
O que os operadores de relés devem verificar
O aviso do Tor Project recomenda que operadores de relés Linux consultem o Relay Search para identificar sinalizações “Exit” ou políticas de saída que não tenham configurado. Também orienta a verificar o torrc e todos os arquivos incluídos em busca de alterações nas linhas ExitRelay, ExitPolicy, ContactInfo, MyFamily ou Nickname.
O aviso também recomenda procurar regras NAT na porta 22, processos em escuta ou conexões de saída desconhecidos, novas contas de usuário, entradas em authorized_keys, tarefas agendadas, unidades do systemd e um executável do Tor que não passe pela verificação do pacote. Os servidores de Zimmer não apresentavam nenhum dos sinais no nível do sistema listados, apenas a política de saída alterada. Portanto, uma verificação aparentemente limpa da máquina não descarta a presença desse Ebury.
Os sinais do implante, segundo a publicação de Zimmer, são:
- Arquivo: /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, com setuid e sem vínculo com qualquer pacote. Nos servidores de Zimmer, tinha 63.368 bytes e um hash diferente em cada máquina.
- Link simbólico: libkeyutils.so.1 apontando para esse arquivo.
- Soquete: soquete UNIX abstrato @event-0YsOG9WSOE.
- Processo: um falso /sbin/rsyslogd ou, em versões anteriores, systemd-udevd ou arpd, executado dentro do grupo de controle cgroup do ssh.service.
- Endereço IP: 185.225.226[.]62, origem do acesso de 28 de agosto.
- Chave SSH: RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, usada para acessar o Switzerland2.
- Chaves SSH incorporadas ao implante: RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo e ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y.
- Chave de host do servidor de interceptação: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, encontrada na conexão de kaba.
Se possível, faça a verificação a partir de um sistema de recuperação ou de uma imagem de disco desconectada. Em um servidor em funcionamento, entre usando uma chave. “Nunca digite uma senha em um servidor que você suspeita estar comprometido, porque o Ebury vai capturá-la”, escreveu Zimmer.
Para contornar o rootkit em modo de usuário antes de executar o programa atualizado de Léveillé ou os comandos da publicação de Zimmer, inicie um terminal com:
`H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash`
Se encontrar o malware, o Tor Project recomenda:
- tirar o relé de operação;
- preservar o disco e os registros antes de apagar os dados;
- reinstalar o sistema em vez de tentar limpar a máquina;
- gerar uma nova identidade de relé e considerar roubadas as chaves antigas;
- trocar todas as credenciais armazenadas no servidor.
A reinstalação é importante porque o implante sobreviveu a uma reinicialização no servidor de Zimmer. Georg Koppen, do Tor Project, recomendou relatar o caso pelo endereço [email protected]. Se o endereço IP tiver sido bloqueado durante o incidente, o operador deve escrever para o mesmo endereço depois de limpar a máquina para solicitar a remoção do bloqueio.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...