Root Access Intrusion -- A Suite of Tools

Rhonda Thorne

While UNIX systems administrators aren't worried about things like the "CodeRed" or "I Love You" viruses, a root access intrusion is a real threat. By minimizing the number of people who know the root password, establishing a frequent regular schedule to change the root password, and forcing a switch user (su) to root, systems administrators may think that they have secured their systems. However, someone who is not approved to use root could still invade a UNIX system. This article will provide some tools to help administrators detect and investigate possible intrusion.

If you are like me and have lots of systems to monitor, you know it is time consuming to review sulogs, command-line history files, and password files for root access intrusions. Monitoring UNIX files with automated tools is essential for effective security. If you have an HP 11.0 system, the free IDS/9000 Intrusion Detection System may be worth using. If not, the following suite of tools can be used by any UNIX admin for intrusion notification and investigation.

With more than six years of experience, and using the "Zen of Sys Admin" (save the data, secure the system, and make the users effective), I applied all of the measures that I learned in UNIX security training and was confident that the possibility of a breach was minimal. However, while working on a massive Y2K conversion project that included more than 30 applications, application development, and database consultants, I encountered a breach of security at the root access level. Fortunately, the tools discussed here were in place and disclosed the security breach, identified the intruder, and proved which commands had been executed during the intrusion.

The Scenario

I received an email showing su's to root on a system had transpired. I noticed that the username switching to root had no right to root access, so I went to the directory containing each root login command-line history. I had the username, time, and date of the person switching to root. I opened this history file to view the command lines executed by the intruder and found that this person was logged in as root and had entered a command of vi /etc/passwd. I immediately went to the /etc/passwd file and found an additional entry for root with a different username. This is a sys admin's nightmare -- the system had been breached, and the intruder had created a root "back door".

Upon further review of the root command-line history and home directories .sh_history, as well as checking out the system, the only damage shown was the creation of the root back door and some permission changes to database files. I copied the /etc/passwd file, removed the root back door from the active /etc/passwd file, changed the root password on all of the systems, and printed out my evidence from the saved password file, pertinent history file, and the sulog file.

After removing the security holes, I gathered the evidence and informed the IT Director. With all of the evidence from these tools, the IT Director had no choice but to let this user go. The IT Director was impressed with my proactive method of proving an improper root access intrusion and rapid system recovery after the breach. There were still lessons to be learned from this incident, however, and I immediately created a way for the system to notify me of any root back doors added to the /etc/password file.

The tools described here have not been tested on a Linux box, but they should work with some script tweaking. The methods have been tested on IBM AIX, HP-UX, and Solaris platforms for this sample. Here is the setup:

Step 1: Forcing an su to root

For all of these tools to work, you must prohibit users from logging in as root. In other words, you must force users to access root through the su - command. This will cause an entry in the /var/adm/sulog, which will provide the name of the user trying to breach root access security. It will also create a separate file in a specified directory that contains the intruder's command-line history (explained in step 2). If you choose not to force su - to root, the notification tools can still be used (steps 3 and 4). The following methods will force an su to root, making it so that a direct login as root can only be done at the console.

AIX: You can use SMIT, security users, change user for root, and mark remote login to be "false". If you are using NIS on your systems, I recommend investigating this further because SMIT will use the "change user command" (chuser). The chuser man page recommends not using this command if you are running NIS because chuser only changes local files, not NIS files.

HP-UX: Create the file /etc/securetty and add the word CONSOLE. Change permission on the file by doing a chmod 600 /etc/securetty, thereby requiring root access to change this file.

Solaris: Ensure the entry CONSOLE=/dev/console is placed uncommented in the /etc/default/login. Permissions to the /etc/default/login file should be set so that no one can change this file except root, but the file can be read by all. You may try chmod 444 /etc/default/login.

Step 2: Capturing Individual root Login Command-Line History

To catch an intruder and the commands he executes, root's .profile must be revised to include the creation of separate command-line histories for each root login. This is accomplished by adding the script in Listing 1 and setting the login shell to be the Korn shell (ksh) in the /etc/passwd file.

