| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1.4.6 TCP/IP Hijacking Hijacking involves the attacker forcibly taking control of a legitimate conversation between a server and a client, much as a non-electronic troublemaker might seize control of a car. Hijacking is generally the result of a successful attack using a different technique, such as a replay or MITM attack, allowing the attacker to impersonate a legitimate user. In other words, the intruder intercepts the source side packets and replaces them with new packets sent to the destination. The most common example of this is web session hijacking, where an attacker takes advantage of lax security to take control of a users browser session. Most web servers use cookies, small data files accessible by server scripting languages such as PHP or ASP, to authenticate and track users. When a user connects to a website and authenticates, an attacker may be able to hijack their session by loading a hacked cookie or by inputting a specific URL on a poorly configured web server into their browser. The legitimate user will most likely be kicked out, or at least be shown an error page indicating their login has failed. Another opportunity for session hijacking is provided by poorly configured server time-outs. If a web developer makes the session time-out (length of time of no activity before the web server disconnects the user) too long, it provides a larger window of opportunity for an attacker to hijack the session. Hijacking is not limited to web based sessions only. Like (and sometimes using) an MITM attack, hijacking is especially suited to telnet type plaintext connections, where an attacker can watch a TCP session being initiated and data being passed between client and server. If the attacker sees something interesting they can break into the conversation and take control of the users session for their own purposes.
There are several precautions you can take against this type of attack. The most simple is to re-authenticate the user before performing important actions. For web servers, creating unique session cookies also mitigates the risk somewhat. The more unique the cookie, the harder it is to break and hijack. Finally, if possible, use secure protocols and the employ the same countermeasures used against replay attacks. An excellent resource for further study is available in the footnote80. __________________ 80. http://blinky-lights.org/script.html
Home - Table Of Contents - Contact Us CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com Version 1.0 - Version Date: November 15, 2004 Adapted with permission from a work created by Tcat Houser et al. CertiGuide.com Version © Copyright 2004 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||