UnixWorld Online: Internet Security: Column No. 002

Danger!

Hopefully, you are already beginning to notice some red flags flying. For one thing, allowing users to create their own ~/.rhosts file means that any user can share his or her account with any other user with no password. Sharing accounts is never a good idea, and letting your users arrange this on their own is an even worse idea. I suggest that you decide whether to allow this or not, and make it part of your local security policy. You can enforce this by having the cron daemon run a shell script which looks for .rhosts files in all home directories, mails a copy of any such file to root, remove the file, and mail a warning to the user.

Even arranging for trust with the /etc/hosts.equiv file is not safe. Remember that I said there were three machines, but have so far left out boffo. Suppose the administrator of violet doesn't trust boffo, but daisy's admin does. So a user from boffo can log into daisy, and then from there log into a similarly-named account on violet-- even though violet's configuration file would deny this. Trust is transitive. When setting up a trust arrangement, it is essential that trust not be extended to any system outside the local ring of trusted systems.

Sun Microsystems has participated in one of the darker moments in UNIX system security. In all releases of SunOS, including the latest (4.1.4), and the first several releases of Solaris 2.x (but not including 2.3), the /etc/hosts.equiv file included with the distribution contains only a single visible character, the plus sign (+). The plus sign is the wild card, and means that a newly installed Sun system running SunOS trusts any user (except root) on any host. While most systems won't have an account for rik or guest on them, they will have standard accounts, such as bin. Thus, an intruder could log into any Sun system (which hadn't been correctly configured) as the bin user, across the network, with no password.

Was Sun trying to make their systems insecure intentionally? No, although they certainly succeeded. Having the plus sign just made newly installed Sun workstations easier to use on a network. If you have Sun systems, check for the plus sign in /etc/hosts.equiv anywhere in the file by itself at the beginning of a line. A plus sign in front of a hostname is okay (but not necessary). The plus sign works the same way on any system that supports the ``r'' commands, and you should delete it if found (or trust everyone). A minus sign denies access. You could have a /etc/hosts.equiv file with just a minus sign, and deny access.

Of course, if this were the only problem, things wouldn't be too bad. The rlogin command does have a bright side. When trust is extended, no password is sent across the network, so password sniffing programs will fail. You might also be using ``r'' commands locally to aid in system administration. What you should not do is allow use of the ``r'' commands between networks which you do not control and therefore, can't trust.

Internet Invaders

Someone who wishes to break into a UNIX system will often search for trust relationships. Kevin Mitnick did this (see my last column), and this is not uncommon. Or suppose that a person running a password sniffer captures the packets showing the use of rlogin without a password. The sniff file includes the name of the local and remote hosts, and the account name. To login, all they have to do is fake his or her own host name and account name. The ``r'' servers rely on the names found in the rlogin request to determine if the request will be permitted or denied. If the server blindly trusts this information, then the attacker can login with no password.

Modern ``r'' servers include a reverse name lookup. That is, they use the source IP address and convert it to a hostname using gethostbyaddr(). If the hostname discovered by converting the IP address doesn't match the name in the rlogin packet, access is denied. Sun systems do this, but is it sufficient? Nope. The attacker probably controls the remote system, and can tell the Domain Name System there to lie (see Steven Bellovin's paper ``Using DNS for System Break-ins'' in the Proceedings of the Fifth Usenix Security Symposium).

Or, in another attack, the attacker uses initial sequence number guessing (see my last column) and sends packets to the ``r'' server without ever receiving a reply. This is the form of IP address spoofing used by Kevin Mitnick in his Christmas Day attack.

There are a couple of things you can do to prevent these attacks. One is to block packets destined for the ``r'' commands from ever entering your network. The ``r'' servers listen at ports 512 (rexec, used by rcp), 513 (rlogin), and 514 (rsh). These are connection-oriented services, and use the TCP protocol. Blocking these with a packet filtering router is relatively easy to do. Firewalls based on proxy servers typically block these by default.

You can also defend individual systems by turning off these services if you don't intend to use them. The /etc/inetd.conf file contains entries for each of these services (see Listing 2). You disable these services by putting a octothorp (pound sign or #) at the beginning of the line, and sending a hangup signal (SIGHUP, use kill -HUP) to the inetd process.

The ``r'' commands are certainly convenient. You can do tricks with them, for example, access a remote tape drive as if it were local by using rsh to drive dd.

But the lack of strong authentication is a terrible weakness. Newer versions of the ``r'' commands include support for Kerberos IV, which means if you are using Kerberos you could use the ``r'' commands in relative safety. If not, it is time to make some decisions about your site, or at least the systems under your control, about supporting these utilities. And check those Suns. Remember that any system you have upgraded to a later version of SunOS may have the plus sign in /etc/hosts.equiv (unless you overwrote it with your own file during installation.)