indicators of unix host compromise

What Intruders May Do After They Have Root

Paul C. Brutch, a 1999 USENIX scholar and Ph.D. candidate in computer science at Texas A&M University, performs research in network security.




Tasneem G. Brutch
<tasneem@cs.tamu.edu>

Tasneem G. Brutch is a Ph.D. candidate in computer engineering at Texas A&M University. She performs research in security for wireless and mobile computing.



and Udo Pooch
<pooch@cs.tamu.edu>

Dr. Udo Pooch is the E-Systems Professor of Computer Science at Texas A&M University.

Chronology of a Host Compromise

At 12:00 noon on July 19, 1995, a team of intruders decided to attack an organization's computer system — a system on which the intruders already had valid user accounts. Since they knew the organization's personnel, they decided to use social engineering. Their goal was to obtain the root password for the organization's primary server, and from there to wreak havoc. At 1:00 pm, using administrative privilege at another site, the intruders created a user account at that site with the same account and user name as those of the system manager of the target organization. The intruders sent an email message from this fake account to one of the system administrators in the target organization, asking for the server root password. At 3:11 pm, the system administrator replied to the spoofed email message and provided the real root password. The system administrator, replying out of elm, did not see the mail header and was therefore unaware that this message did not originate from the system manager.

At 3:12 pm, the intruders logged in to the primary server of the target organization using the account of another system administrator, whose password they had sniffed earlier. Next they su'd to root using the password sent to them in the email reply. They proceeded to change the root password and the password of the system administrator's account that they had used to log in. Next they removed other user accounts and even changed the EEPROM password using the eeprom command. Finally, the intruders attacked other machines on the organization's network and destroyed security and administrative functions.

Sometime before 4 pm, the system-administration team detected a problem: they could not log in. They noticed a message on the console of a client machine indicating that an unprivileged user had successfully su'd to root. They also found that the EEPROM password was changed on the server. At 4:12 pm, they decided to power off their machines. On the next day, July 20, the system-administration team struggled unsuccessfully to recover. By July 21, they decided that it was necessary to perform a complete reinstallation of all Sun workstations with an upgrade from SunOS to Solaris 2.4. On July 24, they had their machines operational, and user accounts were restored on July 25. On July 31, one of the client machines was compromised again by the same team of intruders.

This is a description of an actual incident. The individuals who performed this attack were later identified. Instead of being prosecuted, they were rewarded. The attack was accomplished by graduate students during a computer-security laboratory exercise conducted at Texas A&M University. The attack was real, but it was made in a controlled environment as part of a graduate-level computer-security course. This article focuses on some of the ways that students in the course were able to compromise a UNIX host and what actions they took to hide their presence and maintain superuser privilege.

Overview of the Course

Dr. Udo Pooch started the graduate computer-security course in the summer of 1995; through the spring 1999 semester, he has taught it to over 110 students. The course is a mixture of formal classroom instruction on computer and network security principles, and a hands-on security laboratory. As part of the security laboratory, students are divided into multiple penetration teams and a single system-administration team. Each penetration team is given superuser access to a Linux machine residing on a private network. A penetration team has complete control over its assigned Linux machine, and the system-administration team is not normally allowed to venture onto the penetration team's network. The system-administration team manages machines on a separate network, and these two networks are connected by a router. The system-administration team's network consists of a number of Sun workstations running Solaris 2.5.1 and one NT 4.0 machine. The router isolates the security laboratory from the department's network, and a proxy server provides a controlled single point of access to the laboratory[4].

The goal of the penetration teams is to compromise a machine managed and monitored by the system-administration team. The penetration teams are allowed to make almost any type of attack as long as their activity remains within the domain of the security laboratory. The penetration teams have accounts on their own Linux machines and separate user accounts on some of the system-administration team's machines. Therefore, the penetration teams can conduct attacks as inside intruders and simulate remote attacks from the Internet. The system-administration team also provides one Sun workstation running Solaris 2.5.1, without any security patches, for use as a training machine by the penetration teams. Although this training machine resides on the system-administration team's network, it is not trusted by any of the other machines and it is not monitored by the system-administration team. Penetration teams have successfully launched attacks from this training machine to compromise more secure hosts on the system-administration team's network.

