Security Incidents mailing list archives
Re: Checking for rootkits
From: "Jon O." <jono () networkcommand com>
Date: Mon, 25 Feb 2002 14:35:39 -0800
Jason: This is interesting and it's good to see more people using this tool. However, I've got a new design that you may want to consider and I'd recommend for this type of tool along with any Tripwire type tool and possibly even others. Create a chkrootkit server. On this machine you have binary builds for your different platforms along with a data repository of output data. Deployment works by scp, moving the files to the target hosts and running chkrootkit and copies the results back to the chkrootkit server and removes all traces of chkrootkit running on the target machine. The output data is processed and email to admin or dumped to a webpage for review. This way the binaries are not sitting on the machine you are trying to protect and any attacker is unaware chkrootkit is being run until the process comes by the machines, effectively surprising the attack if they notice at all. I've created a similar tool for file integrity monitoring, running once every half hour and found it is also effective as a change control tool. Futhermore, there is added piece of mind knowing that if someone does break in, they would have to disable or prevent the integrity tool from running essentially without prior knowledge it was running. Anyway, just a suggestion that I have found works well for large deployments and doesn't really count on the machine you are trying to monitor. Thanks, Jon On 25-Feb-2002, Jason Dixon wrote:
A few updates... 1) Change the standard file attributes on the md5 file before setting the immutable flag. I make mine 0400 so it's read-only by the superuser. (chmod 0400 /etc/chkrootkit.md5) 2) You may need to edit the location of your mail program in line 18 (changed mine from /usr/bin/mail to /bin/mail). 3) Line 32 of the script will need to be adjusted on Linux boxes... the md5 output is reversed. Simply replace the command 'pop' with 'shift'. -Jason On Fri, 2002-02-22 at 17:55, Jason Dixon wrote:Thanks to an article on the O'Reilly network (http://linux.oreillynet.com/pub/a/linux/2002/02/07/rootkits.html), I've started using chkrootkit (http://www.chkrootkit.org), a utility that checks for rootkits on your Linux/BSD/Solaris install. It looks for certain signatures in trojaned system binaries and compares them against known rootkits. It includes other tools that check for network promiscuity (ifpromisc), lastlog deletions (chklastlog), wtmp deletions (chkwtmp), wtmpx deltions (check_wtmpx - Solaris only), and checks for signs of LKM trojans (chkproc). I've performed some extra steps which allow me to automate the running of chkrootkit, while also authenticating the validity of the chkrootkit binary itself. I'm including the steps here, in case anyone else would like to try this on their own systems. Please note... this utility is great for checking against *known* rootkits... it's not a substitution for common security practices. I would also suggest that anyone serious about preventing rootkit modifications also ensure they install Tripwire on all new installations. However, in situations where a box does not already have Tripwire installed, chkrootkit is a great tool to help gain back some peace of mind. This document covers Linux and *BSD installs only. Installation of chkrootkit is very simple. Grab the tarball, uncompress, and run 'make sense' (as root). Copy the binaries to a standard system bin (I used /usr/local/sbin). Cd to the new location and run the chkrootkit by hand to make sure everything looks good.... tar zxf chkrootkit-0.35.tar.gz cd chkrootkit-0.35/ make sense cp chkrootkit /usr/local/sbin/ cp chkwtmp /usr/local/sbin/ cp chklastlog /usr/local/sbin/ cp chkproc /usr/local/sbin/ cp ifpromisc /usr/local/sbin/ ./chkrootkit The output will look something like this... (snipped for brevity's sake) ROOTDIR is `/' Checking `amd'... not infected Checking `basename'... not infected Checking `biff'... not infected Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `date'... not infected ... Checking `sniffer'... dc0 is not promisc sl0 is not promisc ppp0 is not promisc bridge1 is not promisc gif0 is not promisc Checking `wted'... nothing deleted Checking `z2'... nothing deleted Ok, now for the extra layer of security. To ensure that no one tampers with my chkrootkit binaries, I've created a new file (/etc/chkrootkit.md5) containing the md5sum for each binary. Next, we want to modify the md5 file so nobody can tamper with it. We want to turn on the *immutable* bit for this file. Making a file immutable means that no one can modify the delete the file. In linux, we want to use the 'chattr +i' command... in *BSD, the same command is 'chflags schg'. To view special attributes, you must use 'lsattr' in Linux and 'ls -lo' in *BSD. Note that in Linux, the immutable flag can be removed by the superuser at any time with 'chattr -i'. In *BSD systems, you can only remove the "system immutable" (schg) flag in securelevel 0 or -1 (single-user mode is an example of securelevel 0). md5sum chkrootkit >> /etc/chkrootkit.md5 [run the same command for each binary; command is 'md5' in *BSD] chattr +i /etc/chkrootkit.md5 [Linux] chflags schg /etc/chkrootkit.md5 [*BSD] To automate these utilities, I've setup a cron job to execute a perl script I've created which first authenticates our stored md5 digests against the current md5 values. It uses the Digest::MD5 perl module to run the digests. Installing the perl module is very simple... grab the tarball, uncompress to a directory, run (as root) 'perl Makefile.pl', 'make', 'make test' and 'make install'. wget http://www.cpan.org/authors/id/GAAS/Digest-MD5-2.16.tar.gz tar zxf Digest-MD5-2.16.tar.gz cd Digest-MD5-2.16/ perl Makefile.pl make make test make install Here is the script... I make no guarantees... YMMV. Note the variables that should be changed specific to your usage... $md5_sav_file (location of your trusted md5 file), $runpath (location of your chkrootkit binary), and $admin_mail (your email address... make sure to escape the '@' with a backslash or perl won't interpret it correctly). The script will first compare the known and trusted md5 sums found in our immutable file to the current md5 sums of the binaries. If there are any discrepancies, it will report them. Next, it will cd to the system bin (as defined by $runpath) and run the chkrootkit binary. It needs to cd to the directory, as chkrootkit will attempt to run the other utilities within it's current directory. #!/usr/bin/perl -w # safe_chkrootkit.pl use strict; no strict 'subs'; use Digest::MD5(md5_hex); my $md5_new; my $md5_sav; my $md5_sav_file = "/etc/chkrootkit.md5"; my $file; my $file_and_path; my $path = "/usr/local/sbin"; my @files = qw( ifpromisc chkproc chkrootkit chklastlog chkwtmp ); my @input; my $admin_mail = "admin\@localhost.com"; open(MAIL, "|/usr/bin/mail $admin_mail"); print MAIL "Running authentication tests on chkrootkit binaries...\n\n"; while (<@files>) { $file = $_; $file_and_path = "$path/$file"; open(MD5,"$file_and_path") || die "Can't open file for reading: $!"; $md5_new = Digest::MD5->new->addfile(MD5)->hexdigest; close(MD5); open(TST,"$md5_sav_file",) || die "Can't open file for reading: $!"; while (<TST>) { chomp; if (/$file/) { @input = split(/ /,$_); $md5_sav = pop(@input); unless ($md5_new eq $md5_sav) { print MAIL "\t\t\t*** WARNING ***\n"; print MAIL "The binary file for " . $path . "/" . $file . " has been altered.\n"; print MAIL "The original md5 sum for $file was\n\n"; print MAIL "\t\t$md5_sav\n\n"; print MAIL "and the new md5 sum is\n\n"; print MAIL "\t\t$md5_new\n\n"; print MAIL "Please investigate ASAP\n"; print MAIL "\t\t\t*********************\n"; } else { print MAIL "\[$file\]\n"; print MAIL "Current: $md5_new\n"; print MAIL "Trusted: $md5_sav\n\n"; } } } close(TST); } I hope that others find this as useful as I have. I've implemented this on my OpenBSD firewall, and plan on installing it on my Linux workstation ASAP. Keep in mind that there are many other facets of system security that should still be scrutinized, but this is a nice tool to help out nonetheless. If anyone has any questions, comments or suggestions regarding my usage of this program, or the functionality of the script, please let me know. -Jason _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
Current thread:
- Checking for rootkits Jason Dixon (Feb 24)
- Re: Checking for rootkits Jason Dixon (Feb 25)
- Re: Checking for rootkits Jon O. (Feb 25)
- Re: Checking for rootkits Matt Zimmerman (Feb 25)
- Re: Checking for rootkits Jason Dixon (Feb 25)