| I l@ve RuBoard | |
When you have identified a particular UNIX host as your target, and have, through footprinting, determined the type, version, and patch level as well as the list of open ports and active listening services, you are ready to develop your penetration-testing strategy. The strategy generally is, as mentioned previously, to exploit a listening service to gain remote access, followed by attempts to raise your privilege level to the end goal of gaining root. It is entirely possible that you will be able to remotely execute an attack that directly gives you a root shell.
Among the listening services we examine are those started at boot by the inetd.conf file. These can include finger, echo, telnet, FTP, and SNMP services that run on well-known ports, as well as r services, such as rexec, rstatd, rquotad, and so on.
Inetd services do offer windows of opportunity to compromise a network and should not be overlooked because they are “common” services. Common services are usually under more intense scrutiny for vulnerabilities. It is possible that the administrator has not yet had the opportunity to implement secure versions of these services. Even if the services have been secured, it may still be possible to use these services to either compromise the system directly (connecting to systems through user accounts with weak passwords using telnet or FTP) or to gather information that can be used to compromise the network (such as SNMP information or user information through finger).
For example, one of the first things we attempt to do is connect to any listening service either through Netcat or its usual communications channel. In other words, we use telnet, FTP, and SSH from the command line to connect to ports 23, 21, and 22, respectively. At this point, we attempt to access only generic accounts, such as root, guest, and test, or default accounts for applications such as webmaster, oracle, or maestro. If we attempt to log in with manufactured or made-up user names, we increase the chance of drawing unwanted attention to ourselves.
If we are able to get in through any of these listening services, we then attempt to read critical system files, such as the password or shadow password files (generally /etc/passwd and /etc/shadow, respectively) to get the list of valid user accounts. These password files may require root access, especially the /etc/shadow file. We may not be able to read the shadow password file, but we can identify whether it exists; and therefore, we will know whether the passwords are shadowed. If we can capture these files, we can work on cracking the passwords offline with the aid of a UNIX password-cracking tool, such as John the Ripper or Crack. (These tools are described in Chapter 15.) If the shadow password file is used and we can access only the /etc/passwd file, we can at least determine the users on the system. We also attempt to look for log files and core dump files.
In addition to password files, we examine configuration files (given our time constraints) to determine what the host is doing and which services are running. The names of the files may well be different on different UNIX flavors, but Table 9-1 contains a general list of some of the files we look for.
The .rhosts file lists the user names and the host machines from which they can access r services, including rlogin, rcp, and rsh, on the local host. The cron and At files tell us what, if anything, is being performed on a regular and automatic basis. The /etc/.login file tells us what actions are performed when a user logs into the host. The /etc/.profile file defines the individual user profile. These files can be found within each user's home directory. The /etc/shells file lists all available shells. The /etc/securetty file indicates to which TTY device the root user can log in.
The /etc/hosts.equiv file lists remote hosts and users that are trusted on the local host, meaning that they can access the local host without a password. This file is of the form:
hostname username
A + sign in either space acts as a wild card meaning, essentially, “any.” In other words, a line in the file such as the following:
hostname +
| File Name | File Name |
|---|---|
| .rhosts | /etc/services |
| cron.allow | /etc/inetd.conf |
| cron.deny | /etc/hosts.deny |
| At.allow | /etc/hosts.allow |
| At.deny | /etc/dialups |
| crontabs | /etc/exports |
| Tabs | /etc/netgroup |
| Cron | /etc/ttys |
| /etc/.login | /etc/gettytab |
| /etc/.profile | /etc/termcap |
| /etc/group | /etc/default/audit |
| /etc/shells | /etc/dfs/dfstab |
| /etc/.cshrc | /usr/adm/sulog |
| /etc/securetty | /usr/adm/lastlog |
| /etc/hosts.equiv |
means any user on the specified remote host is trusted on the local host. Also, the listing:
+ username
means the specified user is trusted from any host in the domain. Needless to say, care must be taken when writing this file. It can often be a source of great vulnerability since it potentially allows users to bypass the password authentication mechanisms in place. This file is similar to the .rhosts file, except the /etc/hosts.equiv file operates on a domain-level basis and .rhosts on a user-level basis. Each user can have an .rhosts file within his or her home directory.
The /etc/inetd.conf file lists a majority of the services and applications that are running and automatically started by the host. It is useful to compare this file with the results of a port scan. If an open port for a well-known service is running but that service has been commented out of the inetd.conf file, then a rogue service may be running on that port.
The /etc/hosts.allow file lists the names of all hosts allowed to use the local inet services. Similarly, the /etc/hosts.deny file lists hosts explicitly denied this privilege.
The /etc/dialups file is a listing of the terminal devices that require password authentication (separate from the normal user password authentication) before granting a modem connection. Naturally, this applies to boxes on which modems are listening for incoming connections. The passwords may be stored in the /etc/d_passwd file and should be different from the user passwords stored in /etc/password.
The /etc/exports file lists all directories exported by Network File System (NFS). If any directories are being exported, and if NFS is in use, we try to connect to and peruse any exported directories, as discussed below. The /etc/netgroup file offers hints to permissions in place on the network. It is a listing of network-wide groups and their membership and can be valuable for determining which users have access to what domains and machines.
The /etc/default/audit file contains some default parameters regarding auditing on the local host.
We also attempt to look for log files, such as /usr/adm/sulog and /usr/adm/lastlog. There may be a large collection of log files on UNIX systems, anything from logs of failed passwords to logs regarding the boot process. These are stored in various places on various UNIX flavors, so we generally run the find command to identify all files with “log” in the file name. Log files can also be stored by the date; therefore, searching for file names containing the current day of the month (either numerical or the word) can reveal the most recent logs.
The purpose of reading the logs is to get a sense of what the system is doing. Occasionally, you may be able to find a log of failed login attempts, including the incorrect password. Even failed password attempts can be helpful since they likely contain failed passwords that were merely mistyped by one or two characters. Seeing such failed password strings can often reveal the real password. For example, try to determine the correct password for each of the failed passwords shown in Table 9-2.
The correct passwords are, in order, redskins, Yellowstone, tr@demark, kN0ckN0ck, HOCKEY1, and zak_987. Sometimes passwords are quite simple to ascertain from the failed passwords, as in tr2demark, where the number 2 was intended to be the @ sign. Other common mistakes are to forget to capitalize certain or all letters, as in HOCKEY1. In addition, holding down the shift key for one letter too many often causes overcapitalization or turns numbers into the special characters that are on top of them, as in kN0ckN0ck.
| Failed Password |
|---|
| rewdskins |
| yelloqatone |
| tr2demark |
| Kn)ckN)ck |
| hockey1 |
| Zak987 |
We also look for core dump files on target hosts. These files can be found by searching for files with “core” in the name (often, the name is simply “core”). Leaving core dump files on hosts also presents a possible vulnerability. These files are usually generated when a segmentation fault occurs during normal system usage that results in memory being written to a file (for example, the core being dumped), or during buffer overflows as well as other attacks on the network. The FTP PASV attack is an example of an attack that can lead to a core dump. By remotely executing the PASV command, it is possible to have the FTP service open ports on the firewall for inbound or two-way communication. Additionally, this can be used to create a denial-of-service condition by continually requesting that ports be opened when there are no additional ports to open. In this process, core files can be created on the target system.
Core files contain whatever is in system memory at the time the file is generated. Looking through these files may reveal password hashes and other sensitive information (including IP addresses of other hosts on the network), indicate a partial listing of services and applications running, and illuminate the directory structure (often the path to log files and other configuration files is identified).
Core files can also be located anywhere on the system, and we search for these with the find command as well. Core files are very long, and there may be a relatively large number of them on a system. Looking through these does require a time commitment. We generally take a first pass at these files with the UNIX strings command and take a closer look at any that appear more promising.
As a countermeasure, core files should be removed from the network as soon as possible. It may even be possible to limit their creation through the ulimit command. To preserve these files offline, consider keeping them in a tar file off the network.
We may also look at personal files and read the user's e-mail. However, the amount we peruse a user's file system depends on the policy we sign with the client and the need for network access types of information.
If UDP port 161 is open, we can attempt SNMP queries in order to gather SNMP information. This can be done from the command line (for example, with the snmpwalk command) or with automated tools (for example, NetScanTools by Northwest Performance Software, IP Network Browser, and SNMP Brute Force Attack from SolarWinds). SNMP Brute Force Attack has the advantage that it can brute force the community strings. SNMP may yield read or write access. With read access we can determine the hosts and applications running on the target network. With write access, it is possible to manipulate this information and possibly confuse machines on the target network. While penetration testing, we do not change SNMP information since it could make the target unusable. For example, changing an IP address or route on a remote machine could make it unreachable.
If TCP port 25 is open, it generally signals the presence of sendmail or another e-mail server. Similarly, if HTTP port 80 is open, a Web server may also be running. (Ways to compromise these servers are discussed in Section 9.4.)
As a side note, while it is possible to stumble across a system in which the root password is “root” (or another easy-to-guess password, such as a derivation of the host name or company name), this is becoming less and less likely. In many cases, root is not permitted to log in remotely and can only log in from the workstation itself. In other cases (recommended), root is not permitted to log in at all. The root-level users must log in to their own accounts and then su to root. This grants them root privileges while allowing a record to be kept of who accessed root and at what time.
Remote services, or r services, are also started by the /etc/inetd.conf file and are also frequent targets of attack. r services, including rexec, rwhod, rshd, and rlogin, sport their fair share of exploits. rlogin, a SUID root program, has been famous for poor programming that leaves it susceptible to a buffer overflow condition, either allowing the attacker (here the individual calling the rlogin service) to execute arbitrary code as root on the target system or giving the attacker a root shell directly. One such code distributed over the Internet, called rlogin-exploit.c, overflows the gethostbyname() buffer, resulting in a root shell being generated. This particular exploit has been coded for instances of rlogin running on Solaris 2.5/2.5.1.
r services can be disabled by commenting them out of the inetd.conf file on most UNIX flavors. Many of these services are installed by default and simply need to be commented out if they are not going to be used.
This raises the question: why are these r services installed in the first place? Originally, as networks and networking concepts in general were being developed, developers envisioned several potential uses for this functionality. At that time, security was not a significant concern. Today, the risks are generally greater than the potential benefits. The functionality can usually be replaced with other similar yet more secure alternatives. For example, rlogin was a tool designed to allow users to remotely log in to hosts across a network (and potentially without a password if the user is known on the remote host). In addition, rlogin passes data over the network in clear text, so it is not recommended from a security perspective. rlogin (as well as telnet) functionality can be replaced with the more secure SSH. SSH allows users to log in to other hosts with a password and encrypts the traffic.
Other r services provide functionality that simply may not be necessary. For example, rsh opens a remote shell on the local host and allows users to execute commands on that remote host. This is undesirable from a security perspective.
UNIX systems can also have a collection of Remote Procedure Call (RPC) services for which several holes exist and additional holes are found on a regular basis. For example, the rpc.ypupdated service performs insufficient user authentication and may allow remote users to execute commands as root on susceptible target hosts. The rpc.ttdbserverd service allows remote users to exploit a buffer overflow condition in the ToolTalk database and either escalate privileges or gain unauthorized access.
The rpc.mountd service has been found vulnerable to several buffer overflows and also may allow remote users to map the target directory structure. Mountd is the server for the NFS service that is common on most UNIX systems. NFS is an RPC service that provides the capability to export file systems across the network and is a popular hacker target. When we find NFS running on a target host, we attempt to mount any exported directories. It is not uncommon to find sensitive directories, or even the "/" directory, that is, the entire directory structure, exported to everyone. This allows anyone who can connect to the host to view any file on the system, depending on the file permission settings. Mounting exported directories can be done from the command line, as well as with the nfsshell tool discussed in Section 9.6.
In addition to taking advantage of any user misconfigurations in NFS, there are a host of exploits available as well. For example, on Red Hat Linux version 4.x or 5.x with read/write access to an exported directory, it is possible to cause an overflow in the buffer associated with the path name to the directory upon removing the directory. Therefore, the process is to first create a directory with a very long name and then attempt to remove it through NFS (for example, over FTP). If successful, the attacker could cause arbitrary commands to be executed as the user under which NFS runs (likely, root). This is essentially a bounds-checking error that can result in root access.
There are sufficient vulnerabilities identified with NFS that make it better to simply disable it. Since NFS is generally started by the inetd.conf file or an rc script, disabling it involves commenting it from the appropriate source. If it must be used, it's important to ensure that only necessary directories are exported and with the correct permissions. Further, the users to whom the directories are exported should be listed by fully qualified host names to help avoid misidentification. These settings generally appear in the /etc/export file.
Additional RPC vulnerabilities include the remote exploits for rpc.autofsd designed to create a root shell on a specific port (530). This exploit is more specifically designed for the BSD OS. Of lesser direct consequence is the vulnerability in rpc.statd allowing remote attackers to place Trojans on the target system. Rpc.statd can also allow hackers to delete files that require root level permission to delete. Exploit code for these and other RPC services can easily be found on numerous sites throughout the Internet. The most effective countermeasure is to comment these services out in the inetd.conf file and block all unnecessary ports at the firewall.
| I l@ve RuBoard | |