The goal of the system-administration team is to detect and trace all unauthorized access for the machines that it manages and monitors. The system-administration team makes every effort to ensure that the systems they monitor are secure. Ideally, the system-administration team should: install the latest vendor security patches; perform vulnerability scanning by running Tiger scripts by Doug Schales; install tcp wrapper by Wieste Venema to monitor and filter incoming requests for certain network services; run Crack by Alec Muffet against the password file; enable remote logging via the syslog facility; and run Tripwire by Gene Kim and Eugene Spafford to perform system integrity checking. Unfortunately, the system-administration team spends much of its time at the beginning of each semester performing mundane administrative tasks like setting up user accounts. In some cases, penetration teams have compromised a monitored host before the system-administration team was even able to install all of its security tools.

Throughout the past five years, various hardware and software configurations have been installed in the security laboratory. For example, in 1998 secure hubs were used for physical connectivity to prevent penetration teams from sniffing traffic on the system-administration team's network[4]. The security laboratory changes each year as new system-administration teams try different configurations to implement different security solutions. As the security laboratory configuration becomes more complex, it requires more time from the system-administration team to set up and manage.

Definition of Host Compromise

We need to define what we mean by a host compromise. Kahn states that a component is compromised if it is misused or under the control of an adversary of its owner; events that can compromise a component include penetration, attack by an insider, and accidental misuse[3]. For the purpose of this article, we will say that a UNIX host is compromised whenever an intruder is able to log in with the real user ID and effective user ID of superuser, or when an intruder can change the real user ID or effective user ID of a process, such as a shell program, to superuser. In UNIX, any account with UID 0 has superuser privilege.

At login time, intruders can set their real and effective user ID to superuser simply by logging in as the root account and supplying the root password. Any other account that has a UID of 0 would work. Intruders sometimes create or modify accounts in the /etc/passwd file with UID 0 as a backdoor. Alternatively, the intruder can use the setuid() routine to set the real and effective user ID of a process. In order for this attack to work, the process calling the setuid() routine needs to have an effective user ID of superuser. Root-owned, set-user-ID files (programs) temporarily change the effective user ID of the process to superuser when the program is executed. In some cases, it is necessary to provide root-owned, set-user-ID programs in order to allow normal users to perform tasks that require privilege. Intruders often exploit these set-user-ID programs to run a process, such as a shell program, with an effective user ID of superuser.

Exploits to Gain Superuser Privilege

The penetration-team members used several approaches to acquire superuser access on the system-administration machines. These included exploitation of system misconfigurations, buffer-overflow attacks, symbolic-link attacks, TCP spoofing, and social engineering. One of the penetration teams took advantage of the trusted status of their machine in the /etc/hosts.equiv file on one of the system-administration team machines to rlogin as a privileged user. Buffer-overflow attacks were made against root-owned, set-user-ID programs such as fdformat and eject. These programs had vulnerabilities because bounds checking was not properly done in the volume-management library. Symbolic-link attacks were also run against root-owned programs such as lpr and Solaris Admintool. The penetration teams used repeated invocation of the lpr command to overwrite the /etc/passwd file using a previously created symbolic link in the print spool directory. Another symbolic-link attack was made against the Solaris Admintool, which uses an insecure locking mechanism to allow simultaneous access, modification, and creation of files by various users. This vulnerability was exploited to create world-writable files that were owned by root.

In one of the laboratory configurations, source routing was left enabled by the system-administration team. This allowed a penetration team to launch a successful TCP spoofing attack. The attack was launched from the training machine, which was compromised by a penetration team, on the system-adminitration team's network. The attack exploited the fact that machines on the network, with the exception of the training machine, trusted each other.

