Like the other r-commands, rsh provides no encryption, so an attacker on the path reads the entire exchange: the command executed, its full output, and any data transferred. Because rsh commonly relies on host-based trust rather than passwords, the prize is usually the command and output (which often include sensitive data or secondary credentials the command handles) rather than a login password, but where password authentication is in play it is captured too. The unauthenticated-after-setup TCP stream is also hijackable, matching the Telnet/rlogin session-takeover technique.
# capture rsh traffic from an on-path position
tcpdump -i eth0 -A port 514 -w rsh.pcap
# follow the TCP stream to read the command, output, and any data/credentials
tshark -r rsh.pcap -q -z follow,tcp,ascii,0
Exploitation notes#
- The main capture value is the command and its output, which frequently carry sensitive data or secondary credentials; host-trust rsh often has no password to sniff, so content is the target.
- The stream is hijackable (inject a command into the established TCP session), the same technique as rlogin session hijacking and Telnet; a single injected command can plant durable
.rhoststrust. - Needs an on-path or tap position; r-commands on a flat legacy segment are readily intercepted.
- This is the shared cleartext weakness of all r-commands; see the traffic-interception group for the cross-command treatment.