O aviso de SSH que expôs 333 nós do Tor

Em 2 de outubro, 333 exit relays do Tor comprometidos começaram a redirecionar conexões SSH através de 12 servidores de interceptação, representando cerca de 10% dos exit relays da rede. Embora represente uma parcela menor da largura de banda total, esta campanha coordenada efetivamente transformou uma parte significativa da rede de anonimato em uma arma.

A armadilha foi insidiosa: o tráfego web normal passava intocado, mas o tráfego SSH na Port 22 era alterado. Usuários tentando uma conexão SSH seriam, sem saber, direcionados para um dos 12 servidores de interceptação, acionando um aviso crítico: “Remote host identification has changed.”

Muitos desenvolvedores, acostumados a ignorar tais avisos, provavelmente clicaram para prosseguir. Mas ignorar este alerta e continuar com a autenticação por senha expôs suas credenciais, registrou cada comando digitado e facilitou a implantação do Ebury, um backdoor e ladrão de credenciais do OpenSSH, em seus servidores.

O aviso em si é a peça-chave. As chaves de host SSH permitem que um cliente verifique a identidade de um servidor; uma incompatibilidade pode sinalizar eventos benignos, como uma reconstrução legítima do servidor. No entanto, é um indicador igualmente potente de um man-in-the-middle attack ativo. Este incidente demonstrou inequivocamente que este aviso nunca deve ser tratado como rotineiro ou ignorado sem uma investigação rigorosa.

Os atacantes prepararam sua armadilha com bastante antecedência, comprometendo hosts de relay em agosto e instalando o Ebury, um backdoor e ladrão de credenciais para Linux. Eles então modificaram as políticas torrc em 342 relays para permitir explicitamente a porta 22, convertendo pelo menos 24 relays que não eram de saída em exit nodes. Isso permitiu que o tráfego SSH saísse por relays que normalmente não o transportariam, redirecionando as conexões para um dos 12 servidores de interceptação SSH dedicados.

Quando uma vítima encontrava o aviso Remote host identification has changed e aceitava a chave SSH substituída, as consequências eram rápidas e graves. Fazer login com uma senha acionava um ataque multifacetado:

• Roubo de credenciais
• Monitoramento abrangente de comandos
• Uma tentativa automatizada de abrir uma segunda sessão SSH para o servidor de destino e instalar o Ebury, frequentemente via instaladores codificados em base64 com privilégios sudo.

Este incidente não implicou que o Tor criptografou ou expôs todas as conexões; a rede fornece anonimato de roteamento, não proteção de ponta a ponta. O Tor roteia o tráfego web padrão (portas 80/443) intocado. A verificação de host SSH permanece a salvaguarda crítica contra um exit relay que se passa pelo destino, uma defesa que 333 relays comprometidos — representando 10% dos exit nodes do Tor e 7,46% de sua largura de banda de saída total — subverteram.

Aquele aviso de SSH, "Remote host identification has changed", geralmente recebe um dar de ombros e um clique. Desta vez, um pesquisador, kaba, viu isso como um chamado à ação. Em vez de descartar o fingerprint inesperado, kaba aproveitou o ExitMap, um scanner especializado de exit relay do Tor, para testar sistematicamente a rede.

A metodologia de kaba foi elegante: conectar entre dois servidores controlados, roteando o tráfego através de cada Tor exit relay, e verificar se havia alterações nas impressões digitais SSH. Essa abordagem sistemática provou ser crítica. Ela permitiu que kaba distinguisse uma campanha de interceptação coordenada e generalizada de reconstruções de servidores isoladas ou simples erros de configuração, confirmando a escala sem precedentes do ataque. Para aqueles interessados em análise de rede, Exitmap: Fast and Modular Tor Exit Relay Scanner oferece um mergulho mais profundo nesta ferramenta poderosa.

Em 4 de outubro, a equipe de integridade da rede Tor marcou os relays maliciosos como BadExit. Eles foram rapidamente removidos do consenso da rede ativa até 5 de outubro. A equipe do Tor avaliou isso como um ataque sem precedentes, um testemunho de sua sofisticação, e não uma falha fundamental na arquitetura do Tor. O incidente destaca o papel crítico que pesquisadores independentes desempenham na manutenção da integridade da rede.

Aquele aviso de "Remote host identification has changed" não é uma sugestão; é um alarme. Quando uma chave de host SSH muda, pare. Verifique a nova impressão digital através de um canal fora de banda em que você confia, então — e somente então — atualize seu arquivo known_hosts. Nunca exclua cegamente a chave antiga ou aceite uma substituição sem confirmação; é precisamente assim que os atacantes do Ebury coletaram credenciais.

Desative a autenticação SSH baseada em senha sempre que possível. A autenticação por chave pública reduz significativamente o risco de roubo de senhas, mas não torna as verificações de identidade do host opcionais. Um gerenciamento de chaves forte, idealmente com módulos de segurança de hardware, fortalece ainda mais sua postura, mas uma chave de host comprometida continua sendo uma ameaça crítica.

Os operadores devem integrar essas lições em seus fluxos de trabalho. Revise logs de acesso e autenticação SSH inesperados imediatamente. Verifique processos desconhecidos ou componentes OpenSSH modificados — o Ebury 1.8.3 pode ser furtivo. Investigue suspeitas de infecções por Ebury usando a pesquisa da ESET para indicadores de comprometimento e consulte o artigo de kaba para detalhes mais profundos do incidente.

Este ataque a 333 Tor nodes foi um lembrete claro: a segurança é uma corrente, e os hábitos dos usuários são frequentemente seu elo mais fraco. Faça desse aviso de SSH um sinal de parada, não um quebra-molas.

O que aconteceu no ataque SSH ao Tor?

Os atacantes usaram relays Tor comprometidos para redirecionar conexões SSH através de servidores de interceptação, onde podiam roubar credenciais de usuários que ignoraram os avisos de chave de host.

O ataque comprometeu todo o tráfego do Tor?

Não. A campanha relatada visava conexões SSH, enquanto o tráfego web comum passava normalmente. O Tor não substitui a criptografia de ponta a ponta ou a verificação de host SSH.

O que é o Ebury?

Ebury é uma família de malware de backdoor e roubo de credenciais para Linux associada à adulteração do OpenSSH e à propagação de infecções entre servidores.

Como posso proteger as conexões SSH?

Rejeite alterações inesperadas de chave de host até que sejam verificadas por um canal confiável, use chaves SSH e desative a autenticação SSH baseada em senha onde possível.

O que é o ExitMap?

ExitMap é uma ferramenta para escanear Tor exit relays, usada pelo pesquisador kaba para identificar relays que alteraram conexões SSH.