Re: SSH2 Exploit?

["Jon Zobrist" <kgb () ussr com>]

Wouldn't this count as an SSHD1 remote exploit?

http://www.ciac.org/ciac/techbull/CIACTech02-001.shtml

Jon Zobrist, CISSP



----- Original Message -----
From: "Ron DuFresne" <dufresne () winternet com>
To: "Teodor Cimpoesu" <teo () gecadsoftware com>
Cc: <vuln-dev () securityfocus com>
Sent: Wednesday, February 27, 2002 7:10 PM
Subject: Re: SSH2 Exploit?


> 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.