spacer.png, 0 kB
spacer.png, 0 kB
Home arrow All Articles arrow Hacking Articles arrow Session hijack script

Subscribe to our news and articles by RSS or by email
Session hijack script Print E-mail
This demonstration involves three hosts: attacker, victim, and target.
  • 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.

Attacker: Determining the IP addresses of target and victim systems. This can be easily done with utilities like
finger, systat, rwho.

--------------------------------------------------------------------------------

Attacker: Runs hunt as root on attacking host. Then he Waits for hunt to indicate a session has been detected


Attacker: Then he 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 shell.

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

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.

 



Related Items:

 
< Prev   Next >
spacer.png, 0 kB
spacer.png, 0 kB
spacer.png, 0 kB