Session hijack script

• 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 secondary 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:

1. 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.

   ---

2. 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 "*>").

3. Attacker: Starts ARP relay daemon, prepares RST daemon entry for use later, sets option to enable host name resolution (for convenience).

   ---

4. Victim: Logs in to target using telnet. Runs pine to read/compose email.

5. 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.

6. 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.

7. Attacker: Finds this is a user session and decides to give it back (resynchronizes TCP/IP stream).

8. Victim: Sees prompt for keystrokes, follows request, gets session back. Puzzled, decides to log in to root account to take a closer look.

   ---

9. Attacker: Turns on RST daemon to prevent new connections, waits to hijack root session.

10. Victim: Runs ssu to get SecurID protected root shell.

11. Attacker: Completes hijack after seeing root login.

12. 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.

13. Attacker: Sets up backdoor, disables command history, resets session, turns off RST daemon.

14. 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 "normal").

    ---

15. 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.