Re: RedHat 6.2 box exploited - analysis of attacker activity

[xflare () INFINITO IT]

i've had the same attack on a plain rh6.2 box; but
I just unplugged the computer from the networkand
it?s still there, since i 've had no time to check
it in depth;
But it's impressive .  the attacker put the same
stuff (linsniffer and the irc stuff);
he sent a mail with root account to an email
address and the site from where he was connecting
seemed something like computerfun.mini...
but I think he used another way to get in; 
cgi and operator account were created/modified,and
he left a lot of stuff; when i'll find some time I
'll say more.
Bye
Nick




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