Re: [linux-security] Re: Re: Bind Overrun Bug and Linux (fwd)

[Shaun <shaun lexicom ab ca>]

> > systems which no longer seem to have this. This file contained an archive of
> > the trojan's that were inserted into the compromised system - does anybody know
> > what is in these trojans?
> 
> Check the Linux RootKit ... (LRK)..
> 
> Typically LRK to use config-files.. (and typically LRK-users to place
> files in /dev.. find /dev -type f | grep -v MAKEDEV.. examine results)
> 
> ps
> ls
> top
> netstat
> ifconfig
> linsniff
> login

Finding a joe blow hacker is quite the trivial process, most of them leave
the default configuration files as they were named in the rootkit.

There are many set of trojanned source code trees out there, but the most
prevailent seems to be Linux RootKit (LRK).  This kit included lots of
trojanned binary source, but is sloppily written.

This is all LRK actually contains, from it's readme:
chfn: local backdoor
chsh: local backdoor
inetd: remote backdoor
login: remote backdoor
ls/du: hide files
ifconfig: hide sniffing
netstat: hide connections
ps/top: hide processes
passwd: localhost backdoor
rshd: remote backdoor
syslogd: hide log strings
tcpd: avoid denials
It also includes linsniff, and a few other log cleaner programs.

Furthermore;  there are more eleet rootkits out there that include a
number of kernel modules that can hide virtually anything.


 For example, LRK config defaults:
	/dev/ttyp*
These files are quite noticable, as *no* files in /dev/ should be of type
f (regular file) except MAKEDEV.  They should be of only type: c/b/s.  A
simple 'find /dev -type f' will report all of the regular file types.

Doing a strings /bin/ps will should you the file that they have assigned
PS to take its hideable strings from.

Also, you may want to look at some code that looks through the wtmp/utmp
files and looks for null entries, most wtmp cleaners NULL out the entry,
rather than writing a whole new wtmp.

I would not be so sure as to rely on what they have backdoored locally, as
most people would want to place many remote backdoors. If there is no
remote backdoors, then what use is there to put a local backdoor in?  

I would think the most common remote backdoor pairs would be something
like: rshd/tcpd/inetd/login and local: passwd/ping/chfn.  I witness many
people using *all* of the backdoors provided with these rootkits, just to
get found in 1 hour.  

There are many preventitive measures that could be taken to possibly
avoid these situations.  
For example: 
	-take checksums and make a script that compaires them nightly.  It
is also a good idea to grab a clean binary, and a master checksum list of
a WRITE protected media source, most commonly a floppy disk.  
	-keep clean system binaries, all of the netkit, and majority of
suid root installed binaries.
	-make some sort of script that monitors the kernel and reports
if it is forced into promiscous mode.
	-know WHO is on your system, and measure out the pro's and con's
in giving out shell accounts
	-keep updated on what bugs have been made public, along with
applying the necessary patches for them
	-compile your kernel to not support on-demand loadable modules
	-do nightly diff's between crucial system files, eg: /etc/passwd

There are many other measures to be taken, and many software packages out
there to help.  But it all boils down to the whole fact that if you are
security concious, rootsh3ll hackers will not be able to comprimise your
network integrity as they only use publically available exploits.  And if
the person that is hacking you does not use rootsh3ll warez, expect to
never get rid of him without rm -rf /'ing your whole system.  

On a side note, LRK has much quantity, but lacks quality.  Any hacker
with skill realizes that you cannot have gay little /dev/ttyp* plain text
configuration files laying around.

Don't be scared of 'configure rootkit ; make install'  kiddies, these are
the people like 'The Analyzer' that get caught up on becoming well known
in the hacker community, but have no real skills.

Be scared of the people that you do not see on your system, or find
evidence of them being their, but you just know they are.


Regards, Shaun.