333 Tor exit nodes infected with Ebury were intercepting SSH

On Friday Oct 2 at 09:35am, 333 infected Tor exit nodes began a coordinated campaign to intercept SSH connections and collect as much unencrypted data as possible. Tor has around 3000 exit relays, so the attackers controlled roughly 10% of them. According to the author of the kaba.cx post, they had gained access to the servers two months earlier, in August, and quietly deployed an Ebury 1.8.3 payload, an OpenSSH backdoor and credential stealer for Linux.

The author says the attack appears to have had two goals. The first was to gather unencrypted mail traffic: by blocking certain ports, the attackers made their exit nodes handle only unencrypted mail. The writeup he points to for that part comes from one of the victims, a veteran Tor operator, on the Tor mailing list. The second goal was an SSH man-in-the-middle, which is the focus of the post. A user whose circuit exits through one of the infected nodes notices nothing at first. Encrypted web traffic is forwarded as usual, but an SSH connection on port 22 is silently redirected to one of 12 SSH interception servers.

That is what happened to the author on Friday morning: his SSH client printed the "REMOTE HOST IDENTIFICATION HAS CHANGED" warning. If a user ignores it and logs in, the attacker does three things: steals the password, opens a connection to the user's real server and watches every command typed, and opens a second connection to infect that server with Ebury.

On Friday evening the author sent his findings to the Tor Project's network health team. They confirmed it was something new and began contacting the affected relay operators. Their comment: "We've not seen an attack like that before." The timeline he gives: interception started Fri Oct 2; on Sun Oct 4 the team announced the problem to operators, who began shutting their exits down, and the relays were marked BadExit so clients would stop using them to exit traffic; on Mon Oct 5 the attackers restarted many relays, but because they were already flagged these could only serve as middle relays, and later that day all infected servers were shut down, partly by operators and partly by the attackers. The health team described the pattern in its announcement: the attacker gains access to Linux hosts, and when those machines run as non-exits, edits the torrc file to turn them into exits. On metrics.torproject.org a clear dip is visible on October 4th and has not recovered since.

To find the nodes, the author used exitmap to build a script that pinned an exit node and opened an SSH connection from his server A to his server B. Server A checked that it received the right SSH fingerprint from B; server B checked whether the connection arrived from the pinned exit or from one of the 12 interception servers. He ran it against every one of the ~3000 exit relays. Around a dozen served a fake fingerprint, and over 300 intercepted nothing but still redirected through the same interception servers. Redirection alone was enough to confirm an exit was infected. In further analysis he used sshesame as a honeypot and tricked the MITM into logging into it. That showed the attackers used paramiko, a Python SSH library, and tried to install Ebury with Perl: a command that first checks permissions and sudo, then runs a base64-encoded payload through perl.

Two questions remain open. How the attackers got into all those servers is unknown; one theory is that the hosting company was itself hacked, but the author calls it just a theory and says no one really knows. Who is behind it is also unknown: the use of Ebury and the broad collection of unencrypted data point to a financially motivated crime group, though the author calls this speculation too. He also suspects the attack was launched on a Friday in the hope nobody would answer over the weekend, and praises the Tor team for acting quickly. His takeaway: disable password authentication in favor of SSH keys, and he plans to buy hardware keys. Marc-Etienne M. Léveillé is quoted from the Tor mailing list saying that, given how many servers had Ebury between 2009 and 2023 (400 000), there are most likely other compromised Tor relays out there.

Key facts

• 333 Tor exit nodes infected with Ebury 1.8.3 began a coordinated campaign on Friday Oct 2, about 10% of Tor's roughly 3000 exit relays.
• On an infected exit, encrypted web traffic passes normally, but SSH on port 22 is redirected to one of 12 interception servers that steal passwords, watch commands and try to infect the target server with Ebury.
• The author found the nodes by running an exitmap-based test against all ~3000 exits: around a dozen served a fake SSH fingerprint and over 300 only redirected.
• The relays were marked BadExit on Oct 4 and all infected servers were shut down by Oct 5, partly by operators and partly by the attackers.
• How the attackers got in and who they are remain unknown; the author's advice is to use SSH keys instead of passwords.

Why it matters

About one in ten Tor exit relays was under one attacker's control, and the Tor network health team said it had not seen an attack like it before. The campaign targeted two things at once: unencrypted mail traffic, and SSH sessions, where a stolen password plus a second connection let the attacker infect the user's own server with Ebury. The attackers had held the servers since August and struck two months later.

Who it affects

Anyone who made an SSH connection on port 22 through Tor while their circuit exited via one of the 333 infected nodes, and anyone sending unencrypted mail traffic through them. Relay operators are affected too: the health team says the attacker took over Linux hosts and, where they ran as non-exits, edited torrc to make them exits. One victim was a veteran Tor operator. The post does not say how many users had passwords stolen or servers infected.

How to use it

The author's advice is to disable password authentication in favor of SSH keys, and he plans to buy hardware keys himself. Treat a "REMOTE HOST IDENTIFICATION HAS CHANGED" warning as a possible man-in-the-middle; the attack only pays off if the user ignores it and logs in. Operators are told by George, quoted from the Tor mailing list, that relays and bridges need to be treated as highly targeted production machines. The author also links the Tor Project's relay setup page for anyone who wants to run a relay. For checking exits, his method used exitmap with two servers, one to check the fingerprint received and one to see whether the connection came from the pinned exit or an interception server.

How solid is it

This is a firsthand account from a Tor user whose own SSH connection was redirected, backed by his own scan of all ~3000 exits and a honeypot test. The Tor network health team's quotes and the BadExit timeline are given as reported by the author, and the dip on metrics.torproject.org is cited as corroboration. The author's name is not given in the text. The attackers' goals are described as what the attack "appears" to have had, and the crime-group and Friday-timing ideas are labelled speculation or suspicion by the author himself.

Risks and caveats

How the attackers got into the servers is unknown; the hosting-company hack is only a theory. Who is behind the campaign is unknown too. Marc-Etienne M. Léveillé warns that, given how many servers had Ebury between 2009 and 2023 (400 000), there are most likely other compromised Tor relays. When the infected relays were flagged, the attackers restarted many of them on Oct 5, but as flagged relays they could only serve as middle relays. The source post's headline word "removed" glosses over the mechanics: the nodes were flagged BadExit and shut down by operators and attackers, not taken down by the author directly.

“We've not seen an attack like that before.”

— Tor Network Health Team, quoted in the kaba.cx post