 | Chapter 24 Discovering a Break-in |  |
| Chapter 24 Discovering a Break-in | |
If your intruder gained superuser access, or access to another privileged account such as uucp, he may have modified your system to make it easier for him to break in again in the future. In particular, your intruder may have:
Created a new account
Changed the password on an existing account
Changed the protections on certain files or devices
Created SUID or SGID programs
Replaced or modified system programs
Installed a special alias in the mail system to run a program
Added new features to your news or UUCP system
Installed a password sniffer
Stolen the password file for later cracking
If the intruder committed either of the last two misdeeds, he'll now have access to a legitimate account and will be able to get back in no matter what other precautions are taken. You'll have to change all of the passwords on the system.
After a successful break-in, you must perform a careful audit to determine the extent of the damage. Depending on the nature of the break-in, you'll have to examine your entire system. You may need to also examine other systems on your local net, or possibly the entire network (including routers and other network devices).
Note that COPS and Tiger are helpful recovery tools, as are many commercial security toolkits, especially because they provide an automatic check of the suggestions we make in this chapter. Remember, though, that they too could be compromised, so fetch a new copy and work from there. COPS and Tiger assume the integrity of system executables, such as ls and find. We think they are best used in conjunction with an integrity checker such as Tripwire. (See Appendix E, Electronic Resources for how to obtain all of these packages.)
The remainder of this chapter discusses in detail how to find out what an intruder may have done and how you should clean up afterwards.
After a break-in, scan the /etc/passwd file for newly created accounts. If you have made a backup copy of /etc/passwd, use diff to compare the two files. But don't let the automated check be a substitute for going through the /etc/passwd file by hand, because the intruder might have also modified your copy of the file or the diff program. (This is the reason it is advantageous to keep a second copy of the /etc/passwd file and all of your comparison tools on removable media like a floppy disk.)
Delete any accounts that have been created by an intruder. You may wish to make a paper record of an account, before deleting it in case you wish to prosecute the intruder (assuming that you ever find the villain).
Also, be sure to check that every line of the /etc/passwd file is in the proper format, and that no UID or password fields have been changed to unauthorized values. Remember, simply adding an extra colon to the /etc/passwd entry for root can do the same amount of damage as removing the superuser's password entirely!
The following awk command will print /etc/passwd entries that do not have seven fields, that specify the superuser, or that do not have a password:
# cat-passwd | awk -F: 'NF != 7 || $3 == 0 || $2 == "" { print $1 " " $2 " " $3}'
root xq7Xm0Tv 0
johnson f3V6Wv/u 0
sidney 104
#This awk command sets the field separator to the colon (:), which matches the format of the /etc/passwd file. The awk command then prints out the first three fields (username, password, and UID) of any line in the /etc/passwd file that does not have seven fields, has a UID of 0, or has no password.
In this example, the user johnson has had her UID changed to 0, making her account an alias for the superuser, and the user sidney has had his password removed.
This automated check is much more reliable than a visual inspection, but make sure that the script that you use to run this automated check hasn't been corrupted by an attacker. One approach is to type the awk command each time you use it instead of embedding it in a shell script.[3]
[3] Or use Tripwire.
An intruder who gains superuser privileges can change any file on your system. Although you should make a thorough inventory of your computer's entire filesystem, you should look specifically for any changes to the system that affect security. For example, an intruder may have inserted trap doors or logic bombs to do damage at a later point in time.
One way to easily locate changes to system programs is to use the checklists described in Chapter 5, The UNIX Filesystem.
After a break-in, review the protection of every critical file on your system. Intruders who gain superuser privileges may change the protections of critical files to make it easier for them to regain superuser access in the future. For example, an intruder might have changed the mode of the /bin directory to 777 to make it easier to modify system software in the future, or altered the protections on /dev/kmem so as to be able to modify system calls directly using a symbolic debugger.
Computer crackers who gain superuser access frequently create SUID and SGID files. After a break-in, scan your system to make sure that new SUID files have not been created. See the section Section 5.5, "SUID" for information about how to do this.
An intruder may have created new .rhosts files in your users' home directories, or may have modified existing .rhosts files. (The .rhosts file allows other users on the network to log into your account without providing a password. For more information, see Chapter 16.) After a break-in, tell your users to check their .rhosts files to make sure that none of these files have been modified.
Chapter 16 also contains a shell script that you can use to get a list of every .rhosts file on the system. After a break-in, you may wish to delete every .rhosts file rather than take the chance that a file modified by the attacker won't be caught by the account's rightful owner. After all, the .rhosts file is simply a convenience, and your legitimate users can recreate their .rhosts files as necessary.[4]
[4] At some sites, this may be a drastic measure, and might make some of your users very angry, so think it over carefully before taking this step. Alternatively, you could rename each .rhosts file to rhosts.old so that the file will not be used, and so that your users do not need to retype the entire file's contents.
An intruder may have added more machines to your /etc/hosts.equiv file, so be sure to check for changes to this file. Also, check your /etc/netgroups and /etc/exports files (or equivalent) if you are running NIS or NFS.
An intruder may have modified the contents of dot (.) files in your users' home directories. Instruct all of your users to check these files and report anything suspicious. You can force your users to check the files by renaming them to names like login.old, cshrc.old, and profile.old. Be sure to check the versions of those files belonging to the root user, and also check the /etc/profile file.
If you are using sendmail, the attacker may have created or modified the .forward files so that they run programs when mail is received. This aspect is especially critical on nonuser accounts such as ftp and uucp.
If you know the precise time that the intruder was logged in, you can list all of the dot files in users' home directories, sort the list by time of day, and then check them for changes. A simple shell script to use is shown below:
#!/bin/ksh
# Search for .files in home directories
for user in $(cat-passwd | /bin/awk -F: "length($6) > 0 {print $6}")
do
for name in $user/.*
do
[[ $name == $user/.. ]] && continue
[[ -f $name ]] && print "$name"
done
done | xargs ls -ltd However, using timestamps may not detect all modifications, as discussed at the end of this chapter. The -c and -l options to the ls command should be used to also check for modifications to permission settings, and to determine if the mtime was altered to hide a modification.
Another approach is to sweep the entire filesystem with thefind command and observe what files and directories were accessed around the time of the intrusion. This may give you some clues as to what was done. For instance, if your compiler, loader, and libraries all show access times within a few seconds of each other, you can conclude that the intruder compiled something.
If you decide to take this approach, we suggest that you first remount all your filesystems as read-only so that your examinations don't alter the saved filesystem dates and times.
The intruder may have created a "hidden directory" on your computer, and be using it as a repository for stolen information or for programs that break security.
On older UNIX systems, one common trick for creating a hidden directory was to unlink (as root) the ".." directory in a subdirectory and then create a new one. The contents of such a hidden directory are overlooked by programs such as find that search the filesystem for special files. Modern versions of UNIX, however, detect such hidden directories as inconsistencies when you run the /etc/fsck program. For this reason, be sure to run fsck on each filesystem as part of your routine security monitoring.
On some HP-UX systems, intruders have stored their tools and files in a CDF (Context Dependent File) directory. On these systems, be sure to use the -H option to find and ls when you are looking for files that are out of place.
Nowadays, intruders often hide their files in directories with names that are a little difficult to discover or enter on the command line. This way, a novice system administrator who discovers the hidden directory will be unlikely to figure out how to access its contents. Filenames that are difficult to discover or enter include ".." (dot dot space), control characters, backspaces, or other special characters.
You can often discover hidden directories easily because they cause results that differ from those of normal directories. For example:
prose% ls -l drwxr-xr-x 1 orpheus 1024 Jul 17 11:55 foobar prose% cd foobar foobar: No such file or directory prose%
In this case, the real name of the directory is foobar, with a space following the letter r. The easy way of entering filenames like this one is to use the shell's wildcard capability: The wildcard *ob* will match the directory foobar, no matter how many spaces or other characters it has in it, as long the letters o and b are adjacent.
prose% ls -l drwxr-xr-x 1 orpheus 1024 Jul 17 11:55 foobar prose% cd *ob* prose%
If you suspect that a filename has embedded control characters, you can use the cat -v command to determine what they are. For example:
% ls -l total 1 -rw-r--r-- 1 john 21 Mar 10 23:38 bogus?file % echo * | cat -v bogus^Yfile %
In this example, the file bogus?file actually has a CTRL-Y character between the letters "bogus" and the letters "file". Some versions of the ls command print control characters as question marks (?). To see what the control character actually was, however, you must send the raw filename to the cat command, which is accomplished with the shell echo.
If you are using the 93 version of the Korn shell, you can also list all the files in the local directory in a readable manner. This approach works even when your ls command has been replaced with an altered version:
$ printf $'entry: %'' .* * entry: . entry: .. entry: $'..\n' entry: $'bogus\031file' entry: temp0001 entry: temp0002 $
Sometimes attackers leave files in the filesystem that are not owned by any user or group - that is, the files have a UID or GID that does not correspond to any entries in the /etc/passwd and /etc/group files. This can happen if the attacker created an account and some files, and then deleted the account - leaving the files. Alternatively, the attacker might have been modifying the raw inodes on a disk and changed a UID by accident.
You can search for these files with the find command, as shown in the following example:
# find / -nouser -o -nogroup -print
Remember, if you are using NFS, you should instead run the following find command on each server:
# find / \( -local -o -prune \) -nouser -o -nogroup -print
You might also notice unowned files on your system if you delete a user from the /etc/passwd file but leave a few of that user's files on the system. It is a good idea to scan for unowned files on a regular basis, copy them to tape (in case they're ever needed), and then delete them from your system.
|  | |
| 24.3 The Log Files: Discovering an Intruder's Tracks |  | 24.5 An Example |