Re: [cobalt-users] New Exploit?

["Oliver Schlag" <cjcs@xxxxxxxx>]

Hy Paul,

we were hacked two times by this hack. Jonothon Ortiz has taken a look at the kit with what we've been hacked. Here are some of the infos he send me about the rootkit we had installed and some infos about what i've found out :

There is a .tgz file in /tmp with the complete rootkit and all files are installed in /usr/local/man/mann/.brm

The following files are possibly infected/created :
/sbin/insmod
/sbin/rmmod
/usr/share/terminfo/1/.1
/init
/brmrc
/sh

There is a cronjob created which will start /sbin/rmmod -as every 10 minutes.

There is a high possibility that there are some users created on your system :

user / password (md5) / password (clear)

trk2 / SDaVtiyNMzUYs / fucked
brmbrm / SD5FxnRnzpCs

Another possible thing is that there's a new group running with an ID of 34 and named TRK_GID.

This hack was installed via an violated SSH / Telnet or RLogin. If you find a file called trk2.c this fill will attempt to play with your kernel. You've got a struct for stolen SSH passwords floating around there named ssh. Another thing is, that if you try to reboot your box, it perhaps will fail to boot while trying to free the unused kernel memory.

Try to search for the files trk2.o, cleaner.o, cleaner, theese are from the rootkit. You should backup all your data and make a complete restore of the box and then disable telnet, perhaps a CVS server running on the box and get the latest version of ssh, from http://pkg.nl.cobalt.com or a newer version from http://www.openssh.org.

Another thing i've found out is that many commands on the shell will die with an seg fault.

I've found a file called KiNgpiN3 in /usr/local/man/mann/.brm which seems to be a IRC Client. This looks into a channel of an IRC Server and it seems that this client waits for the start command for a DDOS Attack.... Check your output of ps -auxwf for weird processes.

Thanks again for this informations to Jonothon Ortiz :o)

Greetings
Oliver




---------- Original Message ----------------------------------
From: "Paul Harvey" <paul@xxxxxxxxxxxxx>
Reply-To: cobalt-users@xxxxxxxxxxxxxxx
Date: Tue, 11 Dec 2001 07:25:17 -0000

>I got hacked using the exploit below.  Are Cobalts supposed to be
>protected against this?
>
>I use SSH2 and have patches in place.  They seem to have got into root via
>one of our users.
>
>Does anyone know what version of Linux is used on the Raq4?
>
>
>----------------------------------------------
>/*
>* epcs2 (improved by lst [liquid@xxxxxxx])
>* ~~~~~~~
>* exploit for execve/ptrace race condition in Linux kernel up to 2.2.18
>*
>* originally by:
>* (c) 2001 Wojciech Purczynski / cliph / <wp@xxxxxxxxxxxx>
>*
>* improved by:
>* lst [liquid@xxxxxxx]
>*
>* This sploit does _not_ use brute force. It does not need that.
>* It does only one attemt to sploit the race condition in execve.
>* Parent process waits for a context-switch that occur after
>* child task sleep in execve.
>*
>* It should work even on openwall-patched kernels (I haven't tested it).
>*
>* Compile it:
>* cc epcs.c -o epcs
>* Usage:
>* ./epcs [victim]
>*
>* It gives instant root shell with any of a suid binaries.
>*
>* If it does not work, try use some methods to ensure that execve
>* would sleep while loading binary file into memory,
>*
>* i.e.: cat /usr/lib/* >/dev/null 2>&1
>*
>* Tested on RH 7.0 and RH 6.2 / 2.2.14 / 2.2.18 / 2.2.18ow4
>* This exploit does not work on 2.4.x because kernel won't set suid
>* privileges if user ptraces a binary.
>* But it is still exploitable on these kernels.
>*
>* Thanks to Bulba (he made me to take a look at this bug ;) )
>* Greetings to SigSegv team.
>*
>* -- d00t
>* improved by lst [liquid@xxxxxxx]
>* props to kevin for most of the work
>*
>* now works on stack non-exec systems with some neat trickery for the
>automated
>* method, ie. no need to find the bss segment via objdump
>*
>* particularly it now rewrites the code instruction sets in the
>* dynamic linker _start segment and continues execution from there.
>*
>* an aside, due to the fact that the code self-modified, it wouldnt work
>* quite correctly on a stack non-exec system without playing directly with
>* the bss segment (ie no regs.eip = regs.esp change). this is much more
>* automated. however, do note that the previous version did not trigger
>stack
>* non-exec warnings due to how it was operating. note that the regs.eip =
>regs.esp
>* method will break on stack non-exec systems.
>*
>* as always.. enjoy.
>*
>*/
>
>
>----------------------------------------------------------------------------
>---
>
>
>
>_______________________________________________
>cobalt-users mailing list
>cobalt-users@xxxxxxxxxxxxxxx
>To Subscribe or Unsubscribe, please go to:
>http://list.cobalt.com/mailman/listinfo/cobalt-users
>