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 teodorat_private > > -- 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.
This archive was generated by hypermail 2b30 : Mon Mar 04 2002 - 18:32:40 PST