Re: Apache Software Foundation Server compromised, resecured. (fwd)

From: Crist Clark (crist.clark@globalstar.com)
Date: 06/01/01


Date: Thu, 31 May 2001 19:25:22 -0700
From: "Crist Clark" <crist.clark@globalstar.com>
To: Kris Kennaway <kris@obsecurity.org>

Kris Kennaway wrote:
>
> On Thu, May 31, 2001 at 06:49:06PM -0700, Crist Clark wrote:
> > Kris Kennaway wrote:
> > >
> > > On Thu, May 31, 2001 at 05:54:49PM -0700, Crist Clark wrote:
> > >
> > > > *sigh*
> > > >
> > > > You cannot 'record passphrases.' RSA authentication uses public key
> > > > cryptography. The client, the person logging in, proves it knows a
> > > > secret, the private key, without ever revealing it to the server who
> > > > only knows the public key.
> > >
> > > The ssh client on the sourceforge machine was trojaned;
> >
> > A lot of people SSH _out_ of the sourceforge machine(s)? And they do
> > so by typing a passphrase on that machine as opposed to agent forwarding?
>
> Apparently so.
>
> I believe agent forwarding still exposes the problem: it basically
> sets up a trust relationship with the remote system which allows
> processes running as you on the target machine to access the keys
> stored in the original ssh-agent on your source machine.
>
> i.e. in order to authenticate from the second machine to a third when
> agent forwarding is enabled from machine one to machine two, the
> second client requests a copy of your decrypted credentials which are
> stored in the ssh-agent on the first, and uses them as it pleases
> (ideally, only to authenticate -- once, and according to your
> directions -- with the third system).

According to the documentation, this is NOT how the agent forwarding
works. The second client passes data, typically a challenge, back to
machine one, where the agent does its thing with the private key
material, then passes the decrypted challenge information back to
machine two.

Have a look at all of the communications the agent does,

  SSH_AGENTC_REQUEST_RSA_IDENTITIES
  SSH_AGENT_RSA_IDENTITIES_ANSWER

These two are basically the output of 'ssh-add -l.' There is no confidential
data passed out of the agent,

  SSH_AGENTC_RSA_CHALLENGE
  SSH_AGENT_RSA_RESPONSE

These are the two that I think people are confused about. In your example,
Kris, machine two would take the challenge it got and pass it back to
the agent on machine one with as a SSH_AGENTC_RSA_CHALLENGE comm. The
agent would reply with a SSH_AGENT_RSA_RESPONSE. The private RSA key never
changes hands.

  SSH_AGENT_FAILURE
  SSH_AGENT_SUCCESS

If it does not understand something or when ACK's a comm and it does not
need to pass data back, respectively.

  SSH_AGENTC_ADD_RSA_IDENTITY
  SSH_AGENT_REMOVE_RSA_IDENTITY

How RSA identities are added to the agent. Note, there is no way to get it
back out. It only can be deleted.

And that's all.

> The moral of the story is to never initiate SSH connections from
> untrusted machines, no matter how you do it, because you expose your
> private credentials to that system

From how I read the docs, this is not true for agent forwarding.

-- 
Crist J. Clark                                Network Security Engineer
crist.clark@globalstar.com                    Globalstar, L.P.
(408) 933-4387                                FAX: (408) 933-4926
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.  If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited.  If you have received this
e-mail in error, please contact postmaster@globalstar.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message