I built exitmap over ten years ago. Glad to see it's still of use :)
4gotunameagain 1 days ago [-]
A bit of a tangential question but are there any guardrails around the capability that exitmap uses to perform its function ?
Could someone DDoS Tor by abusing exitmap ?
chatmasta 23 hours ago [-]
You can configure number of hops per circuit and that includes single hop circuits. So exitmap doesn’t add any functionality that isn’t already part of Tor.
kabakabakaba 1 days ago [-]
Thats awesome! Thanks for building it, it helped a ton :)
96718923545809 1 days ago [-]
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.
theteapot 1 days ago [-]
> This shouldn't affect key-based authentication, though
Depends what you mean by key and what you mean by affect. They can still MITM you if your using pubilc key authentication and you accept the servers host key without verifying it.
theamk 19 hours ago [-]
Can they? I believe SSH key bind the public key auth to the server identity, so this kind of MITM is impossible.
(Just don't turn on ForwardAgent)
2 hours ago [-]
theteapot 17 hours ago [-]
What does that even mean? ForwardAgent has nothing to do with it really.
emilfihlman 17 hours ago [-]
No they can't.
bikvfeee 18 hours ago [-]
Surely if it's someone else's hardware, they can manipulate ram and disk as well? It's just a matter of degree in how easy it is to implement.
adiabatichottub 18 hours ago [-]
It really depends on how paranoid you want to be. Removing their SSH keys and changing the root password will prevent casual snooping by rack-monkeys. If they need to change any hardware other than a drive they'll have to shut down the machine and you'll probably notice the gap in uptime. Keeping crucial data encrypted at rest will likely prevent pulling a mirrored drive and copying it. If that isn't enough security then you'll need to colocate and physically lock down the hardware yourself.
mschuster91 1 days ago [-]
> 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.
Tuna-Fish 1 days ago [-]
AFAIK, there has never been a memory encryption scheme that successfully protects the VM client from the hypervisor, they've all been found to be defective within a few years on the market.
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.
mschuster91 1 days ago [-]
> 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.
Tuna-Fish 1 days ago [-]
Yet less than 20% of the 80+ major vulnerabilities in confidential computing have been found by cloud companies, with the majority being found by universities and independent researchers.
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.
otterley 19 hours ago [-]
> 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.
I can tell you from direct experience on the inside at AWS that they care tremendously about virtualization security.
It's why they never let two tenants share a physical core simultaneously; they were prepared against side-channel attacks before Spectre and Meltdown were discovered.
It's why they never supported Intel SGX, preferring instead to sequester processors for confidential workloads (Nitro Enclaves), and why modern EC2 instances support memory encryption (Graviton + AMD SEV-SNP).
It's why, when you improperly remove a chassis from its cabinet, a mechanism destroys a key component containing the machine's attestation and encryption keys, rendering it useless.
It's why they delegated a large amount of security surface, including practically all I/O functions, to their off-CPU Nitro card.
cdud3 5 hours ago [-]
and yet they have solutions in place to work around all that to do all sorts of things with all there customers data without any customers knowledge because for example law enforcement agencies may demand that for one of there customers one day...
Fact is if you put it in the cloud you lost control. Data, services and integrity is gone. Uploading your stuff to Pirate Bay may actually be more secure because downloading it is maybe illegal :-)
otterley 4 hours ago [-]
> and yet they have solutions in place to work around all that to do all sorts of things with all there customers data without any customers knowledge
Such as what? Point to examples, please; don't just thread-crap hand-wavy statements like this.
Customers are free to--and are in fact encouraged to--use their own keys to encrypt their data both in transit and at rest.
> Fact is if you put it in the cloud you lost control. Data, services and integrity is gone.
The alternatives are arguably worse. You can't get anywhere near the durability of a cloud provider with any economically feasible alternative. Moreover, regardless of where you store data, law enforcement will be able to demand it be turned over with a valid warrant, and it's far easier for them to break down your door and collect it from your homelab servers (or just walk away with them under their arms) than to get into a Tier 1 cloud provider's data center and decrypt the encrypted data from it.
1 hours ago [-]
mulmen 1 days ago [-]
Is this a fair comparison? Why would we know about a cloud provider finding a vulnerability in their own product? Wouldn’t that be kept internal?
Tuna-Fish 23 hours ago [-]
Vulnerabilities are typically fixed, and then reported.
otterley 19 hours ago [-]
Reported to whom? In this case, it's the cloud provider itself.
zzrrt 1 days ago [-]
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.
InsidiousWombat 1 days ago [-]
Those features are mostly to stop VM-to-VM attacks. Host will always be able to mess with it one way or another and partly it is just needed.
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.
mschuster91 15 hours ago [-]
> like via IO devices or the provided storage.
... which AWS provides via the dedicated Nitro card to the VMs directly.
cortesoft 1 days ago [-]
Is there a way from within the VM, though, to determine if that hardware feature exists and is enabled? If you don't trust your VM provider, how do you trust them when they tell you they have that feature and it is enabled?
fc417fc802 1 days ago [-]
Depends on if you don't trust them not to actually snoop on you or if you don't trust them not to get compromised by a third party. In the latter case you'd presumably trust that they deployed the feature claimed.
mschuster91 10 hours ago [-]
> Is there a way from within the VM, though, to determine if that hardware feature exists and is enabled?
Yes, as long as you trust AMD's implementation to not be broken, which to my knowledge hasn't happened yet.
justsomehnguy 1 days ago [-]
Yeah, memory snapshots do not esxist, sure.
jandrese 1 days ago [-]
The attack on SSH seems rather poorly conceived. Not only was it detected immediately thanks to SSH printing that huge banner on MITM attacks, but it allowed the admins to easily trace every infected node and respond quickly to shut the whole operation down. Had they stuck to email they would still be running today.
michaelt 24 hours ago [-]
> Not only was it detected immediately thanks to SSH printing that huge banner on MITM attacks
The thing is, that only helps Tor users who are happy for their PC to contain evidence of what they were doing over Tor (such as a known hosts file listing).
If your security requirements are so high your PC contains no evidence whatsoever of what you were doing over Tor, you wouldn't get the banner.
stingraycharles 22 hours ago [-]
That’s actually a really good point, I remember from the Darknet Diaries podcasts that this is typically how darkweb operators manage their things, not using any storage and starting from a fresh machine every boot.
jandrese 21 hours ago [-]
This is one of the rare use cases where the users should be identifying the servers they are connecting to. If your work is that spooky then a piece of paper with the expected key signature seems like a reasonable precaution.
There used to be that "key art" that was posted to make it more visibly distinct, but I think that feature got discontinued.
solyin 20 hours ago [-]
Just disabled by default. Add
Host *
VisualHostKey yes
to your ~/.ssh/config/ to restore it.
I don't agree with the reasons they turned it off, but more importantly, you can get signed SSH host certificates to never see that prompt for that server ever again.
jszymborski 1 days ago [-]
3000 is insanely few exit nodes.
maeln 1 days ago [-]
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).
BorisMelnik 1 days ago [-]
agree I think tor is such a cool technology but even the thought of what is getting routed through there on my machine or even a machine I rent is enough for me to stay away from it
burningChrome 1 days ago [-]
I watched Adrian Crendshaw's DefCon talk about how people got busted using Tor and have also stayed away since then. I have used it in conjunction with TAILS a few times, but other than that, I don't mess with it any more.
DEF CON 22 - Adrian Crenshaw- Dropping Docs on Darknets: How People Got Caught
Same thought for me with Freenet about 15 years ago.
I liked the idea of it, especially since it was a time where ISPs were really cracking down on BitTorrents. But after seeing a few index sites inside the network, I quickly realized how much of that network was CSAM.
Deleted that and never looked back.
dmantis 1 days ago [-]
You don't route anything by default, you have to explicitly enable it if you wish to help the network.
And relay operators (not exit nodes) don't face any issues. Don't let the unreasonable fear blind you.
antonymoose 1 days ago [-]
I once worked at a very pro-hacker firm (USA) - our CTO, good as he was, once tried to migrate our Ubuntu based servers to BSD, this being a very high tier performance oriented HFT firm, purely on his love of the distro.
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.
maeln 14 hours ago [-]
Yep, running a relay is fine ! I did it for several years (even got the free shirt!). And it is still useful because more relay improve the network for hidden services (which are insanely cool to self-host some stuff, free NAT traversal !).
adrianN 1 days ago [-]
At least here in Germany I believe you’re on very shaky legal ground even if you’re just running a relay.
Schlagbohrer 15 hours ago [-]
Why are so many nodes in the entire network (bridge entries, relays, and exit nodes) in Germany then?
adrianN 14 hours ago [-]
Because the CCC likes to live dangerously.
tvexitnode 20 hours ago [-]
This somewhat begs the question. I know some smart tvs are sold cheap because they are secretly used in botnets. By multiple bad actors independently even, it's enough common of a strategy.
How come no one has done that for the dark web? That we know of at least? It would be incredibly annoying for cops to suddenly go knocking on 15 thousand doors of completely random people.
gambiting 1 days ago [-]
US government literally has a gigantic data centre purely for the purpose of storing encrypted data traffic that might be decoded one day. We can only assume that anything going through any US controlled TOR node ends up there.
goodpoint 14 hours ago [-]
...or donate to an organization that run them.
InsidiousWombat 1 days ago [-]
Because running one will get your machine blamed for any illegal activities that Tor users are up to. I ran one for whole 2 weeks, before my hosting provider just told me "pls stop".
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
Spivak 1 days ago [-]
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.
Palomides 1 days ago [-]
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
1 days ago [-]
malfist 1 days ago [-]
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.
maxbond 1 days ago [-]
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.
jacquesm 1 days ago [-]
No, it makes it much easier.
ghostbrainalpha 1 days ago [-]
So one person single-handedly knocked out 10% of the entire Tor exit network over an SSH port redirection?
jakzurr 1 days ago [-]
10% were compromised. The author contacted the Tor Project's network health team, who "made an announcement to the operators, who began shutting their exit nodes down."
kabakabakaba 1 days ago [-]
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.
Bender 1 days ago [-]
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.
Bender 1 days ago [-]
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.
jacquesm 1 days ago [-]
What I don't get: Why would you want to access hosts via ssh over TOR?
hackermailman 1 days ago [-]
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.
M95D 1 days ago [-]
- 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.
ndriscoll 1 days ago [-]
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?
tosti 1 days ago [-]
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.
jacquesm 1 days ago [-]
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.
mschuster91 1 days ago [-]
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.
cesarb 1 days ago [-]
> 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.
theamk 19 hours ago [-]
Are there restrictive firewalls which block unknown HTTP/HTTPS but not Tor? I'd expect Tor to be blocked first.
(And then proxying via your home is much faster and safer. You can do websocket-based proxy, but even exposing ssh server on port 443 works in a lot of places!)
nickdothutton 1 days ago [-]
Remote admin some shady server you control and do not want LE seeing a direct inbound ssh from you in Upper Sandusky, Ohio.
dustfinger 1 days ago [-]
TOR provides anonymity at the network level, SSH does not.
robinpie 22 hours ago [-]
I use Tor for NAT traversal. I ssh into my home computers over Tor all the time
jacquesm 21 hours ago [-]
What's the advantage over say Tailscale for this application?
NoidFonsense 1 days ago [-]
No public IP. you can use an onion service instead
mmooss 1 days ago [-]
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.
jacquesm 1 days ago [-]
I can't really see legal use cases for (1) and (2) might get you fired if the second. 2a is a 'maybe'.
mmooss 31 minutes ago [-]
Your argument seems to oppose anonymity overall, not just in Tor. Is that what you're really talking about here?
If so, the benefits and costs of anonymity, including legal benefits, are well-known. Why start that discussion over?
dist-epoch 1 days ago [-]
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.
m00dy 1 days ago [-]
thank you, you saved the whole world.
cesarb 1 days ago [-]
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.
g_p 1 days ago [-]
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.
eptcyka 1 days ago [-]
Or use fido/gpg in a yubikey - the user gets to authenticate the use of the secret, but it never leaves the hardware token, let alone the client computer.
michaelt 1 days ago [-]
> The biggest question is still how they got into all those servers in the first place.
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.
privacyishuman 1 days ago [-]
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. No problems now.
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.
declan_roberts 1 days ago [-]
I'm having trouble differentiating the different "attacks" here. Based on your thread it sounds like you're getting a DDoS attack against your nodes. The article appears to show some level of sophisticated OS backdooring (possibly from the ISP being compromised). Are you also seeing attempts to backdoor your nodes?
Writing a longer command to get less details and shorter output - this is so LLM!
A human would simply run the two commands in sequence and parse errors on the remote side - this would have gave more information about unexpected errors.
Nifty3929 1 days ago [-]
Not really the point of the article, but I'll use it as a soapbox anyway: Privacy (of the sort supported by Tor) is never a technology problem - it's a government / legislative problem.
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.
1 days ago [-]
Schlagbohrer 16 hours ago [-]
"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. :)"
can someone explain to me how SSH keys would have prevented this MITM? My understanding is that when the user gets the message from their SSH software that says "Warning! This SSH fingerprint has changed" and is prompted to re-login, that would happen whether it is by password or by key. So how would keys prevent this? One still has to re-link the SSH endpoints, and do it over a compromised connection in this case.
johanyc 5 hours ago [-]
> when the user gets the message from their SSH software that says "Warning! This SSH fingerprint has changed" ... that would happen whether it is by password or by key.
You have already sent the password to the mitm already.
evolve2k 1 days ago [-]
> 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?
QuantumNomad_ 1 days ago [-]
If you have an iPhone, the ssh client app Terminus can use the Secure Enclave of the iPhone to store your private key, which prevents all apps on the phone, even Terminus itself, from being able to read the private key. The private key is stored in hardware. You use FaceID to approve the login operation that ssh is performing.
I switched over to using that in Terminus recently instead of having Terminus generate and manage the private ssh keys.
Likewise, many Mac and MacBook machines have Secure Enclave too that can store private keys in hardware and works with the ssh client that comes with macOS. But I have not personally started using that yet. Will soon though. You then use TouchID to approve each login operation that ssh is performing.
Yubikey is cool too. I’ve used it mainly for other things than ssh.
Whatever solution you go with, have a backup or another way to restore access when your hardware key eventually breaks and cannot be used.
For example, instead of buying one Yubikey buy three and give each of them access to the same places. Keep one on you, one at home, and one somewhere else. Rotate between using each of them every couple of weeks so you are sure they all still work and that all of them have the accesses to all the same places.
In the case of ssh, you probably either have physical access to the target machine or you have VNC management from the hosting provider, etc, that you can fall back to if you misplace or damage your hardware key. So if you only use the hardware key for ssh and you have other means like those to get back in then having just a single hardware key is mostly fine.
g_p 1 days ago [-]
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.
hackermailman 1 days ago [-]
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
yonatan8070 1 days ago [-]
SSH keys are great, and you should absolutely use them
But you should also just listen to the big warning that says "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!"
hackermailman 1 days ago [-]
True they can also get information from the public ssh key like if you used a real email address or name to start spear phishing or who knows what else like extortion threats to your company
rektlessness 14 hours ago [-]
I was cleaning up a bunch of stale SSH access creds I had forgotten about and decided to migrate to FIDO2 keys.
> The use of Ebury and the broad collection of unencrypted data point to a financially motivated crime group.
Collection of unencrypted data points to other players as well that have been known to have great interest in Tor exit nodes etc., but they're careful and not usually this noisy, so probably newgen trolls.
DonHopkins 1 days ago [-]
[dead]
fguerraz 1 days ago [-]
Any legit use case for using SSH over Tor?
jandrese 1 days ago [-]
Administering your hidden service?
goodpoint 14 hours ago [-]
None, use an onion service for it.
illist-ell1s 1 days ago [-]
privacy
Rendered at 22:20:32 GMT+0000 (Coordinated Universal Time) with Vercel.
Could someone DDoS Tor by abusing exitmap ?
> 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 can still MITM you if your using pubilc key authentication and you accept the servers host key without verifying it.
(Just don't turn on ForwardAgent)
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.
I can tell you from direct experience on the inside at AWS that they care tremendously about virtualization security.
It's why they never let two tenants share a physical core simultaneously; they were prepared against side-channel attacks before Spectre and Meltdown were discovered.
It's why they never supported Intel SGX, preferring instead to sequester processors for confidential workloads (Nitro Enclaves), and why modern EC2 instances support memory encryption (Graviton + AMD SEV-SNP).
It's why, when you improperly remove a chassis from its cabinet, a mechanism destroys a key component containing the machine's attestation and encryption keys, rendering it useless.
It's why they delegated a large amount of security surface, including practically all I/O functions, to their off-CPU Nitro card.
Fact is if you put it in the cloud you lost control. Data, services and integrity is gone. Uploading your stuff to Pirate Bay may actually be more secure because downloading it is maybe illegal :-)
Such as what? Point to examples, please; don't just thread-crap hand-wavy statements like this.
Customers are free to--and are in fact encouraged to--use their own keys to encrypt their data both in transit and at rest.
> Fact is if you put it in the cloud you lost control. Data, services and integrity is gone.
The alternatives are arguably worse. You can't get anywhere near the durability of a cloud provider with any economically feasible alternative. Moreover, regardless of where you store data, law enforcement will be able to demand it be turned over with a valid warrant, and it's far easier for them to break down your door and collect it from your homelab servers (or just walk away with them under their arms) than to get into a Tier 1 cloud provider's data center and decrypt the encrypted data from it.
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.
... which AWS provides via the dedicated Nitro card to the VMs directly.
Yes, as long as you trust AMD's implementation to not be broken, which to my knowledge hasn't happened yet.
The thing is, that only helps Tor users who are happy for their PC to contain evidence of what they were doing over Tor (such as a known hosts file listing).
If your security requirements are so high your PC contains no evidence whatsoever of what you were doing over Tor, you wouldn't get the banner.
There used to be that "key art" that was posted to make it more visibly distinct, but I think that feature got discontinued.
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
https://www.youtube.com/watch?v=eQ2OZKitRwc
I liked the idea of it, especially since it was a time where ISPs were really cracking down on BitTorrents. But after seeing a few index sites inside the network, I quickly realized how much of that network was CSAM.
Deleted that and never looked back.
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.
How come no one has done that for the dark web? That we know of at least? It would be incredibly annoying for cops to suddenly go knocking on 15 thousand doors of completely random people.
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
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.
(And then proxying via your home is much faster and safer. You can do websocket-based proxy, but even exposing ssh server on port 443 works in a lot of places!)
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.
If so, the benefits and costs of anonymity, including legal benefits, are well-known. Why start that discussion over?
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.
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.
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.
A human would simply run the two commands in sequence and parse errors on the remote side - this would have gave more information about unexpected errors.
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.
can someone explain to me how SSH keys would have prevented this MITM? My understanding is that when the user gets the message from their SSH software that says "Warning! This SSH fingerprint has changed" and is prompted to re-login, that would happen whether it is by password or by key. So how would keys prevent this? One still has to re-link the SSH endpoints, and do it over a compromised connection in this case.
You have already sent the password to the mitm already.
Question: Where to get these hardware keys? Which are good options and why?
I switched over to using that in Terminus recently instead of having Terminus generate and manage the private ssh keys.
Likewise, many Mac and MacBook machines have Secure Enclave too that can store private keys in hardware and works with the ssh client that comes with macOS. But I have not personally started using that yet. Will soon though. You then use TouchID to approve each login operation that ssh is performing.
Yubikey is cool too. I’ve used it mainly for other things than ssh.
Whatever solution you go with, have a backup or another way to restore access when your hardware key eventually breaks and cannot be used.
For example, instead of buying one Yubikey buy three and give each of them access to the same places. Keep one on you, one at home, and one somewhere else. Rotate between using each of them every couple of weeks so you are sure they all still work and that all of them have the accesses to all the same places.
In the case of ssh, you probably either have physical access to the target machine or you have VNC management from the hosting provider, etc, that you can fall back to if you misplace or damage your hardware key. So if you only use the hardware key for ssh and you have other means like those to get back in then having just a single hardware key is mostly fine.
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.
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
But you should also just listen to the big warning that says "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!"
Wrote up the cleanup: isolate the clanker, retire the leftovers, move admin logins to a hardware key with touch and PIN. https://gist.github.com/AUAggy/c1881c1efd85b6cc46d3564ac9012...
If you are on a compatible Apple MacBook you can also use Touch-ID https://news.ycombinator.com/item?id=50175882
Collection of unencrypted data points to other players as well that have been known to have great interest in Tor exit nodes etc., but they're careful and not usually this noisy, so probably newgen trolls.