9.5 Unix Remote Information Services: rusers, rwho, finger & systat

9.5 Unix Remote Information Services: rusers, rwho, finger & systat

Syllabus item F1 is precise: "Discovery of valid usernames from network services commonly running by default: rusers, rwho, SMTP, finger." It then requires you to "understand how finger daemon derives the information that it returns, and hence how it can be abused." These are legacy services from the era of trusted campus networks, and they survive on Solaris, AIX, HP-UX, embedded appliances and unhardened Linux hosts. Every one of them hands out user information to anyone who asks.

The reason this matters is the username half of a credential. Password attacks (spraying, brute force) need a valid user list, and account-lockout policies mean you cannot afford to waste attempts on non-existent names. A confirmed username is worth as much as half the credential.

---

1. The finger Service (TCP 79)

finger (RFC 1288) was designed so users could look up each other's contact details and login status. fingerd listens on TCP port 79.

finger @target.example.com        # list all currently logged-in users
finger root@target.example.com    # detail for a specific account
finger admin@target.example.com

A response is rich:

Login     Name         TTY  Idle  When       Where
jsmith    John Smith   pts/0    2  Tue 09:14  10.20.31.117
oracle    Oracle User  pts/1   15  Tue 08:02  dbadmin-lt

How fingerd Derives Its Output — and Why That Is Abusable

This is the exact point the syllabus calls out. fingerd builds its answer from files it reads on the host:

• /etc/passwd — login name, the GECOS field (real name, office, phone), home directory and shell.
• utmp / wtmp — who is currently logged in, on which terminal, from where, and idle time.
• ~/.plan and ~/.project — free-text files in each user's home directory whose contents finger prints verbatim.
• lastlog — the last login time and source for each account.

Two abuses follow directly:

1. Username and account enumeration. Because the answer comes from /etc/passwd and utmp, finger user@host confirms whether an account exists, and finger @host dumps everyone currently logged in — including the source addresses they logged in from, which reveals administrator workstations and trust relationships. Some fingerd implementations even accept a query with no user or a wildcard, listing all known accounts.
2. Information disclosure and further abuse. The GECOS field leaks real names (feeding password guessing and social engineering) and phone/office data. The .plan file is attacker-influenced in some setups. Historically, fingerd also enabled the finger redirection / relay trick (finger user@host1@host2), using one host to finger another and bypassing source-address controls — and the original 1988 Morris Worm spread partly through a fingerd buffer overflow, the canonical example of the service's danger.

The idle and last-login data is valuable operationally: an account idle for months is a candidate for takeover with less chance of the real user noticing.

---

2. rwho and ruptime (UDP 513)

rwho shows who is logged in across every host on the local network. It depends on the rwhod daemon, which broadcasts each host's login state on UDP port 513 and listens for the broadcasts of its peers, caching them under /var/spool/rwho.

rwho              # all users on all hosts that broadcast rwhod
ruptime           # uptime, load and user count for each broadcasting host

ruptime reads the same cached data to report each host's uptime and load. The security problems:

• Passive disclosure. Because rwhod broadcasts, an attacker on the segment simply listens on UDP 513 and harvests a live map of every host, every logged-in user, and each host's uptime — with no query sent. Uptime is itself useful: a host with a very long uptime has not been rebooted and is therefore likely missing kernel patches.
• Broadcast amplification of the estate map. One rwhod gives you the whole broadcast domain's user population.

---

3. rusers and the RPC Family (portmapper 111)

rusers is the RPC-based equivalent of rwho. It is an ONC RPC service, program number 100002, and like all RPC services it is located by first querying the portmapper (rpcbind) on TCP/UDP port 111, which returns the dynamic port rusersd is actually listening on.

rpcinfo -p target.example.com          # enumerate RPC services and their ports
rusers -l target.example.com           # long listing: users, TTYs, idle times
rusers -al 10.20.30.0                   # -a includes hosts with no users logged in

sysadmin  target:pts/0    Sep 14 09:14   :22
backup    target:pts/2    Sep 14 03:00  1:47

The related RPC/legacy services in the same family, all named or implied by the syllabus:

rstatd deserves a note: its performance data reveals when a host is busy or idle, letting an attacker time activity for low-observation windows, and older rstatd implementations carried remote format-string vulnerabilities.

The systat service (TCP 11) is the bluntest of all — connecting to it runs a who-style command and returns the live user and process listing directly, no client tool required:

nc target.example.com 11        # systat: dumps who/process output
nc target.example.com 15        # netstat service: dumps connection table

---

4. Chaining Into a Username List

 finger @host        -> currently logged-in users + real names + source hosts
 finger user@host    -> confirm/deny a specific account
 rwho / rusers       -> users across the whole segment
 systat (TCP 11)     -> live who/process output
 rstatd              -> when the host is busy (timing) 
        |
        v
  Consolidated, de-duplicated username list
        |
        v
 SMTP VRFY/EXPN (section 9.2)  -> confirm which names are valid mail recipients
        |
        v
 Password spraying / targeted brute force (mindful of lockout)

The value of F1 is that these services build the input to the credential-attack phase. A single finger @host can name every administrator and the workstation each logs in from; combined with GECOS real names it also seeds a realistic phishing campaign.

---

5. Detection, Reporting and Remediation

These services are almost never needed on a modern network, so the finding and the fix are simple:

• Confirm exposure with nmap -p 11,15,79,512,513,514 <target> for the TCP/UDP legacy services and rpcinfo -p <target> for the RPC family.
• Report the specific disclosure, not just "finger is enabled": name the accounts, real names and source hosts the service actually revealed, because that evidence is what conveys the risk.
• Remediate by disabling the services entirely — remove fingerd, rwhod, rusersd, rstatd and the systat/netstat inetd entries; where a legitimate need exists, restrict them by firewall to management hosts only. Modern equivalents (SSH, monitoring agents with authentication) replace every legitimate use.
• Treat username disclosure as a real finding even without a password, because it removes lockout-safe target selection and directly enables spraying and phishing.