Atacantes assumiram o controle de mais de 300 relays de saída do Tor no início de outubro e os usaram para redirecionar conexões SSH (Secure Shell, protocolo de acesso remoto seguro) para servidores que roubavam senhas de login, descobriu um pesquisador.
Relays de saída são o último salto em um circuito do Tor, onde o tráfego deixa a rede rumo ao seu destino. Somente um login por senha em um servidor SSH feito via Tor entre 1º e 5 de outubro, após aceitar a chave de host do servidor de interceptação, pode ter sido capturado.
O Projeto Tor começou a sinalizar relays em 4 de outubro e, em 5 de outubro, nenhum permanecia no consenso — a lista de relays que os clientes Tor utilizam. No pico, em 4 de outubro, os relays que carregavam a política de saída do atacante representavam 7,46% da capacidade de saída do Tor, medida pelo peso no consenso, segundo uma análise dos dados públicos do diretório do Tor publicada na lista de discussão tor-relays.
O pesquisador, que assina como kaba, escaneou todos os cerca de 3.000 relays de saída do Tor em 2 de outubro e encontrou 333 redirecionando SSH para os mesmos 12 servidores de interceptação. A análise dos dados do diretório contabiliza 377 relays operados por 59 operadores que mudaram para a política de saída do atacante entre 1º e 4 de outubro — o que ela classifica como "compatibilidade de política, não prova de comprometimento".
Como os relays sequestrados interceptaram conexões SSH
Um relay de saída só encaminha tráfego para as portas que sua política de saída permite. Os atacantes reescreveram essa política nos arquivos de configuração torrc dos relays para permitir a porta 22 (a porta do SSH), habilitando SSH em 342 relays que a bloqueavam. Outros 24 relays, que não eram relays de saída, tornaram-se relays de saída.
"Parece que o atacante está obtendo acesso a hosts Linux e, quando essas máquinas operam como não-saídas, ele edita o arquivo torrc e as transforma em saídas para conseguir conduzir o ataque via SSH", escreveu a equipe de saúde da rede do Projeto Tor em seu aviso de 5 de outubro aos operadores de relays. A maioria dos relays afetados já era relay de saída, mostram os dados do diretório.
A mesma alteração fechou as portas de e-mail criptografado, IMAPS (Internet Message Access Protocol Secure) e POP3S (Post Office Protocol 3 Secure), e na maioria dos relays abriu as portas compatíveis com texto puro, POP3 (Post Office Protocol 3) e IMAP (Internet Message Access Protocol).
Um cliente Tor só escolhe uma saída que permita a porta de destino, então esses relays pararam de transportar e-mail criptografado e passaram a transportar SSH, Telnet e, na maioria deles, e-mail em texto puro. O motivo de as portas de e-mail criptografado terem sido fechadas não é visível nos dados, segundo a análise.
Com a porta 22 aberta, uma conexão SSH por meio de uma dessas saídas ia para um dos 12 servidores de interceptação em vez de seu destino, descobriu kaba. Quando um servidor interceptava a conexão, ele apresentava sua própria chave de host. Um usuário que já conhecia a chave do servidor real viu o aviso do OpenSSH (implementação aberta do protocolo SSH) de que a identificação do host remoto havia mudado, e um usuário que se conectava pela primeira vez viu o prompt usual para aceitar uma nova chave.
No escaneamento de 2 de outubro, cerca de uma dúzia de relays de saída servia uma chave de host falsa, e os outros 300 ou mais redirecionavam pelos mesmos servidores sem alterar a chave.
Um usuário que aceitasse a chave e digitasse uma senha a entregaria ao interceptador. O interceptador se conectava ao servidor real, de modo que a sessão funcionava, e cada comando podia ser observado e registrado separadamente, junto com a senha roubada, para verificar acesso a sudo e executar um instalador em Perl codificado em base64. No honeypot (ambiente preparado para atrair e estudar atacantes) de kaba, o instalador tinha a mesma forma do comando que instalou o Ebury — um backdoor (acesso oculto) que se esconde dentro do OpenSSH — em um dos servidores de um operador de relay, como descrito abaixo.
Um login SSH baseado em chave não pode ser retransmitido dessa forma. Pelo protocolo de autenticação do SSH, a assinatura do cliente inclui um identificador único para cada sessão, de modo que uma assinatura feita para a sessão do interceptador é inútil contra o servidor real. O interceptador ainda poderia aceitar um login por chave e mostrar um shell (interpretador de comandos) falso, mas não conseguiria alcançar o servidor real com ele.
Uma senha, por outro lado, viaja dentro da sessão criptografada e pode ser lida pelo servidor na outra ponta, que aqui era o interceptador.
Quem foi exposto e o que fazer se você foi
Para ser exposto, alguém precisava ter se conectado a um servidor SSH via Tor entre 1º de outubro e a tarde de 5 de outubro, ter caído em uma das saídas sequestradas, ter a conexão interceptada em vez de repassada, aceitar a chave de host do interceptador e fazer login com senha. Não há contagem de vítimas.
Se você aceitou uma chave de host desconhecida ou alterada via Tor nessa janela, trate a senha que digitou como roubada, troque-a e verifique no servidor a presença dos sinais de Ebury listados abaixo. Um cliente OpenSSH que aceitou a chave a salvou em known_hosts.
O servidor que interceptou a conexão de kaba utilizou uma chave ED25519 com a impressão digital SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, embora os demais servidores de interceptação possam 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 via Tor retornou um aviso de chave alterada. Ele então usou o exitmap, ferramenta de escaneamento que a própria equipe de saúde da rede do Projeto Tor também utiliza, para abrir uma conexão SSH de um de seus servidores para outro por meio de cada relay de saída, um a um.
Uma ponta verificava se a chave de host estava correta, e a outra se a conexão se originava na saída ou em um servidor de interceptação. Ele reportou os resultados à equipe de saúde da rede naquela noite.
A equipe de saúde da rede também percebeu a mudança de política por meio de seu próprio monitoramento. Em 4 de outubro, ela contatou Zimmer, que operava a família de relays Quetzalcoatl — o maior grupo de relays afetados — e Zimmer confirmou que a mudança não era dele, pediu que os relays fossem marcados como ruins e interrompeu o Tor no servidor que os executava.
As autoridades de diretório começaram a votar os sinalizadores BadExit e MiddleOnly nos relays afetados às 18:00 UTC (Tempo Universal Coordenado) daquele dia, e os sinalizadores estavam no consenso às 21:00. BadExit informa aos clientes Tor que nunca usem um relay como saída.
Na manhã de 5 de outubro, uma reinicialização automatizada percorreu 55 dos hosts do Quetzalcoatl, com a política ainda em vigor. Quem a executou é desconhecido. As autoridades de diretório já estavam rejeitando relays afetados da rede, disse o Projeto Tor em seu aviso, e os dois relays que Zimmer havia interrompido foram recusados ao tentar se reconectar, escreveu ele.
Às 17:00 UTC de 5 de outubro, nenhum relay com a política do atacante estava no consenso, e nenhum havia retornado até 9 de outubro, segundo a análise dos dados do diretório. Quarenta e um relays, nove deles do Quetzalcoatl, ainda publicavam a política naquele momento, mas não estavam listados.
A contagem de relays com o sinalizador Exit no Tor Metrics caiu cerca de 370 entre 3 e 5 de outubro, correspondendo ao número de relays afetados, e não havia se recuperado até 18 de outubro.
Ebury e como os atacantes entraram
Zimmer descreveu seu lado em um post-mortem na lista em 7 de outubro. Dois de seus servidores executavam o Ebury versão 1.8.3: um servidor de gestão na Contabo que servia como gateway (portal de acesso) de VPN (Virtual Private Network, rede privada virtual) e jump host (servidor intermediário) SSH da família, e um VPS (Virtual Private Server, servidor virtual privado) da FranTech que ele chama de Switzerland2, no qual rodavam dois relays de saída.
O Ebury é um backdoor e ladrão de credenciais para o OpenSSH em atividade desde 2009, segundo a ESET, que estimou em 2024 que ele havia infectado 400.000 servidores, com mais de 100.000 ainda infectados no fim de 2023.
O atacante fez login no servidor de gestão em 28 de agosto com a senha da conta de operador na primeira tentativa, obteve acesso de root (superusuário) em cinco minutos, instalou o Ebury e, pouco mais de uma hora depois, acessou o Switzerland2 e o instalou lá também.
"A causa raiz foi nossa: uma senha reutilizada para login SSH, sudo e senha do backup, armazenada em texto puro nos dois servidores, além da autenticação por senha no SSH deixada habilitada no servidor de gestão exposto à internet", escreveu Zimmer. De onde o atacante obteve essa senha é desconhecido.
Os logins de backdoor do Ebury não deixam registro. Em 2 de outubro, os arquivos de configuração dos relays de saída foram reescritos sem login, comando sudo ou tarefa agendada nos logs, e os dois relays publicaram a política do atacante às 09:34 UTC. Ela permaneceu ativa por cerca de 52 horas em dois relays que movimentavam aproximadamente 3,4 TiB (Tebibytes, unidade de armazenamento) por dia.
Uma reinicialização de rotina em 4 de outubro matou as ferramentas ocultas do atacante, mas o Ebury voltou em seguida.
As chaves mestres "offline" da família "não estavam offline: cópias ficavam no backup da estação de trabalho no servidor de gestão, criptografadas com a senha que o atacante já tinha", escreveu Zimmer. Ele aposentou todos os relays e a bridge (ponte, nó de entrada do Tor) da família e apagou os dois servidores.
Este Ebury é um único arquivo de biblioteca setuid (com permissão para executar com privilégios do dono do arquivo), /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, com o link simbólico libkeyutils.so.1 apontando para ele. A biblioteca empacotada fica intocada, então dpkg -V e debsums não o detectam, e sshd, sudo e PAM (Pluggable Authentication Modules, módulos de autenticação do Linux) passam pelos seus checks de pacote. A versão 1.8.3 é mais recente que os indicadores públicos da ESET, que param na 1.8.2, e o script de detecção publicado pela ESET, lido em 21 de outubro, não lista um nome de socket para ela.
Marc-Etienne M. Léveillé, coautor do artigo de 2014 da ESET sobre o Ebury, autor do relatório de 2024 e que desde então deixou a empresa, respondeu que a versão 1.8.3 existe desde pelo menos junho de 2026 e publicou uma cópia atualizada do script que a contempla. "Dado quantos servidores tiveram Ebury entre 2009 e 2023 (400.000!), é muito provável que existam outros relays do Tor comprometidos", escreveu.
Como os hosts dos outros 58 operadores foram acessados é a principal questão em aberto. Entre os relays deles listados em 1º de outubro, 71 dos 101 hospedados na FranTech Solutions, a rede por trás da marca de hospedagem BuyVM, mudaram para a política do atacante, contra 13 dos 9.054 hospedados em outros lugares, segundo a análise dos dados do diretório.
Quarenta relays de 21 operadores mudaram em cinco minutos e meio em 1º de outubro, a maioria por recarregamento de configuração, o que a análise interpreta como um único ator já com acesso a todos os 40.
A melhor hipótese de Léveillé para a senha foi um login vindo de um host que já executava o Ebury, com a possibilidade alternativa de um provedor de hospedagem comprometido. A ESET já viu provedores cujos servidores de gestão executavam o Ebury e cujos servidores virtuais de clientes terminaram infectados, escreveu ele.
Kaba contou 26 dos 27 servidores comprometidos fora da família Quetzalcoatl na FranTech/BuyVM e perguntou na lista: "Será que eles comprometeram esses servidores no nível do provedor de hospedagem?"
O comprometimento do próprio Quetzalcoatl passou por seu servidor de gestão na Contabo, e 225 dos 273 relays afetados ficavam em outras redes.
Quem está por trás da campanha é desconhecido, assim como quantos dos hosts afetados executavam o Ebury: Zimmer examinou dois dos seus, e os dados do diretório mostram apenas a política. Um falso daemon CRON em letras maiúsculas e regras de NAT (Network Address Translation, tradução de endereços de rede) redirecionando a porta 22 estavam entre os sinais que outros operadores reportaram ao Projeto Tor. Os servidores de Zimmer não tinham nenhum desses, e se os casos compartilham um único ator é uma questão em aberto.
Nos relays de Zimmer, as mudanças de porta significavam que qualquer recuperação de e-mail só podia ocorrer em texto puro, escreveu ele, e um processo oculto chamado snf rodou no Switzerland2 durante a maior parte da janela. O que ele fazia é desconhecido.
O que operadores de relays devem verificar
O aviso do Projeto Tor pede que operadores de relays Linux verifiquem no Relay Search a presença de um sinalizador Exit ou política de saída que não tenham definido, e revisem o torrc e quaisquer arquivos incluídos em busca de alterações em linhas de ExitRelay, ExitPolicy, ContactInfo, MyFamily ou Nickname.
O aviso também lista regras de NAT na porta 22, processos desconhecidos em escuta ou conexões de saída, novos usuários, entradas em authorized_keys, tarefas agendadas e unidades do systemd (gerenciador de serviços do Linux), além de um binário do Tor que falhe em sua verificação de pacote. Os servidores de Zimmer não apresentaram nenhum dos sinais em nível de host dessa lista, apenas a política de saída alterada, então uma verificação de host limpa não descarta este Ebury.
Os sinais do implante, do post de Zimmer, são:
- Arquivo: /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, setuid e pertencente a nenhum pacote (63.368 bytes em seus servidores, com um hash que difere em cada servidor)
- Link simbólico: libkeyutils.so.1 apontando para esse arquivo
- Socket: socket UNIX abstrato @event-0YsOG9WSOE
- Processo: um falso /sbin/rsyslogd (antes systemd-udevd ou arpd) rodando dentro do cgroup (grupo de controle de processos) do ssh.service
- IP: 185.225.226[.]62, origem do login de 28 de agosto
- Chave SSH: RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, usada para logar no Switzerland2
- Chaves SSH embutidas no implante: RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo e ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y
- Chave de host do interceptador: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, vista na conexão de kaba
Verifique a partir de um sistema de recuperação ou de uma imagem de disco offline, se possível. Em um servidor em produção, faça login com uma chave. "Nunca digite uma senha em um servidor do qual você suspeita, porque o Ebury vai capturá-la", escreveu Zimmer.
Inicie um shell com H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash para passar pelo rootkit em nível de usuário (programa que oculta a presença de malware no sistema) antes de executar o script atualizado de Léveillé ou os comandos no post de Zimmer.
Se você o encontrar, os passos do Projeto Tor são:
- tire o relay do ar
- preserve o disco e os logs antes de apagar
- reinstale em vez de limpar
- gere uma nova identidade de relay e trate as chaves antigas como roubadas
- faça a rotação de todas as credenciais que estavam no host
Reinstalar é importante porque o implante sobreviveu a uma reinicialização no servidor de Zimmer. Reporte à bad-relays@lists.torproject.org e, se o seu endereço IP foi bloqueado durante o incidente, escreva ao mesmo endereço assim que o host estiver limpo para que o bloqueio seja removido, disse Georg Koppen, do Projeto Tor, em um complemento.
