5 ms·

This sounds way worse than it is. To be clear, the "remote" part of the code execution is that an attacker controlling your destination server can cause your c

This sounds way worse than it is. To be clear, the "remote" part of the code execution is that an attacker controlling your destination server can cause your client to run an attacker-controlled payload, if the client is forwarding their credentials (`ssh -A`). Most people don't tend to make connections to arbitrary SSH hosts, and certainly they don't do it while forwarding their credentials along. It's a neat attack, and I applaud the Qualys team on their find, but this is not any sort of emergency situation for 99.99% of systems.

malux85 3y ago
Yeah if I’m reading the technical analysis right, your conditions that you mention have to be correct and also the attacker must have “poisoned” library files on the targets machine so they can dlopen them, is that right? Pretty unlikely
- sullivanmatt 3y ago
  There must be a specific set of libs present on the victim (client), correct. Qualys claims that stock Ubuntu Desktop systems often have these libs, and that they haven't looked into whether other distros tend to. But yes, your point stands. Huge number of preconditions here to fulfill.
- Arnavion 3y ago
  The libraries are on the client's machine, not the server's. And they're not "poisoned"; the default distro-provided libs already provide the remote execution capabiity (eclipse-titan, libkf5sonnetui5, libns3-3v5 and systemd-boot packages from Ubuntu 22.04).
  - malux85 3y ago
    Ahh I see I thought the attacker also had to have custom malicious libs deployed on the client machine I wasn't sure if standard ones would do, thanks for clarifying that
