Attackers hijacked over 300 Tor exit relays to intercept SSH logins

Compromised Tor relays were reconfigured to route SSH traffic to interception servers between October 1 and 5, stealing passwords and installing the Ebury backdoor, The Hacker News reports.

Attackers hijacked over 300 Tor exit relays to intercept SSH logins

At a glance

  • A researcher known as "kaba" found 333 Tor exits redirecting SSH connections to the same 12 interception servers in early October.
  • At the peak on October 4, relays using the attacker's exit policy made up 7.46% of Tor's exit capacity, according to a directory-data analysis.
  • Users who accepted an unfamiliar host key and logged in with a password between October 1 and 5 should treat that password as stolen.
  • The Tor Project flagged the relays as BadExit and removed them from the consensus by October 5; operators are urged to check hosts for Ebury.

Attackers took over more than 300 Tor exit relays in early October and used them to intercept SSH connections, steal passwords and, in some cases, install the Ebury backdoor on the servers users were connecting to, The Hacker News reported on October 21. A researcher who publishes as "kaba" found 333 exits redirecting SSH traffic to the same 12 interception servers, and the Tor Project removed the affected relays from the network by October 5. Anyone who logged into an SSH server over Tor with a password during that window may have exposed their credentials.

What happened

According to the report, attackers gained access to Linux hosts running Tor relays and edited their torrc configuration files. 342 relays that had blocked SSH began allowing it, and 24 relays that had not been exits became exits. A directory-data analysis counted 377 relays run by 59 operators that switched to the attacker's exit policy between October 1 and 4, which at the October 4 peak represented 7.46% of Tor's exit capacity by consensus weight. The analysis describes this as a policy match rather than proof that every relay was compromised.

The Hacker News traces the campaign to at least August 28, when an attacker logged into the management server of relay operator Zimmer's Quetzalcoatl family using the operator's password, gained root within minutes and installed Ebury. In a post-mortem, Zimmer said a single password had been reused for SSH, sudo and backups and stored in plaintext. How the other 58 operators' hosts were breached remains unknown, and the operator behind the campaign has not been identified.

Technical details

Clients connecting to port 22 through the rogue exits were routed to an interception server. On about a dozen exits it presented a fake host key; on roughly 300 others it forwarded traffic without changing the key. Users who accepted the key and typed a password handed it to the interceptor, which then logged into the real server so the session appeared normal. The report says the interceptor logged commands, checked for sudo rights and ran an installer matching Ebury, a long-running OpenSSH backdoor. Key-based logins could not be relayed to the real server.

The same configuration change blocked encrypted mail ports and, on most relays, opened plaintext POP3 and IMAP.

Who is affected

The Hacker News says users who connected to SSH servers over Tor between October 1 and 5, accepted a changed or unfamiliar host key and logged in with a password are at risk; there is no victim count. Relay operators are also affected. Former ESET researcher Marc-Etienne Léveillé warned that there are likely other compromised relays.

What to do

  • If you accepted an unfamiliar host key over Tor during the window, change the password and check the server for Ebury indicators. The reported interceptor key fingerprint is SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.
  • Prefer key-based SSH authentication and never accept unexpected host key changes.
  • Relay operators should check Relay Search and torrc files for unexpected exit policies, look for NAT rules on port 22, unknown users, cron jobs or systemd units, and reinstall compromised hosts, generating new relay identities.
  • Findings can be reported to the Tor Project's bad-relays team.

Sources

This story is based on the sources listed above. Always check the vendor’s official advisory before acting on critical systems.