Re: RedHat 6.2 box exploited - analysis of attacker activity

[Thomas Roessler <roessler () DOES-NOT-EXIST ORG>]

Some notes:

- It seems that you did your investigation directly on the attacked
  system. It's likely that you destroyed evidence (such as time
  stamps) doing so.  It would have been a much better idea to create
  images like this:

        dd if=/dev/hda8 bs=1024 | nc analysis.host whatever-port,

  where another instance of nc is run on the analysis host, so the
  data collected over the network can be written to disk.

- Try investigating unused disk space with the ils and icat tools
  from Wietse's and Dan's tct package (-> www.porcupine.org).  You
  may be able to recover deleted tar balls, source code, and lots of
  other interesting things.

- Try applying strings (1) to the disk images (or just to free
  blocks, recovered using unrm from the tct package), and peruse the
  output with less.  Use the pager's search function to look for
  things you may be interested in - file or user names encountered
  elsewhere on the system are often a good candidate. Another good
  candidate are patterns which look like the time stamps used by
  syslogd. Try this:
  
  strings < image-of-log-partition | egrep '^(Dec|Jan|Feb|)  ' | sort -u
  
  - you may quite well recover most of the lost log files this way.

- You may wish to investigate the sshd binary installed by the
  attacker for references to "strange file names".  There are trojan
  horse sshd binaries with backdoors and password logging
  facilities.  In particular, you may wish to look for strings which
  are 32 or 40 characters long (base64 encoded md5 or sha1 hashes in
  hex representation).

- On a RedHat box which is entirely under the control of the package
  manager (errm, and the intruder), you could have used rpm to
  validate the binaries installed on the system:

     rpm --root /where/the/images/are/mounted -q -V -a | grep ^5 

- If you have enough time, you could engage in further dumpster
  diving on unused blocks, using Lazarus from the tct package.

- I'd suggest you further emphasize that people should restrict the
  software they have on their system.  Don't install or run anything
  but the bare minimum needed to accomplish your goals.  If all you
  need is an ip filter, don't run ANY network services - and
  certainly don't run lpd, linuxconf, telnetd, ftpd, and similar
  things.

- Looking at the root kit config files you quote, this heavily looks
  like one of the standard lrk's.  You might wish to have a look at
  the source code of these packages if you are interested in the
  meaning of the individual lines.

> The group ID 1018 appears to have ran the rootkit.

Group ID?  What you are quoting in what follows looks like user ID
1018 unpacked the files, and root just copied them (or used the fix
program from the root kit the wrong way(?), or just unpacked some
tar ball which left these identities in place - actually, that looks
like the most likely variant to me, but then again, I could easily
be wrong).

> The system binaries that were replaced by this 
> activity are as follows:
>
> -rwxr-xr-x    1 1018     users       19840 Nov 25  
> 1998 /sbin/ifconfig
> -rwxr-xr-x    1 1018     users       33280 Dec 27  
> 1998 /bin/ps
> -rwxr-xr-x    1 1018     users       35300 Jan  2  
> 1999 /bin/netstat
> -rwxr-xr-x    1 1018     users       53588 Jan 12  
> 1999 /usr/bin/top
> -rwxr-xr-x    1 1018     users       13621 Dec 19 
> 10:14 /bin/vobiscu (unfamiliar)

Interesting...  Could you possibly make a copy of that one available
online?  ;-)

> The group ID 1004 created the following files of 
> interest:

From what do you conclude that group ID 1004 was involved here?

> [root@fortran /dev]# ls -al /dev/caca
> -rw-rw-r--    1 root     501           117 Jan 13 
> 21:01 /dev/caca

(Contents looks like a configuration file for lrk's netstat.)

> [root@fortran /netw3]# strings /dev/dsx | more
> 3 psybnc
> 3 wu-scan
> 3 muje
> 3 statdx
> 3 sl2
> 3 sshd2
> 3 linsniffer
> 3 smurf       
> 3 slice
> 3 mech
> 3 muh
> 3 bnc

> /dev/dsx appears to be a listing of what the attacker 
> has installed.

This looks like a configuration file for the root kit's ps and top
tools.  (Did you apply strings(1) to the root kit binaries, looking
for file names?)

> Lock down systems to provide “defense in depth”. Do 
> not simply rely upon ipchains to block hostile traffic. 
> Deny all traffic except  what is specifically allowed. 
> Comment out services in /etc/services that do not 
> need to be ran (finger, etc) as well as in /etc/rc.d. If 
> the FTP service will be used, make sure 
> that /etc/ftpusers only allows specific usernames.  If 
> attacker pierces firewall mechanism, limit what is 
> available by turning off everything that is not needed, 
> leaving only those services that are truly necessary. 

It's best to remove the packages containing "dangerous" services
completely.  That way, you won't re-enable them upon the next
package update.

Also, remember that ftpusers traditionally is a black list of users
_not_ permitted to ftp into the system.

> An intrusion detection system such as snort 
> (www.snort.org) is inexpensive, easy to configure, 
> and in wide use. Snort can monitor a network and 
> alert a network manager (with the proper 
> configuration) via pager or email that an attack is 
> taking place. Tripwire is a file integrity monitor that 
> can be used to take a snapshot of certain key system 
> files ( such as ps, netstat, ifconfig, and many more).

You may wish to additionally recommend occasional integrity checks
using rpm (8).

> When these key system files are changed, an alert 
> can be generated to notify that something suspicious 
> is taking place. There are freeware/GPL options for 
> SSH (openSSH) and a freeware tripwire clone 
> available on the Internet (see www.whitehats.com for 
> a large collection of open source security tools).
>
> Curt Wilson - Netw3 Consulting
> netw3 () netw3 com

-- 
Thomas Roessler                     <roessler () does-not-exist org>