e28eta 3y ago
I don’t know how prevalent it is as a network architecture, but it seems like a bastion host / jump box would be a juicy target for this exploit, since it’d let the attacker jump upstream.
- jmalicki 3y ago
  Sure, but first they have to root the bastion box. If you root the bastion box, you have user credentials for anything inside the network. Controlling the user's laptop seems unlikely to be your most profitable next step.
  - yjftsjthsd-h 3y ago
    It really depends on the setup; ex. I imagine it's easier to steal company code from a laptop than server, while data is the other way around.
  - gunapologist99 3y ago
    > If you root the bastion box, you have user credentials for anything inside the network. But that's not how a (properly-configured!) bastion host works. You won't have user credentials for anything UNLESS users are using Forward Agent (which they shouldn't! simplest explanation here.. https://userify.com/docs/jumpbox https://userify.com/docs/jumpbox ). That's the point behind using ProxyJump. Your connection actually jumps THROUGH the bastion box and doesn't stop for interception along the way. (And, of course, an attacker can't do anything very useful with ssh public keys except for maybe traffic analysis or learning more target IP's.)
- akerl_ 3y ago
  Increasingly, the role of a bastion host is served either by something like Teleport, which handles authn/z and proxying without needing forwarded agents, or newer options in OpenSSH like ProxyJump where you hop via a bastion host but without ever forwarding your agent.
TechBro8615 3y ago
The attacker controlled destination server could be a compromised host, so this enables lateral movement from a deployed VM or remote dev machine into a developer laptop.
justsomeadvice0 3y ago
Lots of people end up with AgentForward on by default as a sort of "make it work" fix, and lots of people use `git+ssh` on untrusted servers. Here's an example: https://abyssdomain.expert/@filippo/109659699817863532 https://abyssdomain.expert/@filippo/109659699817863532 TBF this is a vulnerable config either way; but RCE on the client shouldn't be possible.
- tinus_hn 3y ago
  I’m not so sure git is secure against a malicious server, even if you’re not simply pulling in a Makefile written by the attacker.
  - themoonisachees 3y ago
    Assuming you do perfect integrity checks of the git repo you're pulling, git uses SSH and obeys ssh config for each hosts under the hood. It's safe to say that if you have forward-agent enabled git is vulnerable.
- doubled112 3y ago
  I've been using a separate SSH config for git for a long time now. Nice to see it wasn't just paranoia. Among the settings are explicitly disabling agent forwarding, and using a git specific identity (SSH key).
gunapologist99 3y ago
Aren't all SSH hosts potentially attacker-controlled? ;)
- nocsi 3y ago
  Yea, but there’s a security boundary wherein you don’t want the SSH host to be executing code in your environment. Of course, the attackers can backdoor sshd to log credentials, setup init scripts on the host to execute code every client login and other shenanigans.
  - gunapologist99 3y ago
    Of course. So it's not really that out of the question if you are using agent forwarding, so, yeah, this is a big deal.
gunapologist99 3y ago
I beg to differ: this does not sound way worse than it is. If anything, it's understating the issue. Not only can it be exploited across a wide variety of clients across multiple platforms, but all that's required is that you're using key forwarding. This is devastating, because it's not just that you control the destination server and steal the keys, but you can take over the user's entire workstation. Once you've got the user's entire workstation, you potentially have access to everything else they have, from their email, to other SSH hosts, to key loggers, to Git repos. This is about as bad as it gets, and all because someone is using Agent Forwarding. Best of all, the victim has no idea that they've been completely compromised. They can live inside your machine for years, upgrade their sploits, and generally exfiltrate all of your secrets. Never use agent forwarding. Just don't. "Agent forwarding should be enabled with caution" in the man page is another massive understatement. Even if you think you need it, check the other responses in this thread for examples of how to work around it.
- dumpsterdiver 3y ago
  > Never use agent forwarding Agreed. As this exploit proves, it's not even safe to log into your own servers using ssh forwarding if any service is exposed remotely, because if an attacker compromises that exposed service and gains root then they could extend the attack to your workstation, and that's a huge deal - especially considering that you have the private key to log into that server on your computer (so it's not an unsafe bet there might be other keys).
  - gunapologist99 3y ago
    Exactly - agent forwarding is the laziest and fastest path to getting severely pwned, but the irony is that the alternatives are actually fairly simple and fast, if someone is willing to take the time to adjust their process a little bit.
    - pritambaral 3y ago
      > agent forwarding is the laziest and fastest path to getting severely pwned Only for people who don't know what they are doing. Usually, such people also make poor replacement decisions that are even less secure. > the alternatives are actually fairly simple and fast, if someone is willing to take the time to adjust their process a little bit. I often need to work on code in ephemeral containers. Is there an "actually fairly simple and fast" method I can use to be able git pull and push to and from these ephemeral containers that: 1. doesn't require too much adjustment (a little bit is okay); and 2. is not less secure than agent forwarding with confirmation?
ivlad 3y ago
“git pull” over SSH and have your system RCEd? I’d say it levels above “neat”.
- franga2000 3y ago
  You'd need to go out of your way to make git pull do agent forwarding and I can't really think of a reason why anyone would.
paulmd 3y ago
Are you saying that if you SFTP in to a client machine to upload a file to their server, it’s expected behavior that you’re willing to give them root on your machine?

malux85 3y ago

Yeah if I’m reading the technical analysis right, your conditions that you mention have to be correct and also the attacker must have “poisoned” library files on the targets machine so they can dlopen them, is that right? Pretty unlikely

sullivanmatt 3y ago
There must be a specific set of libs present on the victim (client), correct. Qualys claims that stock Ubuntu Desktop systems often have these libs, and that they haven't looked into whether other distros tend to. But yes, your point stands. Huge number of preconditions here to fulfill.
Arnavion 3y ago
The libraries are on the client's machine, not the server's. And they're not "poisoned"; the default distro-provided libs already provide the remote execution capabiity (eclipse-titan, libkf5sonnetui5, libns3-3v5 and systemd-boot packages from Ubuntu 22.04).
- malux85 3y ago
  Ahh I see I thought the attacker also had to have custom malicious libs deployed on the client machine I wasn't sure if standard ones would do, thanks for clarifying that

e28eta 3y ago

I don’t know how prevalent it is as a network architecture, but it seems like a bastion host / jump box would be a juicy target for this exploit, since it’d let the attacker jump upstream.

jmalicki 3y ago
Sure, but first they have to root the bastion box. If you root the bastion box, you have user credentials for anything inside the network. Controlling the user's laptop seems unlikely to be your most profitable next step.
- yjftsjthsd-h 3y ago
  It really depends on the setup; ex. I imagine it's easier to steal company code from a laptop than server, while data is the other way around.
- gunapologist99 3y ago
  > If you root the bastion box, you have user credentials for anything inside the network. But that's not how a (properly-configured!) bastion host works. You won't have user credentials for anything UNLESS users are using Forward Agent (which they shouldn't! simplest explanation here.. https://userify.com/docs/jumpbox https://userify.com/docs/jumpbox ). That's the point behind using ProxyJump. Your connection actually jumps THROUGH the bastion box and doesn't stop for interception along the way. (And, of course, an attacker can't do anything very useful with ssh public keys except for maybe traffic analysis or learning more target IP's.)
akerl_ 3y ago
Increasingly, the role of a bastion host is served either by something like Teleport, which handles authn/z and proxying without needing forwarded agents, or newer options in OpenSSH like ProxyJump where you hop via a bastion host but without ever forwarding your agent.

TechBro8615 3y ago

The attacker controlled destination server could be a compromised host, so this enables lateral movement from a deployed VM or remote dev machine into a developer laptop.

justsomeadvice0 3y ago

Lots of people end up with AgentForward on by default as a sort of "make it work" fix, and lots of people use `git+ssh` on untrusted servers. Here's an example: https://abyssdomain.expert/@filippo/109659699817863532 https://abyssdomain.expert/@filippo/109659699817863532 TBF this is a vulnerable config either way; but RCE on the client shouldn't be possible.

tinus_hn 3y ago
I’m not so sure git is secure against a malicious server, even if you’re not simply pulling in a Makefile written by the attacker.
- themoonisachees 3y ago
  Assuming you do perfect integrity checks of the git repo you're pulling, git uses SSH and obeys ssh config for each hosts under the hood. It's safe to say that if you have forward-agent enabled git is vulnerable.
doubled112 3y ago
I've been using a separate SSH config for git for a long time now. Nice to see it wasn't just paranoia. Among the settings are explicitly disabling agent forwarding, and using a git specific identity (SSH key).

gunapologist99 3y ago

Aren't all SSH hosts potentially attacker-controlled? ;)

nocsi 3y ago
Yea, but there’s a security boundary wherein you don’t want the SSH host to be executing code in your environment. Of course, the attackers can backdoor sshd to log credentials, setup init scripts on the host to execute code every client login and other shenanigans.
- gunapologist99 3y ago
  Of course. So it's not really that out of the question if you are using agent forwarding, so, yeah, this is a big deal.

gunapologist99 3y ago

I beg to differ: this does not sound way worse than it is. If anything, it's understating the issue. Not only can it be exploited across a wide variety of clients across multiple platforms, but all that's required is that you're using key forwarding. This is devastating, because it's not just that you control the destination server and steal the keys, but you can take over the user's entire workstation. Once you've got the user's entire workstation, you potentially have access to everything else they have, from their email, to other SSH hosts, to key loggers, to Git repos. This is about as bad as it gets, and all because someone is using Agent Forwarding. Best of all, the victim has no idea that they've been completely compromised. They can live inside your machine for years, upgrade their sploits, and generally exfiltrate all of your secrets. Never use agent forwarding. Just don't. "Agent forwarding should be enabled with caution" in the man page is another massive understatement. Even if you think you need it, check the other responses in this thread for examples of how to work around it.

dumpsterdiver 3y ago
> Never use agent forwarding Agreed. As this exploit proves, it's not even safe to log into your own servers using ssh forwarding if any service is exposed remotely, because if an attacker compromises that exposed service and gains root then they could extend the attack to your workstation, and that's a huge deal - especially considering that you have the private key to log into that server on your computer (so it's not an unsafe bet there might be other keys).
- gunapologist99 3y ago
  Exactly - agent forwarding is the laziest and fastest path to getting severely pwned, but the irony is that the alternatives are actually fairly simple and fast, if someone is willing to take the time to adjust their process a little bit.
  - pritambaral 3y ago
    > agent forwarding is the laziest and fastest path to getting severely pwned Only for people who don't know what they are doing. Usually, such people also make poor replacement decisions that are even less secure. > the alternatives are actually fairly simple and fast, if someone is willing to take the time to adjust their process a little bit. I often need to work on code in ephemeral containers. Is there an "actually fairly simple and fast" method I can use to be able git pull and push to and from these ephemeral containers that: 1. doesn't require too much adjustment (a little bit is okay); and 2. is not less secure than agent forwarding with confirmation?

ivlad 3y ago

“git pull” over SSH and have your system RCEd? I’d say it levels above “neat”.

franga2000 3y ago
You'd need to go out of your way to make git pull do agent forwarding and I can't really think of a reason why anyone would.

paulmd 3y ago

Are you saying that if you SFTP in to a client machine to upload a file to their server, it’s expected behavior that you’re willing to give them root on your machine?