Attackers took control of more than 300 Tor exit relays in early October and used them to redirect SSH connections to servers that stole login passwords, a researcher found.
Exit relays are the last hop in a Tor circuit, where traffic leaves the network for its destination. Only a password login to an SSH server made through Tor between October 1 and 5, after accepting the interception server's host key, could have been captured.
The Tor Project began flagging relays on October 4, and by October 5, none remained in the consensus, the list of relays that Tor clients use. At the peak on October 4, the relays carrying the attacker's exit policy made up 7.46% of Tor's exit capacity, measured by consensus weight, according to an analysis of public Tor directory data posted to the tor-relays mailing list.
The researcher, who publishes as kaba, scanned all of Tor's roughly 3,000 exits on October 2 and found 333 redirecting SSH to the same 12 interception servers. The directory-data analysis counts 377 relays run by 59 operators that switched to the attacker's exit policy between October 1 and 4, which it calls "a policy match, not proof of compromise."
How the Hijacked Exits Intercepted SSH
An exit relay only carries traffic to the ports its exit policy allows. The attackers rewrote that policy in the relays' torrc configuration files to allow port 22 (the SSH port), enabling SSH on 342 relays that had blocked it. Another 24 relays that had not been exits at all became exits.
"It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack," the Tor Project's network health team wrote in its October 5 notice to relay operators. Most of the affected relays were already exits, the directory data shows.
The same change closed the encrypted mail ports, IMAPS and POP3S, and on most relays opened the plaintext-capable ones, POP3 and IMAP.
A Tor client only picks an exit that allows the destination port, so these relays stopped carrying encrypted mail and started carrying SSH, Telnet, and, on most of them, plaintext mail. Why the encrypted mail ports were closed is not visible in the data, the analysis says.
With port 22 open, an SSH connection through one of these exits went to one of 12 interception servers instead of its destination, kaba found. When a server intercepted the connection, it presented its own host key. A user who already knew the real server's key saw OpenSSH's warning that the remote host identification had changed, and a user connecting for the first time saw the usual prompt to accept a new key.
In the October 2 scan, about a dozen exits were serving a fake host key, and the other 300 or so redirected through the same servers without altering the key.
A user who accepted the key and typed a password handed it to the interceptor. The interceptor connected to the real server, so the session worked, and every command could be watched and separately logged in with the stolen password to check for sudo and run a base64-encoded Perl installer. In kaba's honeypot, the installer took the same form as the command that put Ebury, a backdoor that hides inside OpenSSH, on one of a relay operator's servers, as described below.
A key-based SSH login could not be relayed this way. Under the SSH authentication protocol, , the client's signature includes an identifier unique to each session, so a signature made for the interceptor's session is useless against the real server. The interceptor could still accept a key login itself and show a fake shell, but it could not reach the real server with it.
A password, by contrast, travels inside the encrypted session and can be read by the server at the other end, which here was the interceptor.
Who Was Exposed, and What to Do If You Were
To be exposed, someone had to connect to an SSH server over Tor between October 1 and the afternoon of October 5, land on one of the hijacked exits, have the connection intercepted rather than passed through, accept the interceptor's host key, and log in with a password. No count of victims exists.
If you accepted an unfamiliar or changed host key over Tor in that window, treat the password you typed as stolen, change it, and check that server for the Ebury signs listed below. An OpenSSH client that accepted the key saved it in known_hosts.
The server that intercepted kaba's connection used an ED25519 key with the fingerprint SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, though the other interception servers may have used different keys.
How It Was Found and Stopped
Kaba encountered the attack on the morning of October 2, when an SSH connection over Tor returned a changed-key warning. He then used exitmap, a scanning tool that the Tor Project's network health team also uses, to open an SSH connection from one of his servers to another via each exit in turn.
One end checked whether the host key was correct, and the other whether the connection originated at the exit or from an interception server. He reported the results to the health team that evening.
The health team also spotted the policy change through its own monitoring. On October 4, it contacted Zimmer, who ran the Quetzalcoatl relay family, the largest group of affected relays, and Zimmer confirmed the change was not his, asked for the relays to be marked bad, and stopped Tor on the server running them.
Directory authorities began voting the BadExit and MiddleOnly flags on affected relays at 18:00 UTC that day, and the flags were in the consensus by 21:00. BadExit tells Tor clients never to use a relay as an exit.
On the morning of October 5,, a scripted restart swept through 55 of Quetzalcoatl's hosts, with the policy still in place. Who ran it is not known. The directory authorities were by then rejecting affected relays from the network, the Tor Project said in its notice, and the two relays Zimmer had stopped were refused when they tried to rejoin, he wrote.
By 17:00 UTC on October 5, no relay with the attacker's policy was in the consensus, and none had returned as of October 9, the directory-data analysis found. Forty-one relays, nine of them Quetzalcoatl's, were still publishing the policy at that point but were not listed.
Tor Metrics' count of relays carrying the Exit flag fell by about 370 between October 3 and October 5, matching the number of affected relays, and had not recovered by October 18.
Ebury, and How the Attackers Got In
Zimmer described his side in a post-mortem on the list on October 7. Two of his servers were running Ebury version 1.8.3: a management server at Contabo that served as the family's VPN gateway and SSH jump host, and a FranTech VPS he calls Switzerland2 that ran two of the exits.
Ebury is a backdoor and credential stealer for OpenSSH that has been active since 2009, according to ESET, which estimated in 2024 that it had infected 400,000 servers, with more than 100,000 still infected in late 2023.
The attacker logged in to the management server on August 28 with the operator account's password on the first try, gained root within five minutes, installed Ebury, then reached Switzerland2 a little over an hour later and installed it there too.
"The root cause was ours: one password reused for SSH login, sudo and the backup passphrase, stored in plaintext on both servers, plus SSH password authentication left enabled on the internet-facing management server," Zimmer wrote. Where the attacker got that password is unknown.
Ebury's backdoor logins leave no record. On October 2, the exits' configuration files were rewritten with no login, sudo command, or cron job in the logs, and the two relays published the attacker's policy at 09:34 UTC. It stayed live for about 52 hours on two relays moving roughly 3.4 TiB a day.
A routine reboot on October 4 killed the attacker's hidden tools, but Ebury came straight back.
The family's "offline" master keys "were not offline: copies sat in the workstation backup on the management server, encrypted with the password the attacker already had," Zimmer wrote. He retired every relay and the bridge in the family and deleted both servers.
This Ebury is a single setuid library file, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, with the libkeyutils.so.1 symlink pointed at it. The packaged library is untouched, so dpkg -V and debsums do not catch it, and sshd, sudo, and PAM pass their package checks. Version 1.8.3 is newer than ESET's public indicators, which stop at 1.8.2, and ESET's published detection script, read on October 21, lists no socket name for it.
Marc-Etienne M. Léveillé, who co-wrote ESET's 2014 Ebury paper, wrote its 2024 report and has since left the company, replied that version 1.8.3 has been around since at least June 2026 and posted an updated copy of the script that covers it. "Given how many servers had Ebury between 2009 and 2023 (400 000!), there are most likely other compromised Tor relays out there," he wrote.
How the other 58 operators' hosts were entered is the main open question. Among their relays listed on October 1, 71 of the 101 hosted on FranTech Solutions, the network behind the BuyVM hosting brand, switched to the attacker's policy, against 13 of 9,054 hosted elsewhere, the directory-data analysis found.
Forty relays of 21 operators changed within five and a half minutes on October 1, most by a configuration reload, which the analysis reads as one actor already holding access to all 40.
Léveillé's best guess for the password was a login from a host already running Ebury, with a compromised hosting provider as another possibility. ESET has seen providers whose management servers ran Ebury and whose customers' virtual servers ended up infected, he wrote.
Kaba counted 26 of the 27 compromised servers outside the Quetzalcoatl family at FranTech/BuyVM and asked on the list: "Could they have compromised those servers at the hoster level?"
Quetzalcoatl's own compromise ran through its Contabo management server, and 225 of its 273 affected relays sat on other networks.
Who is behind the campaign is unknown, and so is how many of the affected hosts ran Ebury: Zimmer examined two of his, and the directory data shows only the policy. A fake uppercase CRON daemon and NAT rules redirecting port 22 were among the signs other operators reported to the Tor Project. Zimmer's servers had neither, and whether the cases share one actor is open.
On Zimmer's relays, the port changes meant any mail retrieval could only happen in plaintext, he wrote, and a hidden process named snf ran on Switzerland2 for most of the window. What it did is unknown.
What Relay Operators Should Check
The Tor Project's notice asks Linux relay operators to check Relay Search for an Exit flag or exit policy they did not set, and to look through torrc and any included files for changed ExitRelay, ExitPolicy, ContactInfo, MyFamily or Nickname lines.
It also lists NAT rules on port 22, unknown listening processes or outbound connections, new users, authorized_keys entries, cron jobs and systemd units, and a tor binary that fails its package check. Zimmer's servers showed none of the host-level signs on that list, only the changed exit policy, so a clean host check does not rule out this Ebury.
The signs of the implant, from Zimmer's post, are:
- File: /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, setuid and owned by no package (63,368 bytes on his servers, with a hash that differs on every server)
- Symlink: libkeyutils.so.1 pointing at that file
- Socket: abstract UNIX socket @event-0YsOG9WSOE
- Process: a fake /sbin/rsyslogd (earlier systemd-udevd or arpd) running inside the ssh.service cgroup
- IP: 185.225.226[.]62, the source of the August 28 login
- SSH key: RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, used to log in to Switzerland2
- SSH keys embedded in the implant: RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo and ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y
- Interceptor host key: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, seen on kaba's connection
Check from a rescue system or an offline disk image if you can. On a live server, log in with a key. "Never type a password into a server you suspect, because Ebury will capture it," Zimmer wrote.
Start a shell with H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash to get past the userland rootkit before running Léveillé's updated script or the commands in Zimmer's post.
If you find it, the Tor Project's steps are:
- take the relay offline
- preserve the disk and logs before wiping
- reinstall rather than clean up
- generate a new relay identity and treat the old keys as stolen
- rotate every credential that was on the host
Reinstalling matters because the implant survived a reboot on Zimmer's server. Report to bad-relays@lists.torproject.org, and if your IP address was blocked during the incident, write to the same address once your host is clean to have the block lifted, Georg Koppen of the Tor Project said in a follow-up.
from The Hacker News https://ift.tt/olec8dS
via IFTTT
No comments:
Post a Comment