Posted by kabakabakaba 8 hours ago
> 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.
Depends what you mean by key and what you mean by affect. They an still MITM you if your using pubilc key authentication and you accept the servers host key without verifying it.
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.
It is probably an useful layer because some of the attacks are not feasible for a remote attacker who has compromised the host but require actual physical access. But the marketing spiel of protecting your data from Amazon itself is just lies, physical access is more powerful than root access, no exceptions.
I'd trust Amazon and Google more than most others when it comes to stuff like formally verifying hardware security solutions and also doing active research against threats posed by malicious internal staff.
It's not actually in their interest to look too closely. They know they are selling snake oil, and they do not care if it works. The only function of the technology, as far as they are concerned, is to be something they can market to customers who are scared at running on public cloud, and either they never intend to exploit it, in which case it doesn't matter if it doesn't work, or they do, in which case they don't want the vulnerabilities to be found and fixed. Either way, there is no upside to them for going spelunking.
AMD SEV technically encrypts guest memory with key that is unavailable to hypervisor but there are still other ways to mess with VM inside, like via IO devices or the provided storage.
Whatever you try, whether Tor or VPNs or whatever - doesn't matter when the cops come knocking. VPNs are coming under legal attack now, and more and more sites refuse to work with them. You can say you're just running a relay, but if it came from your server they will put you in jail. Or consider the cyrpto anonymizer services - the folks running them might claim ignorance of where the crypto is coming from or going to - but they still go to jail.
If you want privacy, you have to get it at the ballot box.
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).
DEF CON 22 - Adrian Crenshaw- Dropping Docs on Darknets: How People Got Caught
And relay operators (not exit nodes) don't face any issues. Don't let the unreasonable fear blind you.
A good dozen engineers in a team of 50 ran relays, one bold fool ran an exit node and was falsely fingered for CSAM type crimes during my tenure. The net effect was no one ran relays anymore. The poor exit operator remains an Irish to this day because he has dozens of headlines about his arrest and none about the dropped charges.
Also depending on country you might be accused by aiding them, and it would be upon you to explain the court you have no control who uses the exit node nor their ID
https://forum.torproject.org/t/tor-relays-shutting-down-my-4...
People say that even running a middle or guard node can get your IP blacklisted. I don't have personal experience of this because I don't use my home IP for regular use, just for selfhosting. All the other devices run on a network wide commercial VPN so if it did happen it wouldn't be an issue.
The simplest way is to just launch the servers yourself, using a cloud provider. Tor is completely OK with exit node operators being anonymous, and with exit nodes running in cheap cloud data centres.
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.
[1] - https://ifconfig.me/
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.
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.
- Hide where you are in the world from your employer, who owns the server. (On vacation?)
- You're hacking the server.
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.
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.