LinuxQuestions.org - Chkrootkit Alert. Am I actually compromised

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Chkrootkit Alert. Am I actually compromised (https://www.linuxquestions.org/questions/linux-security-4/chkrootkit-alert-am-i-actually-compromised-388433/)

Chkrootkit Alert. Am I actually compromised

I was reviewing my nightly notifications from my linux server this afternoon and I saw the following from chkrootkit

Quote:

/etc/cron.daily/chkrootkit:
You have 1 process hidden for readdir command
You have 1 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed
eth0: PACKET SNIFFER(/usr/sbin/snort[26839])

I ran chkrootkit again and it only shows snort. So I than ran -x lkm and got the following.

Quote:

nix:/sbin# chkrootkit -x lkm
ROOTDIR is `/'
###
### Output of: ./chkproc -v -v -p 2
###
CWD 3541: /var/lib/mysql
EXE 3541: /usr/sbin/mysqld
CWD 3542: /var/lib/mysql
EXE 3542: /usr/sbin/mysqld
CWD 3543: /var/lib/mysql
EXE 3543: /usr/sbin/mysqld
CWD 3544: /var/lib/mysql
EXE 3544: /usr/sbin/mysqld
CWD 3547: /var/lib/mysql
EXE 3547: /usr/sbin/mysqld
CWD 3548: /var/lib/mysql
EXE 3548: /usr/sbin/mysqld
CWD 3549: /var/lib/mysql
EXE 3549: /usr/sbin/mysqld
CWD 3550: /var/lib/mysql
EXE 3550: /usr/sbin/mysqld
CWD 3551: /var/lib/mysql
EXE 3551: /usr/sbin/mysqld

What's the likelyhood I've actually been compromised and this isn't a false positive? The server is still up and running and I haven't killed any processes. I'm wondering if I shoudn't scratch chkrootkit and install fresh from source and then scan it again?

My reading on google suggests that LKM Trojan can frequently be reported as a false positive so I don't want to jump the gun and do a complete format / reinstall if it's not necessary.

Any advice/suggestions are greatly appreciated!

The lkm check is prone to false positives especially for threaded processes, whioh I wouldn't be surprised to see spawning from mysql. That being said, check the integrity of the mysqld binary; on rpm-based distros you can use rpm -V <package_name>. Otherwise you can compare it's md5 hash to a known good version.

Also, is snort supposed to be on this box?

Quote:

Originally posted by Capt_Caveman
The lkm check is prone to false positives especially for threaded processes, whioh I wouldn't be surprised to see spawning from mysql. That being said, check the integrity of the mysqld binary; on rpm-based distros you can use rpm -V <package_name>. Otherwise you can compare it's md5 hash to a known good version.

Also, is snort supposed to be on this box?

Yup. Snort is intentional. I'm running Debian and MySQL was originally installed via apt-get.

Here's what I see on my system.

Quote:

$ sudo mysql -V
mysql Ver 14.7 Distrib 4.1.11, for pc-linux-gnu (i386)

Quote:

$ md5sum -b /usr/sbin/mysqld
7d68a5b3adab3eb7cbed1add8ae37d37 */usr/sbin/mysqld

Apparently that version of Mysql is several revisons behind, although apt never found a newer version to upgrade to. I checked the mysql source archives at http://downloads.mysql.com/archives....l-4.1&v=4.1.11 and didn't find any package name or MD5 that matched. Is there someplace else I should be looking for a valid MD5 sum or am I SOL?

The lkm check is prone to false positives especially for threaded processes
I'd like to rephrase that as "the way the LKM check is done *any* short-lived process can cause an FP".

One way to diminish chances of running alien binaries could be to use GRSecurity's "Trusted Path Execution". This means no binaries can be run except those in $PATH, provided PATH is set to a sane choice of dirs and those dirs and binaries can not be tainted (ownership, attributes, extended attributes, mount flags). If you're running a server as well check on mounting $TEMP dirs with noexec and/or nosuid mount flags where possible. Do run a check if this causes trouble for applications though.

Quote:

Originally posted by unSpawn
The lkm check is prone to false positives especially for threaded processes
I'd like to rephrase that as "the way the LKM check is done *any* short-lived process can cause an FP".

One way to diminish chances of running alien binaries could be to use GRSecurity's "Trusted Path Execution". This means no binaries can be run except those in $PATH, provided PATH is set to a sane choice of dirs and those dirs and binaries can not be tainted (ownership, attributes, extended attributes, mount flags). If you're running a server as well check on mounting $TEMP dirs with noexec and/or nosuid mount flags where possible. Do run a check if this causes trouble for applications though.

Thanks for the info UnSpawn. I already have my /tmp directory mounted as such

/dev/hda8 /tmp ext3 rw,noexec,nosuid

I'm still hoping I can find the correct MD5 to compare to.. I'd rather not have to do a complete re-install of the server :(

Might be a good idea to get rkhunter. I always like to have at least two ways to look at these things.

Might be a good idea to get rkhunter.
Spreading your detection capabilities a way better idea would be to get Aide, Samhain or even tripwire running.

Quote:

Originally Posted by unSpawn

Might be a good idea to get rkhunter.
Spreading your detection capabilities a way better idea would be to get Aide, Samhain or even tripwire running.

I agree with unSpawn. The more detection tools the better, the more layers of security the better. Rootkithunter also looks for other system security vulnerabilities besides rootkits. Bastille and Aide as well as tripwire are very good tools.