6 Days Left to Save $400 on SANSFIRE 2017

IDFAQ: Do telnet and rlogin increase the risk of compromise?

Answer: YES. But telnet and rlogin are not the only two programs that increase the risk to a site. Any other program that allows incoming connections and does not have the ability to encrypt it's data is a risk. Some examples are ftp, pop and older versions of sendmail. Sniffers can easily pick off passwords transmitted in plain-text from any of these programs. And the problems with anonymous ftp could easily take up a few paragraphs. In addition, there are still vendors that ship their software with non-passworded accounts by default, which is yet another risk. However, this question was explicitly aimed at telnet and rlogin so let's just stick to those for now.

telnet is used to make connections between machines on a network. By default, telnet tries to connect to the remote host using Port 23. But telnet has the ability to connect to any port that has a valid listener. telnet can be used to spoof or exploit valid protocols. One old example that comes to mind is the WIZ command that used to exist in sendmail. One could telnet to the sendmail port, start up a conversation with the remote sendmail daemon and drop oneself into root fairly trivially. Other examples are the stack overflows of various other programs that are started by the internet server inetd. Although these examples are exploits of other valid programs, the means to get to them is via telnet.

Some versions of telnet have the ability to execute non-interactive commands. If a .telnetrc file exists on the remote machine, then telnet commands in that file will be executed as if they were typed in manually at the telnet prompt. There are versions of telnet that can use Kerberos authentication, and some that can use encryption, but that is still the exception. Check your manual page to see if your version of telnet will support Kerberos authentication or encryption. Without encryption, telnet sends all commands in plaintext, making telnet sessions easy fodder for packet sniffer programs.

If your version of the telnet daemon telnetd has been built with support for authentication or encryption, then those options can be enabled in the /etc/inetd.conf file, giving a slightly more secure telnet. Whether or not your telnetd supports authentication or encryption, telnet should be wrapped via a wrapper program like TCPWrappers to at least enable some tracking of connections. Using wrappers will also allow you to restrict incoming telnet connections using the /etc/hosts.allow and /etc/hosts.deny files. Since telnet is often the target of port-scanning software, a vigilant SysAdmin could comb the logs and subsequently disallow connections from sites or domains that no one should be connecting from.

Here's a listing of past telnet exploits, courtesy of rootshell :

5/7/98 many 3com switches contain an undocumented backdoor telnet password
3/16/98 how to exploit the old Telnetd Environment Vulnerability underDEC OSF/1 (v2.0 - V3.2c)
11/21/97 libcrypt.so/ _RDL_ROOT telnetd env var root exploit for irixsystems
11/12/97 source routing telnet
8/17/97 program to attack a solaris 2.5 box making it totaddy unresponsive
7/17/97 set of perl scripts to run ftp and telnet commands across afirewall
  how to allocate a port and set up a telnet gateway making itdifficult to trace telnets
  get part of the shadow file w/ cores on Linux
6/12/97 'reverse telnet' from a box behind a firewall that allowsICMP packets
1/30/97 obscurity layer for telnet based logins
9/4/96 hacked telnet aaemon that gives a root shell w/o password
8/26/96 create a shared library that gives a root shell locally orremotely
2/13/96 allocate a port and set up a telnet gateway making it difficultto trace telnets. exploits a world-writeable /etc/utmp and allowthe user to modify it interactively. programs like ps ls &du that are modified to hide certain files & processes

Now for rlogin. rlogin is part of the r-command package that also includes rsh and rexec. The really scary part about rlogin/rsh is that if an /etc/hosts.equivM file exists on the system or the user has a .rhosts file, then no password is needed for the user. One of the gaping security holes that comes to mind with this one is the vendor that shipped their operating system with "+" in the /etc/hosts.equivM (trusted hosts) file. [The + is an NIS or YP convention.] The .rhosts and /etc/hosts.equivM files can give a cracker access to other machines easier than any other method. Modern cracker scripts still search for .rhosts files and /etc/hosts.equivM files on systems to get a topology of trusted hosts. They then use those accounts and machines to propagate their cracking activities.

Newer versions of rlogin also exist that employ authentication and encryption, and if yours is compiled with that support, you are highly encouraged to use it. As with telnet, those options can be enabled for the rlogind daemon in the /etc/inetd.conffile, giving a more secure rlogin. Regardless, if you allow rlogin connections you should wrap ALL your r-commands started in /etc/inetd.confwith a wrapper program like TCPWrappers and discourage the use of .rhosts, maybe even setting up a script to prune .rhosts files from your system on an hourly basis.

Here's a listing of past r-command exploits, courtesy of rootshell:

11/21/97 exploit for Digital Unix v4.0 that let's you create a writeable/.rhosts file
7/19/97 rexecd can be used easily to scan the client host from theserver host
6/14/97 figure out valid usernames by examining the response from in.rshd
4/19/97 /tmp/.asppp.fifo can make a world writeable .rhosts file onSolaris 2.5x86
2/24/97 if you have access to uid 65535 (nobody) then root can be obtainedon Linux systems
1/30/97 overwrite a buffer in gethostbyame() on Solaris 2.5.1 and givea root shell
 rexecd allows redirection of stderr stream to an arbitrary port onclient machine
 pine exploit that can be used to create .rhosts files
1/7/97 hpjetadmin can be tricked giving away root by a writeable .rhostsfile
9/9/96 Admintool can be used to create a writeable /.rhosts file onSolaris 2.5

Even better would be to install the SSH package, which is a more secure replacement for rlogin/rsh/rcp. And then turn off BOTH rlogin and telnet in your /etc/inetd.conf file.

Laurie Zirkle, CSE