94 points kabakabakaba 2 hours ago 26 comments
kabakabakaba 2 hours ago | parent
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.
Bender 1 hour ago | parent
[1] - https://ifconfig.me/
kabakabakaba 1 hour ago | parent
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.
Bender 35 minutes ago | parent
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.
jacquesm 1 hour ago | parent
M95D 1 hour ago | parent
- Hide where you are in the world from your employer, who owns the server. (On vacation?)
- You're hacking the server.
ndriscoll 1 hour ago | parent
mschuster91 41 minutes ago | parent
nickdothutton 1 hour ago | parent
dustfinger 1 hour ago | parent
dist-epoch 53 minutes ago | parent
NoidFonsense 45 minutes ago | parent
cesarb 34 minutes ago | parent
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.
hackermailman 17 minutes ago | parent
mmooss 5 minutes ago | parent
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.
96718923545809 1 hour ago | parent
> 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.
mschuster91 42 minutes ago | parent
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.
zzrrt 8 minutes ago | parent
evolve2k 58 minutes ago | parent
Question: Where to get these hardware keys? Which are good options and why?
hackermailman 33 minutes ago | parent
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
g_p 29 minutes ago | parent
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.
cesarb 44 minutes ago | parent
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.
g_p 33 minutes ago | parent
phw 6 minutes ago | parent