inetd Services

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 +

Table 9-1. Common Names for UNIX Configuration Files

File Name File Name

.rhosts /etc/services

cron.allow /etc/inetd.conf

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.

Table 9-2. Sample Failed Password Attempts 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.