Tor guard nodes seemed to be under attack but the devs aren't really engaging with it publicly, at least. It happened to mine and I had to switch it to a middle relay.
> But if you ignore the warning and go ahead with the login, the attacker does three things:
> 1. Steals your password
This shouldn't affect key-based authentication, though
Also, this from Marc-Etienne M.Léveillé email linked in your post:
> Another possibility is a compromised hosting provider. We identified a
couple of them in the past where their management servers were compromised
by Ebury and their customers' VPSes, containers, etc., ended up running
Ebury as well.
Provider-side compromise of customer VPS instances has been a growing trend in recent years. I stopped hosting anything privacy-related on VPS in favor of dedicated hardware. Many people still don't understand how easy it is for a provider to silently dump and/or manipulate both RAM and disk space in real-time.
> Many people still don't understand how easy it is for a provider to silently dump and/or manipulate both RAM and disk space in real-time.
That depends on the VPS technology stack being used. IIRC, at least Amazon uses hardware features like IOMMU that prevent any kind of access to the guest's memory from the host side.
If you believe Amazon and trust there is no way that this IOMMU protection can be disabled or bypassed, I guess this is mitigation against some attacks. Seems like mostly just trusting the AWS brand name, which would be more trustworthy than fly-by-night providers even without IOMMU.
In many countries, running an exit node is a very fast way to have cop knocking at your door and seizing all your stuff.
To run a tor exit node, you either have to try your best to stay anonymous, preferably be based in a country who don't care at all about cyber crime, and run them on a dodgy hosting provider who dgaf. Or you have to create a legal entity, either a non-profit or a company, depending on the country register as a hosting provider (so that you are not consider legally responsible for what comes out of your server if you abide by some rules), and you will still have to respond pretty fast to any police inquiry.
If anything, it's a miracle that there is 3000 of them. Although you can safely assume that a good portion of them (if not the majority) are operated by state intelligence services, cybersecurity companies and bad actor, who will log everything that pass through their node (and might be able to decrypt them one day).
It's insanely few, but also isn't that possibly an advantage? When lots of people's transfers are intermingled that means the possibility of separating out one person's traffic from the rest is harder.
Those user's traffic is cleanly separable at the destination, so this attack is always possible from some vantage point and isn't a defensible position. So malicious exit nodes are the real threat. Your reasoning would apply better to guard nodes.
Well yeah, because running an exit node in the US is "probably legal but there's precedent for still getting arrested and having your stuff seized." I can't imagine very many normal people are willing to paint a target on their backs like this.
Once again, this shows the strength of mutual authentication (ssh user key authentication, or HTTPS client certificates): even if the client accepts the forged server key from a MITM server, the real server won't accept the client key exchange (since it, at least in the SSH protocol, is bound to the connection). For the three things the attacker did here:
1. It can't steal your password, since the private key never leaves your client;
2. It can observe each command you type, but it can't open a connection to the real server to know how it would respond to your commands;
3. It can't open any connection to the real server (it will fail authentication), so it can't do anything to the real server.
If you really like passwords, there are ways to configure sshd to require both a client key and a password, in that order.
You could also do mutual authentication of SSH, with a local password-encrypted private keyfile, if you really like passwords. That gives you all the benefits of the "something you know" factor, without exposing the password to the server. And you can inspect how the decryption and use of the key happens (since it is on your computer), and therefore see it doesn't leave your computer.
TLDR: on Oct 2, 333 exits (~10% of Tor exits) started redirecting port 22 to 12 interception servers running a paramiko-based MITM that stole passwords and tried to drop Ebury on the target.
Thankyou for taking the time to detect and validate/verify those hosts. Is there a way you could make an outbound connection from them (maybe curl) to a site like ifconfig.me [1] and start logging which providers they are on then post a report of them on HN?
That doesnt prove FranTech itself was compromised, but its a strong cluster. AFAIK nobody has contacted them yet, if no one does, I plan to give them a heads up in the coming days.
That is useful information. Historically I have blocked BuyVM on my nodes due to their pro-privacy pro-tor-exit policy. Now I just put anyone arriving from them into a moderator review queue for my silly hobby sites.
It's a good policy to permit Tor exit nodes but it means their network will egress some of the most untoward behavior so that is expected and I would not default to assuming they are compromised, rather have some of the highest concentration of Tor exit nodes. There are pros and cons to such providers and you found one of them.
The Ebury botnet that's been around for a decade now is likely spying on Tor exit ssh tunnels looking for other criminals logging into their h4xxr jump boxes, ransomware deployments they can intercept and exploit themselves, financial crime market operators, crypto drug dealers etc.
I did exactly that as an intern. The boss blocked traffic for everything except tcp 80 and 443 in an attempt to block IM. I set up a tunnel to my house on one of those ports and arp cache poisoned my coworkers so I was their default gw. Only the boss still had filtered Internet and didn't understand how.
Hehe, that's funny. There are not that many opportunities to use your knowledge about the plumbing of the internet to good effect but that definitely was one of them.
And 4) you're the owner of the server, which is paid in bitcoin and hosted at a "bulletproof provider", and you want to leave no trace back to your "real" IP address should the authorities ever manage to seize it. Often the case for piracy, drug marketplaces and CSAM.
> Why would you want to access hosts via ssh over TOR?
When you're behind a restrictive firewall which blocks anything other than HTTP/HTTPS (like at an Internet café), or when there's some upstream routing issue making reaching the server directly impossible from your location (these can be a pain to diagnose).
Or perhaps it's simply your default: you proxy everything through Tor, and need a reason to not go through it.
People ssh over Tor for the same reason they use Tor for any network activity: To make confidential 1) your identity to the remote host and 2) your activities to your network providers (including your ISP/workplace/etc.).
If you want only confidential content, ssh is sufficient and so is https for web browsing. If you want the other things, you must use Tor or maybe something similar.
> The lesson is the same as always: extra security is a worthwhile investment. Disable password authentication in favor of ssh keys. I for one am going to buy myself some hardware keys today. :)
Question: Where to get these hardware keys? Which are good options and why?
You don't need to go out and buy hardware keys today. You should be able to use any FIDO2 key these days for SSH, as long as your server runs a recent enough OpenSSH server, which supports ecdsa-sk or ed25519-sk public keys.
Reputable vendors of those hardware keys included Yubikey and Token2, among others. You are really just using them as FIDO2 tokens, so go for what's reputable there.
If you are just getting started, you can generate and use software-backed keys (using ssh-keygen) and copy the public keys to servers' authorized_keys file using ssh-copy-id (or manually adding it). You should probably start learning this way (with plenty of online guides, and fewer risks of an old server implementation not supporting FIDO2 credentials), and then move to hardware keys once you understand the mechanics of copying around public keys, etc. Your password manager might also support acting as an SSH agent for key based logins - I believe Bitwarden and some others now do this, for example.
A Yubikey, though simply generating ssh keys instead of using passwords would stop this MITM attack. So would changing the rounds and port of ssh on your system and the remote box making yourself an invisible protocol nothing would recognize.
Yubikey benefits is it stores the keys in the hardware if your laptop is compromised somehow or stolen they at least don't get all the ssh keys too
Tor guard nodes seemed to be under attack but the devs aren't really engaging with it publicly, at least. It happened to mine and I had to switch it to a middle relay.
https://forum.torproject.org/t/tor-relays-shutting-down-my-4...
I built exitmap over ten years ago. Glad to see it's still of use :)
Thats awesome! Thanks for building it, it helped a ton :)
Thank you for writing this.
> But if you ignore the warning and go ahead with the login, the attacker does three things: > 1. Steals your password
This shouldn't affect key-based authentication, though
Also, this from Marc-Etienne M.Léveillé email linked in your post:
> Another possibility is a compromised hosting provider. We identified a couple of them in the past where their management servers were compromised by Ebury and their customers' VPSes, containers, etc., ended up running Ebury as well.
Provider-side compromise of customer VPS instances has been a growing trend in recent years. I stopped hosting anything privacy-related on VPS in favor of dedicated hardware. Many people still don't understand how easy it is for a provider to silently dump and/or manipulate both RAM and disk space in real-time.
> Many people still don't understand how easy it is for a provider to silently dump and/or manipulate both RAM and disk space in real-time.
That depends on the VPS technology stack being used. IIRC, at least Amazon uses hardware features like IOMMU that prevent any kind of access to the guest's memory from the host side.
If you believe Amazon and trust there is no way that this IOMMU protection can be disabled or bypassed, I guess this is mitigation against some attacks. Seems like mostly just trusting the AWS brand name, which would be more trustworthy than fly-by-night providers even without IOMMU.
Any legit use case for using SSH over Tor?
3000 is insanely few exit nodes.
In many countries, running an exit node is a very fast way to have cop knocking at your door and seizing all your stuff. To run a tor exit node, you either have to try your best to stay anonymous, preferably be based in a country who don't care at all about cyber crime, and run them on a dodgy hosting provider who dgaf. Or you have to create a legal entity, either a non-profit or a company, depending on the country register as a hosting provider (so that you are not consider legally responsible for what comes out of your server if you abide by some rules), and you will still have to respond pretty fast to any police inquiry.
If anything, it's a miracle that there is 3000 of them. Although you can safely assume that a good portion of them (if not the majority) are operated by state intelligence services, cybersecurity companies and bad actor, who will log everything that pass through their node (and might be able to decrypt them one day).
It's insanely few, but also isn't that possibly an advantage? When lots of people's transfers are intermingled that means the possibility of separating out one person's traffic from the rest is harder.
Those user's traffic is cleanly separable at the destination, so this attack is always possible from some vantage point and isn't a defensible position. So malicious exit nodes are the real threat. Your reasoning would apply better to guard nodes.
No, it makes it much easier.
Well yeah, because running an exit node in the US is "probably legal but there's precedent for still getting arrested and having your stuff seized." I can't imagine very many normal people are willing to paint a target on their backs like this.
plus becoming the technical target of every spy agency and tons of random hackers! likely the most trouble you can bring to your computers legally
So one person single-handedly knocked out 10% of the entire Tor exit network over an SSH port redirection?
Once again, this shows the strength of mutual authentication (ssh user key authentication, or HTTPS client certificates): even if the client accepts the forged server key from a MITM server, the real server won't accept the client key exchange (since it, at least in the SSH protocol, is bound to the connection). For the three things the attacker did here:
1. It can't steal your password, since the private key never leaves your client;
2. It can observe each command you type, but it can't open a connection to the real server to know how it would respond to your commands;
3. It can't open any connection to the real server (it will fail authentication), so it can't do anything to the real server.
If you really like passwords, there are ways to configure sshd to require both a client key and a password, in that order.
You could also do mutual authentication of SSH, with a local password-encrypted private keyfile, if you really like passwords. That gives you all the benefits of the "something you know" factor, without exposing the password to the server. And you can inspect how the decryption and use of the key happens (since it is on your computer), and therefore see it doesn't leave your computer.
Author here :)
TLDR: on Oct 2, 333 exits (~10% of Tor exits) started redirecting port 22 to 12 interception servers running a paramiko-based MITM that stole passwords and tried to drop Ebury on the target.
Thankyou for taking the time to detect and validate/verify those hosts. Is there a way you could make an outbound connection from them (maybe curl) to a site like ifconfig.me [1] and start logging which providers they are on then post a report of them on HN?
[1] - https://ifconfig.me/
In my scan on October 2, 26 of the 27 compromised servers outside the Quetzalcoatl relay family (most hosting multiple exits) were at FranTech/BuyVM.
It's been discussed on the mailing list: https://lists.torproject.org/mailman3/hyperkitty/list/tor-re...
That doesnt prove FranTech itself was compromised, but its a strong cluster. AFAIK nobody has contacted them yet, if no one does, I plan to give them a heads up in the coming days.
That is useful information. Historically I have blocked BuyVM on my nodes due to their pro-privacy pro-tor-exit policy. Now I just put anyone arriving from them into a moderator review queue for my silly hobby sites.
It's a good policy to permit Tor exit nodes but it means their network will egress some of the most untoward behavior so that is expected and I would not default to assuming they are compromised, rather have some of the highest concentration of Tor exit nodes. There are pros and cons to such providers and you found one of them.
What I don't get: Why would you want to access hosts via ssh over TOR?
The Ebury botnet that's been around for a decade now is likely spying on Tor exit ssh tunnels looking for other criminals logging into their h4xxr jump boxes, ransomware deployments they can intercept and exploit themselves, financial crime market operators, crypto drug dealers etc.
- Default route is over tor and you didn't make an exception for ssh.
- Hide where you are in the world from your employer, who owns the server. (On vacation?)
- You're hacking the server.
Tor sounds like just about the worst possible way to hide what you're doing from your employer. Why would you not proxy through... your house?
I did exactly that as an intern. The boss blocked traffic for everything except tcp 80 and 443 in an attempt to block IM. I set up a tunnel to my house on one of those ports and arp cache poisoned my coworkers so I was their default gw. Only the boss still had filtered Internet and didn't understand how.
Hehe, that's funny. There are not that many opportunities to use your knowledge about the plumbing of the internet to good effect but that definitely was one of them.
And 4) you're the owner of the server, which is paid in bitcoin and hosted at a "bulletproof provider", and you want to leave no trace back to your "real" IP address should the authorities ever manage to seize it. Often the case for piracy, drug marketplaces and CSAM.
Remote admin some shady server you control and do not want LE seeing a direct inbound ssh from you in Upper Sandusky, Ohio.
> Why would you want to access hosts via ssh over TOR?
When you're behind a restrictive firewall which blocks anything other than HTTP/HTTPS (like at an Internet café), or when there's some upstream routing issue making reaching the server directly impossible from your location (these can be a pain to diagnose).
Or perhaps it's simply your default: you proxy everything through Tor, and need a reason to not go through it.
TOR provides anonymity at the network level, SSH does not.
No public IP. you can use an onion service instead
How does this use case differ?
People ssh over Tor for the same reason they use Tor for any network activity: To make confidential 1) your identity to the remote host and 2) your activities to your network providers (including your ISP/workplace/etc.).
If you want only confidential content, ssh is sufficient and so is https for web browsing. If you want the other things, you must use Tor or maybe something similar.
I can't really see legal use cases for (1) and (2) might get you fired if the second. 2a is a 'maybe'.
If the SSH host is a backdoor you installed in a company you hacked, you don't want the FBI tracing it back to you.
thank you, you saved the whole world.
> The lesson is the same as always: extra security is a worthwhile investment. Disable password authentication in favor of ssh keys. I for one am going to buy myself some hardware keys today. :)
Question: Where to get these hardware keys? Which are good options and why?
You don't need to go out and buy hardware keys today. You should be able to use any FIDO2 key these days for SSH, as long as your server runs a recent enough OpenSSH server, which supports ecdsa-sk or ed25519-sk public keys.
Reputable vendors of those hardware keys included Yubikey and Token2, among others. You are really just using them as FIDO2 tokens, so go for what's reputable there.
If you are just getting started, you can generate and use software-backed keys (using ssh-keygen) and copy the public keys to servers' authorized_keys file using ssh-copy-id (or manually adding it). You should probably start learning this way (with plenty of online guides, and fewer risks of an old server implementation not supporting FIDO2 credentials), and then move to hardware keys once you understand the mechanics of copying around public keys, etc. Your password manager might also support acting as an SSH agent for key based logins - I believe Bitwarden and some others now do this, for example.
A Yubikey, though simply generating ssh keys instead of using passwords would stop this MITM attack. So would changing the rounds and port of ssh on your system and the remote box making yourself an invisible protocol nothing would recognize.
Yubikey benefits is it stores the keys in the hardware if your laptop is compromised somehow or stolen they at least don't get all the ssh keys too