Zero Effort Private Key Compromise: Abusing SSH-Agent for Lateral Movement | Hacker News Reader

Zero Effort Private Key Compromise: Abusing SSH-Agent for Lateral Movement

grahamhelton.com

61 pointswarrenm26 comments

Not mentioned in the article, but if you add the key to your agent with "ssh-add -c <key>", then whenever the key is used to connect to another machine by the agent, the agent will prompt (on the machine where it was initially run) to confirm that the connection is intended, generally via "ssh-askpass".

In my world, I use this routinely, precisely to detect a connection using a hijacked session, as described in the article. It does not detect the agent hijacking itself, it only detects new connections -- it pops up for all connections, both intended and unintended.

I know we're all supposed to do defense in depth, but I confess to having a bit of a jaundiced view of attacks that begin, "first, become root on a machine in the target domain....". Containment is a good idea, but if you're at the point where you're doing containment of compromised root accounts "inside", things have gone pretty far wrong already.

Or even better, use ProxyJump and don’t forward your agent at all :)

I'm moving towards this for my current workplace. SSH will only be allowed via VPN, only to a bastion, and that bastion will not permit agent forwarding, or really much of anything other than ProxyJump. I'm baffled that agent forwarding is a feature when OpenSSH won't even use a key file if the permissions are wrong.

Agent forwarding has its uses; not all of them can be replaced by ProxyJump.

I never need to SSH directly into servers. When I do, I need to be able to clone private git repos. ssh agent forwarding is the right answer.

To go further, use a VPN that uses UDP and only allow that connection after port knocking three randomly chosen ports.

This is way overkill when you could simply use Wireguard instead.

Not really, its just a few lines in your nftables/iptables rules. And sure, wireguard is great. It's just an underrated trick from decades ago. :)

> So, is this a vulnerability? Well no, not exactly [...]

Connecting to a compromised machine with `ssh -A` (agent forwarding) lets the attacker use your credentials for ssh sessions elsewhere. It's almost explained in the man page.

Avoid the agent forwarding and you are fine.

Nice article, although the title is slightly off. The private key is not compromised (as described agent forwarding uses a challenge-response method) and the attacker can only initiate connections as long as the agent is being forwarded.

Though true in most cases you can then add your own authorized_keys entry.

That does not compromise the user’s SSH key, though, “only” (and potentially persistently as you say) one or more target servers.

OpenSSH 8.9 introduced a restriction feature to mitigate this.

https://www.openssh.com/agent-restrict.html

It works as advertised. It's a bit clunky to use since it applies to the whole ssh agent, so if you only want it to apply to a specific ssh connection you have to spawn a new agent (unless somebody teaches me a better trick).

Example scenario:

I'm on my laptop and I use ssh-agent with my key stored on a HSM device. I use it many many times every hour to interact with my git servers and jumping to other machines. It's kn my laptop so I don't want to fiddle with further restrictions.

I also have to ssh on a remote machine where I would like to restrict agent forwarding to only perform for a selected hosts (mostly so I can git pull from private repos)

Can I do this with one agent?

Yes, your local agent can be accessed on the destination host by any other user with the necessary privileges (including your own account -- a root compromise is not required). This has been known for a very long time and a warning is included in the documentation. No, it does not compromise any private keys.

Your private keys are more likely to be compromised when you store them on untrusted systems. SSH-Agent allows you to avoid that risk.

Another mitigation is to use a dedicated agent per private key (or group of keys) to prevent forwarding keys to destinations that don't need them.

SSH agent restriction (ssh-add -h) looks promising, but support isn't widespread and it doesn't cover all use cases.

The article assumes a remote attacker, but the attacker can more easily be your boss or team. Keep this in mind whenever you forward your agent and plan accordingly.

This article helped me evolve my understanding of the impact of the recent openssh vuln, CVE-2023-38408. Gaining RCE on the source system is more valuable if you consider that the vulnerable machine is likely using ssh-agent to connect to other hosts, which makes pivoting potentially much easier.

This article was much, much longer than it needed to be

Good find! I was always curious how this worked.

I'm a big fan of tools like secretive[1] that can help solve this problem by using biometrics to shift the UX/security trade-off and thus make it feasible to always require some kind of authentication to sign a token with a key.

I'm not aware of any tools that do the same for Linux, and a quick Google search doesn't turn up much[2]. It does look like you can at least get a notification[3], though.

This could provide another layer of protection on the user's endpoint device in addition the network monitoring called out in the article. Defense in depth, and all that.

[1] https://github.com/maxgoedjen/secretive

[2] https://unix.stackexchange.com/questions/705144/unlock-an-ss...

[3] https://www.insecure.ws/2013/09/25/ssh-agent-notification.ht...

Just don't use SSH keys at all. Anywhere.

https://substack.com/@rakkhi/note/c-40163543?r=1afqp

That's shortsighted. Why not go all the way and just stop using computers altogether?

Huh? So what should we use to e.g. SSH to a server to debug a crashed or hanging process, login to a dev instance etc.?

SSH keys are also not “just long passwords” at all.

Not using SSH to configure a machine is smart, but saying no SSH at all is not feasible for many things. When something goes wrong, you need to be able to connect to a running machine and poke around, and you don’t know how you will need to poke until you are doing it.

The statement "SSH keys are just long passwords" in your linked post is a huge red flag that you don't understand enough about how they work and are in no position to dispense advice (that anyone sane should heed) on the subject.

To start (but it would be a longer discussion), passwords can be captured as you type them into a compromised host, SSH keys can't. Also SSH keys can reside on a security device (TPM, smartcard, HSM, security token, whatever) and this way they can _never_ be captured, barring exploits on those hardware devices, even if your workstation is compromised. Some hardware security devices have features like touch-to-authorize, or even biometrics, for every single usage. SSH keys can be _used_ while unlocked, but not from a compromised remote site (unless you do agent forwarding, which this article is all about), and never captured from there. Passwords have literally _none_ of the above features.

Forwarding usually bad. SSH Keys otherwise good. Passwords so bad they're not worth comparing to anything.

(and yeah, there's stuff even better than SSH keys)

Agent confirmations don’t need local authentication really; local confirmation is what’s important here.

Hijack my ssh-agent but you're not using my ssh key for lateral movement unless I touch my Yubikey for you.

And I'll notice when it's blinking but it shouldn't be and just unplug it :)

He lost me at "ssh root@machine".

Just no.

Reply on news.ycombinator.com