This workstation compromised... Not sure how, but...

[John Van Ostrand]

On Mon, 2006-11-20 at 07:09 -0500, Dave Cramer wrote:
> > Again, I am open and receptive any and all comments/constructive
> > criticism regarding this situation.
> >
> > FWIW, the affected platform is an Intel PIII running Fedora Core 1 -
> > which (almost) obviously should have been upgraded a long time ago.

One easy thing to do is to run rpm -Va and look for changed executables
and config files that are scripts. There will be lots of changes listed.
Watch the 'c' attribute since this means config files. Some config files
are executed (e.g. /etc/init.d/, /etc/profile, etc) so you should check
those out. Otherwise look for /usr/bin, /bin, /usr/libexec and other
common executable locations.

This assumes that root kits do not install as RPMs and do not alter the
RPM database. So far this has been a safe assumption for me. Usually
procps is compromised with root kits. A quick check would be "rpm -V
procps".

If you find files that appear compromised use rpm -qf to find the
package of the file, download it and install it with the --noscripts
option. This avoids the catch-22 where a common file like 'ls' is
compromised and when run will re-infect and the pre or post-script for
an RPM uses ls as part of the install. Re-verify the package (rpm -V)
after installation. Some root kits make file immutable using ext3
attributes so that even root cannot replace the file. See item 6 below.

Most compromises will do one of the following:

1. Add a user to the /etc/passwd file. I haven't seen any clever ones
yet, but the date and time on the most recent /etc/passwd or the home
directory created with the user gives a good idea of the time the
compromise took place.
2. Add entries to /etc/xinet.conf or /etc/xinetd.d. This allows them to
start daemons for back doors.
3. Add lines to /etc/rc, /etc/rc.d/rc.local, or add a file
to /etc/init.d/. Use rpm -qf to find the owner of each file, anyone that
is not owned by a package is suspect.
4. One common exploit recently are from bad passwords (ssh dictionary
attacks.) Check /etc/passwd and /etc/shadow and make sure that there are
only passwords on accounts that you want.
5. Another common exploit is buggy web apps. Check /var/tmp and /tmp for
files or dirs owned by apache. Use 'ls -la /tmp /var/tmp' because the
attacker may have used hidden files. Also grep /var/log/httpd/error_log
for wget.  Often they use wget to download root kits.
6. They will often set an 'i' extended ext3 attributed on infected
files. Run lsattr /bin /usr/bin and look for 'i' in the attribute list.

There are some non-compromise things that may have bit you.

Check pam, to see if any files in /etc/pam.d have changed recently.
Check /etc/nsswitch.conf to see if it changed recently.
Did you change root's login in any way, perhaps a new shell that's not
in /etc/shells?

Good luck.


-- 
John Van Ostrand                       Net Direct Inc.
CTO, co-CEO                   564 Weber St. N. Unit 12
                                  Waterloo, ON N2L 5C6
john-Da48MpWaEp0CzWx7n4ubxQ at public.gmane.org                     ph: 518-883-1172 x5102
Linux Solutions / IBM Hardware        fx: 519-883-8533

--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists