The r-commands authenticate only during connection setup, after which the session is an unauthenticated cleartext TCP stream. An attacker who captures or sits on that stream exploits this two ways. The direct and reliable one is live session hijacking: reading the cleartext stream to learn the TCP sequence/ack state and injecting segments carrying commands the server executes as the authenticated user. The second is replay of captured exchanges where the server does not prevent it. Both execute commands without defeating authentication, by riding a session another party established, and a single injected command can plant durable trust.
# live hijack: on-path, read seq/ack from the cleartext stream, inject a command
# e.g. append trust so later access needs no interception
# echo "+ +" >> ~/.rhosts
# classic tools (Hunt, Juggernaut) automated rsh/rlogin TCP hijacking; modern
# exploitation crafts the injection segments directly from the observed stream.
Exploitation notes#
- Live hijacking is the practical form: inject one command (plant
.rhosts, add a user, start a reverse shell) into the established session, running as the authenticated user, often administrative on legacy Unix. - A quiet single-command injection is preferred over a full takeover, which desynchronises and may alert the user.
- It needs only an on-path position and the cleartext stream, no credential or trust; it is the active counterpart to command interception and the same technique as rlogin session hijacking and Telnet.
- The shared cleartext, setup-only-authentication design across rsh/rlogin/rexec is the root cause enabling all interception and replay.