From the training machine, the penetration team made a SYN flood attack against another system-administration team's machine. Then the penetration team, using the training machine, was able to impersonate the attacked machine and exploit its trusted relationship with other machines in the network. The penetration team used snoop to acquire TCP sequence numbers, and then as user bin established a connection with rshd on a target machine in the system-administration team's network. As user bin, they sent spoofed packet(s) containing the command cp /bin/sh /tmp/sh2; chmod 4755 /tmp/sh2 to the target machine. Next the penetration team found that the root crontab file on the target machine was world-readable and had an entry to run a bin-owned program. They modified this called program to create a root-owned, set-user-ID shell. Last but not least was the penetration team that used social engineering to acquire the root password — the incident we described at the beginning of this article.

Covering Their Tracks

Once a penetration team successfully exploited a vulnerability to acquire superuser privilege, it attempted to hide this activity from the system-administration team. Penetration teams normally changed the UNIX system log files, security tools, and the access and modification times of modified system files to cover their tracks. Some penetration teams, however, did not care if their attacks were detected. Instead, they concentrated on ensuring that the attack could not be traced back to their account. These penetration teams made their attacks by masquerading as other legitimate users.

Penetration teams used superuser privilege to remove their presence from the UNIX system log files. In particular, they removed their entries from wtmp, wtmpx, utmp, utmpx, and lastlog using a number of log-editor programs. Two such log-editor programs are UTClean.c and marry.c, which are available from <https://www.rootshell.com>. Other log files that were edited by the penetration teams were messages and sulog. Some teams locked the system log files using the command /usr/bin/chmod 000 at the beginning of every attack. Other teams linked system log files to /dev/null. Even worse, some penetration teams simply removed the log files or the entire /var directory. This action usually caused severe problems for the attacked machine.

In some configurations, the syslog facility was used to provide remote logging to a secure host. One penetration team used an attack to kill syslogd. This attack exploited a vulnerability of Solaris 2.5.1 — that syslogd will crash if it receives an external message from a sender with an unresolvable IP address. The details of this attack can be found in sol_syslog.txt, which is available from <https://www.rootshell.com>.

In addition to modifying the UNIX system log files, penetration teams also targeted the security tools installed by the system-administration team. One of the security tools modified was Tiger scripts by Doug Schales. A penetration team modified the system-administration team's copy of Tiger scripts so that it ignored the penetration team's root-owned, set-user-ID shells. Such attacks were successful because the system-administration teams left their security tools on the compromised host.

In order to hide changes they made to any system file, penetration teams modified the access and modification time of a file using the touch utility. The inode change time of a file was set to the time that the touch utility was used. The system-administration teams were, however, able to view the inode change time using the command ls -cl.

The penetration teams masqueraded as other users by stealing their passwords. The methods used to acquire user passwords included password cracking, password sniffing, X-Window spying, and Trojan-horse login programs. The students in penetration teams ran password-cracking tools against the world-readable /etc/passwd file. Some of the tools used were Crack by Alec Muffet and John the Ripper by Solar Designer. Penetration teams were also successful in sniffing passwords when they had superuser access on the same network as the system-administration teams machines and secure hubs were not used. The sniffers used by the penetration teams included tcpdump by Van Jacobson, snoop (which is packaged with Solaris), and sniffit by Brecht Claerhout. Some of the penetration teams wrote their own filters to analyze the data captured by sniffers. The program xkey, by Dominic Giampaolo, was used by one of the penetration teams to spy on users' sessions by capturing their keystrokes on an X server, with access control disabled. Some penetration team members used Trojan-horse login programs for /bin/login, /bin/rsh, and /bin/rlogin to capture user login IDs and passwords.

Leaving a Backdoor

In case the system-administration team detected and fixed the exploited vulnerability, the penetration teams left an alternate backdoor to gain superuser privilege on the system. The most common method was to leave a root-owned, set-user-ID shell as a hidden file or to modify the /etc/passwd file. Other backdoors included Trojan-horse programs and modified network services. Penetration teams also modified the boot startup scripts and cron schedules to create set-user-ID shells.

