Re: SSH2 Exploit?

[Ron DuFresne <dufresne () winternet com>]

Please allow me to correct my statements below and modify them to fit the
facts:

There is and has been a working exploit on ssh1 for awhile, shortly after
hitting the send on this, I reviewed my library of ssh related
announcements from various sources and did see the CERT annoucemnt of the
crc32 attack against ssh1, as well as re-reviewed the analysis done by
Dave Dittrich of the binaries used in this exploit.  Yet, it seems to
still be the case that only ssh1 in vulnerable, and only ssh2 if it's
configured to fallback to ssh1 for compatability to the older protocol.
Enough reason to finally get folks to move fully to the ssh2 protocol and
let ssh1 rest in peace.  The only alternative for those sites requiring
ssh1 fallback is to limit connections to only those machines that they
trust and can't for any reason upgrade to a current ssh2 client.  Windows
users should be made aware that there are free and/or inexpensive ssh2
clients for those systems, so there should really be few if any reasons
for mitigating circumstances requiring  ssh1 to remain in place.

Though this might be slightly off-topic for this list, folks should be
taking a stance both, for protocols like ssh and others, coming into their
networks as well as going out, of dramatically limiting "any any rules".
If for no other reason then self protection of the resources they are
charged to protect as well as to be decent netciizens and help fight the
battle against trojans debilitating so many networks with each
introduction of  new code.  Fred Avolio's recent NetSec Letter #17, 5
March 2002, The Nefarious "Any"
http://www.avolio.com/columns/17-TheNefariousAny.html  Certainly covers
this better then I'm doing here, read it.

Anyways to avoid the confusion that I'm here trying to correct and
appologise for, re-read me below and sicard the references to ssh1 as
being exploit free.

Thanks,

Ron DuFresne

On Wed, 27 Feb 2002, Ron DuFresne wrote:

> There's nothing here that actually suggests the systems were compromised
> via sshd, neither sshd1 nor sshd2.  Nor is there an actual accounting of
> what other services were open for possible exploit on the systems in
> question.  Nothing about the kernels chosen and possible problems there,
> nor if the systems were acutally remotely exploited of if <as is much more
> possible> that an internal user on the systems actually rooted the
> systems.  I have seen code to scan for sshd1, seen the traces in my logs,
> and there have been hints of possible sshd1 exploit code ciculating for
> awhile now, with no real evicdence presented there is such an exploit in
> use that works remotely.  Those exploits of sshd1 that have been suggested
> are far above the needs and skills of simple skript-kiddies though.  SSHD2
> that I've seen vulnerabilites mentioned for though are those that include
> sshd1 support, so, if there is real evidence of an sshd2 remote exploit or
> even a remote sshd1 exploit in acutal use, then, I'd certainly like to see
> the code or binaries in question.  Otherwie, we only have rumrrs of such
> and most likely have systems hacked via other vectors that are used to
> scan for possibly exploitable sshd's, and these scans are possibly placed
> for scare tactics or diversion from the real purpose of the rooting that
> has taken place.
>
> Thanks,
>
> Ron DuFresne
>
> On Tue, 26 Feb 2002, Teodor Cimpoesu wrote:
>
> > Hi John!
> > On Tue, 26 Feb 2002, John Compton wrote:
> >
> > > Hi,
> > >
> > > I recently had a break-in on a redhat linux system.  The attacker installed
> > > what appears to be torn kit, but there was one thing which caught my
> > > attention. I found a binary named "sshex" on the compromised system.  I
> > > guess this is the exploit used to break in cause most of the servers here
> > > are kept up-to-date.  The system was being used to actively scan for ssh
> > > servers.
> > >
> > > [root@testbox ]# ./sshex
> > >
> > > 7350ylonen - x86 ssh2 <= 3.1.0 exploit
> > > dream team teso
> > > usage: 7350ylonen [-hd] <-p port> <-t target> <-d packet_delay> host
> > >
> > > RH 7.x - SSH-2.0-3.x SSH Secure Shell
> > > RH 7.x - SSH-2.0-2.x SSH Secure Shell
> > > RH 6.x - SSH-2.0-2.x SSH Secure Shell
> > > Slack 8.0 - SSH-2.0-3.x SSH Secure Shell
> > > SuSE-7.3 - SSH-2.0-3.x SSH Secure Shell
> > > FreeBSD 4.3 - SSH-2.0-3.x SSH Secure Shell
> > > FreeBSD 4.3 - SSH-2.0-2.x SSH Secure Shell
> > >
> > > It tries to connect to port 22 when I target localhost, but I can't tell if
> > > sshd is crashing or not as I can't use gdb to attach to the process in time.
> > >
> > >  The only SSH vulnerabilities I could find affected SSH1 servers, or
> > > OpenSSH.  Has anyone else found this exploit on their systems or know
> > > something about it?
> > Yep, it's t0rn, least from other post incident notes I read.
> >
> > I recently cleaned-up a compromised Slackware (7.1, with vulnerable ssh).
> >
> > The version I found installed the following files:
> >  in /usr/src/.lib/
> >     .1addr .1file .1proc dir find ifconfig install ls netstat ps pstree
> >     secure.cgi (as backdoor?) syslogd top.
> >     The replacement binaries were retrieved from:
> >     http://212.66.231.20/arabela/prometeu.tar.gz. The script that
> >     downloaded them stats with the banner:
> >                      Additional file for lite5-r lrk.
> >
> >  in /usr/src/linux/.lib
> >     cleaner create crontd exit ilussion vanish
> >     i,ssh_host_key,ssh_random_seed and sshd3 (altered ssh to listen on 33225.
> >     backup/
> >             backup of drop in replacements for system commands listed above.
> >
> >  /usr/bin/twist2open
> >     a script which was called on boot time from (modified) rc.sysinit and
> >     which uses some files in /usr/lib/locale/ro_RO/uboot/
> >
> >  /usr/lib/locale/ro_RO/uboot/
> >     lots of stuff, among other things kernel modules to hide presence and
> >     avoid killing malicious programs that were installed (my opinion after a
> >     glance over code). It may sound familiar to you adore.c, ava.c
> >     Also log sweepers, password sniffers.
> >
> >  The intruder was a truly script-kiddie in that it didn't used the log
> >  cleaners at the second and next logins and also left all the files in the
> >  system and we were able to clean the system (though I suggested a fresh
> >  installation, which finally happened).
> >
> >  Besides, I don't know if another utility, a login password sniffer, was part
> >  of this kit or installed later. It replaced /bin/login with
> >     usr/local/man/man1/login.man, which communicates with a nscd daemon (of
> >     course, compromised too) and collects login password.
> >
> > If interested on doing a more in depth analysis of this files please send a
> > signed message along with your public key at teodor () cimpoesu ro.
> >
> > -- teodor
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Cutting the space budget really restores my faith in humanity.  It
> eliminates dreams, goals, and ideals and lets us get straight to the
> business of hate, debauchery, and self-annihilation." -- Johnny Hart
>       ***testing, only testing, and damn good at it too!***
>
> OK, so you're a Ph.D.  Just don't touch anything.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
        ***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.