Session hijack script
This demonstration involves three hosts: attacker, victim,
A simple diagram of the network shows the attacker and
victim hosts are on the same network (which can be ethernet
switched and the attack will still work), while the target
system can be anywhere. (Actually, either victim or
target can be on the same network as attacker: it
- attacker is the system used by the attacker for the hijack.
- victim is the system used by the victim for
telnet client connections to the target system.
- target is the target system that the intruder wants to
compromise. It is where the telnetd daemon is running.
For the attack to succeed, the victim must use telnet,
rlogin, ftp, or any other non-encrypted TCP/IP
utility. Use of SecurID card, or other token based second factor
authentication is useless as protection against hijacking, as the
attacker can simply wait until after the user authenticates,
then hijack the session.
The attack scenario can be as simple as:
- Attacker: Spends some time determining the IP addresses
of target and victim systems. Determining trust
relationships can be easily done with utilities like SATAN,
finger, systat, rwho or running
who, ps, or last from previously
stolen (or wide open "guest" style) accounts.
- Attacker: Runs hunt as root on attacking host.
Waits for hunt to indicate a session has been detected
(hunt will note a new session by changing its prompt
from "->" to "*>").
- Attacker: Starts ARP relay daemon, prepares RST daemon
entry for use later, sets option to enable
host name resolution (for convenience).
- Victim: Logs in to target using telnet. Runs
pine to read/compose email.
- Attacker: Sees new connection; lists active connections
to see if this one is potentially "interesting." If it is,
attacker can either watch the session (packet sniffing) or
hijack the session. Decides to hijack.
- Victim: Sees strange new prompt. Tries pressing RETURN
and doesn't know what to think. Tries web browser and notices
that it still works fine (not a network problem). Not sure
what to think.
- Attacker: Finds this is a user session and
decides to give it back (resynchronizes TCP/IP stream).
- Victim: Sees prompt for keystrokes, follows request,
gets session back. Puzzled, decides to log in to root account
to take a closer look.
- Attacker: Turns on RST daemon to prevent new connections,
waits to hijack root session.
- Victim: Runs ssu to get SecurID protected root
- Attacker: Completes hijack after seeing root login.
- Victim: Sees strange prompt. Tries pressing RETURN
again. Same result as before. Tries web browser again. Same
thing. Tries getting a new telnet session. Fails.
Tries ftp. Fails.
- Attacker: Sets up backdoor, disables command history,
resets session, turns off RST daemon.
- Victim: Finally gets a new session. Original session is
now gone. Assumes network outage or Windows TCP/IP stack
corruption. Reboots system and everything is back to
- Attacker: Waits for admin's sessions to all disappear (gone
home for the night), then logs in using new backdoor. Installs
rootkit (more backdoors, sniffer), cleans log files.
Last modified: Thu Dec 9 21:03:56 PST 1999