Section 17.1 Finding Suspicious Files | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

17.1 Finding Suspicious Files

The use of the find command is discussed here to find suspicious files of the type that crackers frequently leave behind after a visit. They do this to allow them to become root or otherwise cause trouble later, even if the original security hole is patched. In "Finding Permission Problems" on page 59, the use of find to catch errors during system administration, by users, or in the original Linux distribution itself was covered. Although the techniques are similar, here the concern is with a cracker trying to hide files.

Many SysAdmins will place these find commands in the root crontab. (If you have a root crontab entry invoking a script or program, you want to make very sure that the permissions on that script and all directories leading to it will prevent a cracker from causing a different script of the cracker's choosing to be run.) Although this will not catch a thorough cracker who covers his tracks very carefully, it will detect the majority who are not thorough. For the "800 pound gorilla" of detecting altered files, please see "Tripwire" on page 649. I found it harder to set up and use than any other tool discussed in this book.

It might be helpful to reread the manual page for find at this time. Either of the following commands may be used to print out the appropriate manual page; the first is for those whose lpr program understands PostScript.

 man -t find | lpr man find | lpr

The following command will find set-UID and set-GID files and also store the details in want_su. Note that you generate a listing and MD5 checksum of each file to detect cracker alterations of the contents of existing set-UID/GID files too. Certainly, if a cracker has root access, he can alter the system to cause all of these tests to not detect anything wrong but he has to know about them first.

 (find / ! -fstype proc -perm +6000 -ls \   ; find / ! -fstype proc -perm +6000 \   -print | xargs -n 50 md5sum) \   | sort | tee want_su

The following command will find these set-UID and set-GID files and report differences from the previous search:

 (find / ! -fstype proc -perm +6000 -ls \   ; find / ! -fstype proc -perm +6000 \   -print | xargs -n 50 md5sum) \   | sort | diff want_su - \   | Mail -s 'SU changed' admin@yoursite.com

The diff technique used here also can be applied to the rest of the find commands described below or throughout the book. It is not shown in the examples for simplicity.

The following example will show world-writable files. Expect to see /tmp and a few other directories and device files here.

 find / ! -fstype proc -perm -2 ! -type | -ls

Files whose names start with dot (".") normally are not listed by ls and so crackers will have their file names start with dot to hide them. As you know, the startup scripts for various programs frequently start with a dot so that ls commands on users' home directories will not produce excessive uninteresting output. (The -a flag causes ls to list these too, of course.) You could use find clauses of the form

 ! -name .profile ! -name .cshrc ! -name .login

before the -ls or -exec action clauses to ignore shell startup files. This would allow a cracker to hide data in these file names. Even ignoring them only in users' home directories is not completely safe because most users run only a single type of shell, allowing crackers to use the name of the startup file for a different shell. The following command will find files whose names begin with dot ("."):

 find / ! -fstype proc '(' -name '.??*' -o -name '.[^.]' ')' -ls

The following command will find files whose numeric UID (owner) is not in /etc/passwd or whose numeric GID is not in /etc/group. These could have resulted from someone extracting a tar archive legitimately or from an incomplete cleanup of a removed user. Also, they could be from a cracker extracting a tar archive containing a Rootkit or another evil utility. Although many of the previous find commands will generate lots of false positives, everything that this one finds should be investigated and corrected.

 find / ! -fstype proc '(' -nouser -o -nogroup ')' -ls

17.1.1 Analyzing Suspicious Files

When suspicious files are found, it would be helpful to do some analysis on them. Accidentally doing a cat command on a binary is unpleasant. The file command is another innovation from the distant UNIX past. For those who are not familiar with it, file does a rather sophisticated analysis of a file's contents to determine and report what kind of file it is, regardless of its name or extension.

Most binary file formats start with a unique byte sequence that find will recognize. Its ASCII-based table of file formats is called magic and is usually found in /usr/share, but sometimes in /etc. It has hundreds of patterns for recognizing scripts for various shells, perl, awk, and so on and almost every binary format in common use, even those that are not supported on Linux.

For each file on its command line (or standard input if a filename of "-" is given), it will list the file's name and its analysis of file content. It will not reveal the contents of the file itself so, generally, it should not be considered an invasion of privacy to run it on user directory trees if there is a security justification for it. Such justification might be a search for files with parameters that are indications of suspicious activity, such as file names beginning with dot.

The file command may be combined with a find invocation to analyze suspicious files. Examples would be

 (find / ! -fstype proc -perm +6000 -ls \   ; find / ! -fstype proc -perm +6000 \     -print | xargs -n 50 md5sum \   ; find / ! -fstype proc -perm +6000 \     -print | xargs -n 50 file) \   | sort | diff want_su - \   | Mail -s 'SU changed' admin@yoursite.com

and

 (find / ! -fstype proc '(' -nouser -o -nogroup ')' -ls   ; find / ! -fstype proc '(' -nouser -o -nogroup ')'   -print | xargs -n 50 file) \   | Mail -s 'Unowned files' admin@yoursite.com

17.1.2 Comparing File Contents Regularly

If a cracker can get write access, frequently he will alter configuration and startup files to create Trojan horses so that he can get back "in" to the system if the original security hole is plugged.

Occasionally, a cracker will plug the security hole that he used to break into a system, after planting a Trojan horse, to prevent other crackers from taking over "his" system.

The many configuration files in /etc, as well as root's own shell startup files, are popular. Although finding all cracker-altered files on a system can be done, and is discussed in "Finding Cracker-Altered Files" on page 697, doing a frequent scan on files that crackers popularly "hit" on a regular basis is an excellent idea. The world-readable ones in /etc most commonly altered are listed here.

 aliases                  logrotate.conf exports                  mailcap ftpaccess                profile ftpusers                 resolv.conf group                    securetty hosts                    sendmail.cf hosts.allow              sendmail.mc hosts.deny               shells hosts.equiv              smb.conf hosts.lpd                syslog.conf inittab                  *.conf lilo.conf

Additionally, there is the shadow, which never is world-readable. One solution would be to maintain a copy of these files somewhere and periodically run a script that invokes diff between the copy and the real files. Certainly, some of these will change over time, /etc/passwd most frequently. If these files are kept in a subdirectory called requisitions, the following script, called diffetc, will e-mail the differences to what ever e-mail address is provided as an argument. It would be a fine addition to the SysAdmin's personal crontab.

 #!/bin/csh -f umask 077 cd requisitions foreach i ( * )           cmp -s $i /etc/$i           if ( $status != 0 ) then                    echo "=== different: $i" >>! .tmp$$                    diff $i /etc/$i >>& .tmp$$                    echo "----------" >> .tmp$$           endif end if ( -f .tmp$$ ) then           Mail -s 'NOT OK: /etc conf analysis' \             $* < .tmp$$           /bin/rm .tmp$$           exit 1 else           echo "All ok" \             | Mail -s 'ok: /etc conf analysis' $*           exit 0 endif

Especially note accounts in /etc/passwd with a UID of 0 with variations on "root"; "toor" and "r00t" are popular. Entries with plus signs ("+") are common too. These are frequently found at the end or in the middle of /etc/passwd. The .hosts and .hosts.equiv files, too, are popular on those systems where the SysAdmin has not yet disabled rsh and friends, as discussed in "Turn Off rsh, rcp, rlogin, and rexec" on page 100, or where ssh is allowed to use these files. Look for suspicious entries in /etc/hosts, /etc/hosts.allow, and /etc/hosts.deny too. The innocent little /etc/aliases file, used by sendmail, also can be used for root exploits because it can be used to arrange for e-mail to a particular name to cause the execution of any program as root to process that recipient's e-mail.

Top