Date: Sat, 2 Jun 2001 08:58:33 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Kris Kennaway <kris@obsecurity.org> Cc: "Karsten W. Rohrbach" <karsten@rohrbach.de>, Crist Clark <crist.clark@globalstar.com>, security@FreeBSD.org Subject: Re: Apache Software Foundation Server compromised, resecured. (fwd) Message-ID: <Pine.NEB.3.96L.1010602083607.65702I-100000@fledge.watson.org> In-Reply-To: <20010601143755.B88206@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Jun 2001, Kris Kennaway wrote: > On Fri, Jun 01, 2001 at 04:19:51PM +0200, Karsten W. Rohrbach wrote: > > Kris Kennaway(kris@obsecurity.org)@2001.05.31 19:35:55 +0000: > > > On Thu, May 31, 2001 at 07:25:22PM -0700, Crist Clark wrote: > > > > > > > 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. > > > > > > Okay, I'm willing to admit I could be wrong about the mechanism, but > > > the trust relationship still exists. The ssh-agent authenticates on > > > demand, so as long as you're connected to the untrusted system it can > > > authenticate as you to other systems without your permission. > > this does not lead to a big tragedy since the agent protocol is > > challenge-response. > > Yes, but it's done on demand with no auditing. A particularly entertaining scenario is the following one: user has a private key on host A and C (where they frequently log in directly using a password), and the paired public key on hosts A, B, C, and D, all in different trust domains. The user logs into A, and sets up their ssh-agent with the private key. The attacker compromises B, trojaning its ssh daemon. The user logs into B from A with agent forwarding enabled, and the attacker uses access to the agent to build authenticated connections to A, B, C, and D. The agent uses debugger access on A to compromise the running ssh-agent and get access to the keying material for the RSA/DSA private key, or trojans the ssh-agent (either for that user by manipulating the execution environment, or for the system if privilege is escalated by modifying/replacing the binary, reordering the path, etc). Note also that in a multiple-key scenario, the SSH client provides no way to selectively forward keys to hosts, or express policy regarding whether keys are then forwarded by the host you have connected to. Note that X11 forwarding has similar compromise properties, only it provides an even more direct path to the user's keying material. The moral of the story, as has been pointed out a number of times, is that unless you are willing to place substantial trust in the host you're logging into, you should not forward either X11 or SSH to that host. And from the perspective of host administrators, it may be that your host is substantially at risk if a user uses the same private key to access other hosts than your own host, using the default configuration for many SSH clients (agent forwarding enabled). In fact, forcing the user to use one-time passwords on a handheld device combined with SSH as a secure host transport may provide the best protection from the perspective of a host administrator. SSH can provide a notable improvement over unencrypted communications in many situations. But in some compromise situations, it can actually make things much worse by providing access to hosts that previously would be unaffected by the compromise, as it encourages the use of automatic and shared authentication. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010602083607.65702I-100000>