The most common backdoor was a root-owned, set-user-ID copy of /bin/sh. These shell programs were most often left in the penetration team's home directories, the /tmp directory, and scattered throughout the system as hidden files. The next most common backdoor was the modification of the /etc/passwd file. Penetration teams created user accounts with a user ID (UID) 0, which provided the account superuser privilege. A number of other modifications were made to the /etc/passwd file, including creating accounts without passwords, adding a password to the smtp account, and changing the root password.

A number of Trojan-horse programs, included Trojan login and su, were used as backdoors. Modified copies of login and su were installed in /usr/bin to grant superuser access to a predefined password. Rootkits usually provide these types of Trojan programs.

The network services were also a major target for the penetration teams. The tcp wrapper program by Wieste Venema provides access control of incoming network service requests for certain services using the hosts.allow and hosts.deny files. These files were modified by the penetration teams to allow certain network service requests that were denied by the system-administration team. Another team created its own network server, which started a root-owned copy of /bin/sh. This penetration team modified the /etc/inetd.conf file and /etc/services to add this network service to the system. They also added false comments and fake documentation for this service in order to make it appear legitimate. Another penetration team installed a fake lpsched daemon that was actually a remote procedure call (RPC) server running in the background as root, waiting to accept commands from a remote RPC client. The RPC server would accept the commands chmod 4755 /usr/bin/ksh or chmod 555 /usr/bin/ksh from the RPC client.

In case the system-administration team were to discover and remove their backdoors, some penetration teams left an alternate mode to gain superuser access. They modified the boot startup scripts and the cron schedule to create root-owned, set-user-ID shells. One team, for example, created a script called S21fsflush in the /etc/rc2.d/ directory. Other teams modified the root crontab file.

For More Information

If you are looking for more details on these attacks, a survey paper on the penetration tests performed during the 1995, 1997, and 1998 security classes that was presented at the SANS Network Security '98 Conference is available in the conference proceedings[2]. A version of the survey paper is also available online as a technical report, TR 98-021, from the Department of Computer Science at Texas A&M University.

If you are interested in starting your own laboratory to perform security vulnerability testing and analysis, we recommend that you read Marti, Bourne, and Fish's paper, "CPSC 665 Advanced Networking and Security Game Administration Plan"[4] and Bishop and Heberlein's paper, "An Isolated Network for Research"[1].

Acknowledgments

We would like to acknowledge the following students whose reports were analyzed for the compilation of this article:

1995 Class: B. Devalla, E. Mitchell, C. Schroeder, S. Sundaresan, R. Wood, P. Brutch, J. Jansen, L. Crotwell, D. Nash, Shiqian Yu, M. Woodings, Alex.

1997 Class: J. Bourne, D. Derrick, B. Fish, D. Ragsdale, S. Joshi, B. Goteti, S. Veluswamy, A. Madhwaraj, M. Sonaseth, D. Lazarova, Y. Feng, M. Guo, Q. Shi, W. Son, R. Agni, Sudhindra N., E. Khan, K. Kothandaraman, C. Standish, T. Brutch, P. Brutch, W. Marti.

1998 Class: X. Ma, L. Zheng, J. Zhao, W. Feng, H. Kim, M. Kulvicki, R. Mixer, R. Kaimal, S. Ramachandran, P. Dakshinamoorthy, S. Dhanekula, Y. Yu, T. Wang, Q. Zhou, J. Bourne, B. Fish, M. Hines.

References

[1] Bishop, M., and Herberlein, L. "An Isolated Network for Research." The 19th National Information Systems Security Conference. 1996.

[2] Brutch, P.; Brutch, T.; Mitchell, E.; and Pooch, U. "UNIX Penetration Tests: Attempts Performed During a Graduate Security Class at Texas A&M." SANS Network Security 98, Technical Conference Part 1, October 24-31, 1998.

[3] Kahn, C. "Using Independent Corroboration to Achieve Compromise Tolerance." 1998 Information Survivability Workshop, October 28-30, 1998.

[4] Marti, W.; Bourne, J.; and Fish, B. "CPSC 665 Advanced Networking and Security Game Administration Plan." WECS '98, Workshop on Education in Computer Security, 19-21 January 1998.