Solaris: You can place the login shell of /bin/ksh in the /etc/passwd, replacing the default of /sbin/sh. Don't make the mistake (as I did) of typing /sbin/ksh -- this is an invalid shell and you won't be able to log in as root.

Be sure to close down root's .profile permissions by doing a chmod 700 .profile so that root is the only one who can change or read root's .profile. This keeps everyone's command-line histories separate while using the Korn shell esc k command-line history option. If the user or intruder does not use the su - when switching to root, these command-line histories will be kept in the intruder's home directory (.sh_history) file. This makes intrusion investigation difficult (if not impossible), because the intruder can clean up his .sh_history file. If this is a critical point and educating users to enforce the su - is unmanageable, you may choose to use the sudo tool for regular users wanting root access for specific purposes, and enforce the su - for the admins only.

In this sample, I use the directory name /var/adm/hist, since other system logging is kept in /var/adm. You can use any name for the directory name. Be sure that you chmod 777 the directory so that everyone has write permission. I also did a chown root:sys /var/adm on AIX and HP, and root:other for Solaris. The file name consisting of the su entry and date:time-year (rthorne-root@13:42:20-021302) is necessary for pinpointing and proving the intrusion. Don't forget to set a root crontab entry to clean out the hist files, which accumulate and take up space. I set my root crontab to remove any hist files over 30 days old, because I should know if a root access breach has occurred before that time elapses.

Step 3: Notification of su Activity

Listing 2 checks the /var/adm/sulog file for su's to root attempted for this date and reports them via email. Remember that a plus sign (+) in the sulog means a successful su, and a minus sign (-) means an unsuccessful su (but it still needs investigation). The reporting function can be changed to the method by which you want to be notified. I have made an entry in the /etc/mail/aliases file for sysadmin2, but you could hardcode the notification address in the script. Place an entry in the root crontab file to run this script on the frequency of your choice, but run it before midnight because it checks for su's for today's date. In this sample, I have simply called this entry security.chk. Keep in mind that an intruder may check the crontab for anything checking for intruders.

Solaris: For the grep -e to work, you must have /usr/xpg4/bin in the root .profile PATH or hardcode this entry in your script (grep `date +$m/%d` /var/adm/sulog | /usr/xpg4/bin/grep -e "-root").

Step 4: Checking the /etc/password File for Root Back Doors

In Listing 3, the password file will be searched for root back doors. As in step 3, you can be notified in any manner. I choose to be paged when a back door has been detected. I have also placed an /etc/mail/aliases entry for sysadmin-page, but you can hardcode the notification address in the script. Place an entry in the root crontab file for the frequency that you would like to be notified if any root back doors are found. Remember to name this script so that the intruder isn't aware of the check for root back doors while reading a crontab listing. There are some sys admins who have root back door passwd entries for administration reasons. If you are one of those, be sure to change -gt 1 to the number of root passwd entries that is normal for your site.

AIX: Change the count line in the script to be the :0:0:, which is the UID/GID of root. By only looking for :0:, the script could report erroneous findings.

HP-UX: Change the count line in the script to be :0:3:, which is the UID/GID for root, because some systems use the UID of 0 for the user system.

Solaris: Change the count line in the script to be :0:1:, which is the UID/GID for root, because some systems use the UID of 0 for the user system. For the grep -e to work, you must have /usr/xpg4/bin in the root .profile PATH, or hardcode this entry in your script as shown in step 3.

Conclusion

I hope that you find these tools useful. Proactive security notification tools help keep you informed when there is a root access intrusion on your system, but I also hope you never need to use the information that these tools can give you. That would be a sys admin's dream.

Rhonda Thorne has been working for more than nine years as a UNIX sys admin. She holds several certifications in IBM AIX and HP-UX and is working on the Solaris SCSA certification. Rhonda is currently working with Solectron Global Services in Memphis, Tennessee. She can be contacted at: rhondathorne@mem.slr.com.