OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: ssh-feature 'backdoor'
From: Harold Gutch (logixfoobar.franken.de)
Date: Thu Feb 03 2000 - 17:06:37 CST

On Thu, Jan 20, 2000 at 04:03:25PM +0900, sen_mleccosys.com wrote:
>
> > 'being sure' is a bit strong don't you think? if someone has spoofed the
> > ip address it doesn't help you at all.
>
> logix> You want to do a blind-spoof on a cryptographic key-exchange?
>
> not necessarily. if you perform a successful denial-of-service attack
> of a certain type on one of your allowed hosts, and you know a
> password to get in to the server running the ssh daemon, then you can
> manage i think.

I haven't double-checked this, but AFAIK the client and the
server first exchange keys valid for this session (connection).
Only the server knows its private key and only the client knows
its private key - both (and anybody in the middle sniffing this)
know the other side's public key.
To be able to pass the authorization information of whatever kind
(be this a plaintext password, the public half of an RSA-keypair
or whatever), you would first need this public key, which you
simply don't have.

Hrm... having just thought of this a little more, I wonder...

Doesn't sshd update it's key-pair (create a new one) only at
startup plus once per hour? If you run sshd from inetd, it will
be created every time somebody logs in, if you run it standalone,
a new key-pair will only be created once per hour (using the
default-values).
Now, if somebody just _connects_ to the machine without actually
logging in, this somebody will still get the current public key,
which then later on can be used to login on a blind-spoofed
"connection".
To be able to succeed in a larger attack without leaving too much
evidence, he would have to
a) connect without leaving his IP-adress in some logfile (which
   might even be on another machine)
b) know a user's password/have a user's private RSA-key for which
   a public RSA-key exists on the machine he is connecting to
c) blind-spoof a connection to this machine, which is not
   trivial, since he will have to "guess" the sequence-number for
   this connection
d) gain root-privileges (again blindly - this would have to be
   planned exactly in advance)
e) do the same as he does every night - take over the world!

I ommitted the part where the "allowed" machine would be knocked
out of action, since that probably is the easier than any of the
other steps mentioned above.

"This vulnerability is completely theoretical" - uh, sure, but it
kinda is there. Or does sshd in fact _not_ send the same public
key over the wire, but rather some modified version of it?
Time to play around with this; if nobody with good insight in
this topic tells me more, then I'll try to find out more this
weekend.

bye,
  Harold 

-- 
Someone should do a study to find out how many human life spans have
been lost waiting for NT to reboot.
              Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message