Problems with rlogin

As mentioned earlier, on a machine with any server for programs in the rlogin protocol family it is critical that only the user can modify his or her rhosts file. If it is possible for someone else to modify it then the ability to modify it can be leveraged into the ability to obtain full access to the account. Note that if your home directory is on an NFS mounted file system exported to someone else’s machine your rhosts file is vulnerable to simple attacks on NFS. A standard attack for the superuser of another machine is to give you an account on the other machine and then use the su command to gain access to your account on the other machine. The NFS server is fooled into believing you are accessing your files because it trusts the other machine to authenticate its users. So far, the attacker is limited to accessing your files, but when he alters your rhosts file the attacker can begin to run programs that execute with your privileges and do greater harm.

If an attacker is able to modify the superuser rlogin file or gain access to any account listed in it, such access can be leveraged into a very serious attack. In particular, an attacker can use rsh to subvert the requirement that Unix superuser logins occur from secure terminals. Unlike rlogin or Telnet, rsh does not require a pseudo-tty. If protection of your superuser login account involves restricting insecure terminals, you may want to disable or alter the rsh program.

---

Warning:  If security bells aren’t ringing in your head by now, this warning is your second chance. While rlogin makes things incredibly easy for the user, it also makes things easy for the hacker because the rlogin protocol completely misses the fundamental security concept of authentication. The reason rlogin avoids the transmission of any form of a password is because it proceeds to establish a terminal session based solely upon identification without authentication. On the Internet today, it is dangerous to deploy applications and protocols based upon the academic notion of trust developed in the early days of Unix. See “A Cautionary Tale” in RFC 1282, BSD Rlogin.

---

Do not confuse the rexec commands (rexec and rcmd) with the r-commands. The rexec daemon waits for a user name and cleartext password to authenticate a client. It will then execute a single shell command. Although this is similar to rsh, rexec requires the transmission of a cleartext password to be sniffed. Also, it provides two distinct error conditions, one for an invalid user name and one for an invalid password. Hence, a brute-force attack can be mounted by attempting all possible user names to both determine what user names are valid and which users have no password. A standard login program will not provide this distinction and provide a mechanism to prevent rapid-fire attempts to log in. Security-conscious system administrators often disable the rexec daemon and rexec commands because users don’t know that they shouldn’t be missed.

Using Encrypted Passwords

Another solution is to use encrypted passwords over the network. You must use caution, however, when simplifying this technique. Even with encryption, a sniffer can still record the encrypted password and decipher it at his or her leisure. It also does not suffice to simply encrypt the password with an algorithm using a key that allows an attacker to determine the encryption key. The attacker would decrypt it for repeated use at a later time. Some protocols use an encryption technique equivalent to the one used by the Unix password program when it stores passwords in the password file. This encryption technique is no longer considered particularly secure against brute force cryptographic attacks where all likely passwords are encrypted with the same algorithm used by the password file. Any two words that encrypt the same must be the same. Hence, poorly chosen (for example, dictionary words) or short passwords are particularly easy to crack by brute force.

What is required is the use of public key cryptography such as the RSA cryptosystem used in PGP (see Chapter 11, “PGP”). In public key cryptography (also called asymmetric cryptography), you use separate keys for encryption and decryption—the decryption key is not computable from the encryption key. The server can send the client its public key and the client can use that key to encrypt the user password. The server then decrypts the password to verify the authenticity of the user. This is a variation on the classic public key system in which a trustworthy third party holds the public keys, but it simplifies the case when no mutually trusted third party is available. It also allows the server to use a time-dependent public key to prevent password replay or brute force decryption of a relatively short password.

---

Note:  SRA from Texas A&M provides Telnet and FTP without cleartext password exchange. It uses Secure RPC (Remote Procedure Call) authentication. Secure RPC is part of the Sun RPC package distributed along with Secure NFS by many vendors and is quite common on Unix systems. Secure RPC uses public key cryptography using the patented Diffy-Hellman algorithm. SRA uses a new random secret key/public key pair for each connection eliminating the need for a separate key server.

SRA can be obtained at ftp://coast.cs.purdue.edu/pub/tools/unix/SRA/TAMU.

---

The use of Kerberos also prevents cleartext passwords from being sent across the network. Kerberos is a comprehensive authentication system using a sophisticated time varying encryption algorithm and requires that both systems at the ends of a communication connection trust a separate security server to negotiate the authentication. This avoids having servers trust clients to do the authentication, as the rlogin protocol must do. See Chapter 9, “Kerberos,” for more information on Kerberos.