openssh unix dev - Jun 2010 - Compromised servers, SSH keys, and replay attacks

We had an incident recently where an openssh client and server were 
replaced with trojanned versions (it has SKYNET ASCII-art in the binary, 
if anyone's seen it. Anyone seen the source code ?). The trojan ssh & 
sshd both logged host/user/password, and probably had a login backdoor.

Someone asked me what was their exposure if they used public/private keys 
instead of passwords.

My suspicion is, for this particular trojan, zero.
But in general, I wondered what credentials could possibly be exposed to 
a modified SSH client or server.

I imagine, if the client is modified it could capture passphrases, and 
the private key (which could be in any case read from 
the filesystem of a rooted box), in addition to I/O on the user terminal.

If a server is modified, I'm not so sure. I don't believe it could
access
the passphrase which should never leave the client. I presume it could 
capture the public key, which could be read from the filesystem anyway.
And I presume it could capture traffic to/from the virtual terminal.

Is there any way for an attacker to replay authentication to a third 
machine, accessed via the compromised machine using ssh-agent ?

If a user connects to a compromised machine using keys, but from an 
untainted client, do they need to change their keys or passphrase ?

(I presume, in principle, that an attacker could steal private user keys 
and machine keys from a rooted server, then subvert the DNS and entice 
users to login to their own server instead. Though I'm not sure why 
they'd want to do that having got server root. Bypass a firewall, maybe.)

-- 
Andrew Daviel, TRIUMF, Canada

On Thu, 24 Jun 2010, Andrew Daviel wrote:
>
> We had an incident recently where an openssh client and server were
> replaced with trojanned versions (it has SKYNET ASCII-art in the
> binary, if anyone's seen it. Anyone seen the source code ?). The
> trojan ssh & sshd both logged host/user/password, and probably had a
> login backdoor.
>
> Someone asked me what was their exposure if they used public/private
> keys instead of passwords.
>
> My suspicion is, for this particular trojan, zero. But in general, I
> wondered what credentials could possibly be exposed to a modified SSH
> client or server.
>
> I imagine, if the client is modified it could capture passphrases, and
> the private key (which could be in any case read from the filesystem
> of a rooted box), in addition to I/O on the user terminal.
Correct.
> If a server is modified, I'm not so sure. I don't believe it could
> access the passphrase which should never leave the client. I presume
> it could capture the public key, which could be read from the
> filesystem anyway. And I presume it could capture traffic to/from the
> virtual terminal.
Correct. The passphrase and private key never leave the client. A
trojaned server could however silently accept authentication and then
try to phish a users for their private key passphrase by presenting a
fake "enter passphrase prompt".
> Is there any way for an attacker to replay authentication to a third
> machine, accessed via the compromised machine using ssh-agent ?
In SSHv2 it should be cryptographically impossible for a server to reply
a public key authentication to another server. In SSHv1 the guarantees
are quite a bit weaker, and it is probably possible for a hostile server
to replay authentication to another server *if* is has a copy of the
victim server's private host key.
> If a user connects to a compromised machine using keys, but from an
> untainted client, do they need to change their keys or passphrase ?
The big worry is whether the user has forwarded an agent to the
compromised server. If they have, then any host that trusts a key in
that agent may have been compromised too. Note that the attacker would
not have access the the private keys themselves (unless they broke into
the host where the agent is running or the private keys are stored), but
they would be able to use the keys in the agent for authentication. This
is why I like the "require confirmation" option for ssh-add.

If not, then changing their passphrase would probably be sufficient
prudence given the above phishing attack.
> (I presume, in principle, that an attacker could steal private user
> keys and machine keys from a rooted server, then subvert the DNS and
> entice users to login to their own server instead. Though I'm not sure
> why they'd want to do that having got server root. Bypass a firewall,
> maybe.)
They could create a server that accepts passwordless authentication and
then issues a password prompt to try and phish your password or private
key passphrase. Owning a server that users will connect to also exposes
any client-side bugs in ssh.

-d