Session hijacking

hijacking how to

1. Session hijacking
From Wikipedia, the free encyclopedia
In computer science, session hijacking, sometimes also known as cookie hijacking is the exploitation of a
valid computer session—sometimes also called a session key—to gain unauthorized access to information or
services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate
a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain
a session on many web sites can be easily stolen by an attacker using an intermediary computer or with access
to the saved cookies on the victim's computer (see HTTP cookie theft).
A popular method is using source­routed IP packets. This allows an attacker at point B on the network to
participate in a conversation between A and C by encouraging the IP packets to pass through B's machine.
If source­routing is turned off, the attacker can use "blind" hijacking, whereby it guesses the responses of the
two machines. Thus, the attacker can send a command, but can never see the response. However, a common
command would be to set a password allowing access from somewhere else on the net.
An attacker can also be "inline" between A and C using a sniffing program to watch the conversation. This is
known as a "man­in­the­middle attack".
Contents
1History of the HTTP
2Methods
3Exploits
3.1Firesheep
3.2WhatsApp sniffer
3.3DroidSheep
3.4CookieCadger
4Prevention
5See also
6References
7External links
History of the HTTP

2. HTTP protocol versions 0.8 and 0.9 lacked cookies and other features necessary for session hijacking. Version
0.9beta of Mosaic Netscape, released on October 13, 1994, supported cookies.
Early versions of HTTP 1.0 did have some security weaknesses relating to session hijacking, but they were
difficult to exploit due to the vagaries of most early HTTP 1.0 servers and browsers. As HTTP 1.0 has been
designated as a fallback for HTTP 1.1 since the early 2000s—and as HTTP 1.0 servers are all essentially
HTTP 1.1 servers the session hijacking problem has evolved into a nearly permanent security risk.
The introduction of supercookies and other features with the modernized HTTP 1.1 has allowed for the
hijacking problem to become an ongoing security problem. Webserver and browser state machine
standardization has contributed to this ongoing security problem.
Methods
There are four main methods used to perpetrate a session hijack. These are:
Session fixation, where the attacker sets a user's session id to one known to him, for example by
sending the user an email with a link that contains a particular session id. The attacker now only has to
wait until the user logs in.
Session sidejacking, where the attacker uses packet sniffing to read network traffic between two
parties to steal the session cookie. Many web sites use SSL encryption for login pages to prevent
attackers from seeing the password, but do not use encryption for the rest of the site once authenticated.
This allows attackers that can read the network traffic to intercept all the data that is submitted to the
server or web pages viewed by the client. Since this data includes the session cookie, it allows him to
impersonate the victim, even if the password itself is not compromised.
[1]
 Unsecured Wi­Fi hotspots are
particularly vulnerable, as anyone sharing the network will generally be able to read most of the web
traffic between other nodes and the access point.
Cross­site scripting, where the attacker tricks the user's computer into running code which is treated as
trustworthy because it appears to belong to the server, allowing the attacker to obtain a copy of the
cookie or perform other operations.
Malware and unwanted programs can use browser hijacking to steal a browser's cookie files without a
user's knowledge, and then perform actions (like installing Android apps) without the user's knowledge.
[2]
An attacker with physical access can simply attempt to steal the session key by, for example, obtaining
the file or memory contents of the appropriate part of either the user's computer or the server.
Exploits
Firesheep
In October 2010, a Mozilla Firefox extension called Firesheep was released that made it easy for session
hijackers to attack users of unencrypted public Wi­Fi. Websites like Facebook, Twitter, and any that the user
adds to their preferences allow the Firesheep user to easily access private information from cookies and threaten
the public Wi­Fi user's personal property.
[3]
 Only months later, Facebook and Twitter responded by offering
(and later requiring) HTTP Secure throughout.
[4][5]
WhatsApp sniffer

3. An app named "WhatsApp Sniffer" was made available on Google Play in May 2012, able to display messages
from other WhatsApp users connected to the same network as the app user.
[6]
 At that time WhatsApp used an
XMPP infrastructure with unencrypted, plain­text communication.
[7]
DroidSheep
DroidSheep is a simple Android tool for web session hijacking (sidejacking). It listens for HTTP packets sent
via a wireless (802.11) network connection and extracts the session id from these packets in order to reuse
them. DroidSheep can capture sessions using the libpcap library and supports: open (unencrypted) networks,
WEP encrypted networks, and WPA/WPA2 encrypted networks (PSK only). This software uses libpcap and
arpspoof.
[8][9]
 The apk was made available on Google Play but it has been taken down by Google.
CookieCadger
CookieCadger is a Java app that automates sidejacking and replay of insecure HTTP GET requests. Cookie
Cadger helps identify information leakage from applications that utilize insecure HTTP GET requests. Web
providers have started stepping up to the plate since Firesheep was released in 2010. Today, most major
websites can provide SSL/TLS during all transactions, preventing cookie data from leaking over wired Ethernet
or insecure Wi­Fi. Cookie Cadger is the first open­source pen­testing tool ever made for intercepting and
replaying specific insecure HTTP GET requests into a browser. Cookie Cadger is a graphical utility which
harnesses the power of the Wireshark suite and Java to provide a fully cross­platform, entirely open­source
utility which can monitor wired Ethernet, insecure Wi­Fi, or load a packet capture file for offline analysis.
Cookie Cadger has been used to highlight the weaknesses of youth team sharing sites such as Shutterfly (used
by AYSO soccer league) and TeamSnap.
[10]
Prevention
Methods to prevent session hijacking include:
Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key
(though ideally all traffic for the entire session
[11]
). This technique is widely relied­upon by web­based
banks and other e­commerce services, because it completely prevents sniffing­style attacks. However, it
could still be possible to perform some other kind of session hijack. In response, scientists from the
Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by correlating the
application session with the SSL/TLS credentials
[12]
Use of a long random number or string as the session key. This reduces the risk that an attacker could
simply guess a valid session key through trial and error or brute force attacks.
Regenerating the session id after a successful login. This prevents session fixation because the attacker
does not know the session id of the user after s/he has logged in.
Some services make secondary checks against the identity of the user. For example, a web server could
check with each request made that the IP address of the user matched the one last used during that
session. This does not prevent attacks by somebody who shares the same IP address, however, and
could be frustrating for users whose IP address is liable to change during a browsing session.
Alternatively, some services will change the value of the cookie with each and every request. This
dramatically reduces the window in which an attacker can operate and makes it easy to identify whether
an attack has taken place, but can cause other technical problems (for example, two legitimate, closely
timed requests from the same client can lead to a token check error on the server).
Users may also wish to log out of websites whenever they are finished using them.
[13][14]
 However this

4. will not protect against attacks such as Firesheep.
See also
ArpON
Cross­site request forgery
HTTP cookie
TCP sequence prediction attack
References
1. "Warning of webmail wi­fi hijack". BBC News. August 3, 2007.
2. Rudis Muiznieks. "Exploiting Android Users for Fun and Profit". The Code Word.
3. "Firefox extension steals Facebook, Twitter, etc. sessions". The H. 25 October 2010.
4. "Facebook now SSL­encrypted throughout". The H. 27 January 2011.
5. "Twitter adds ‘Always use HTTPS’ option". The H. 16 March 2011.
6. "Sniffer tool displays other people's WhatsApp messages". The H. 13 May 2012.
7. "WhatsApp no longer sends plain text". The H. 24 August 2012.
8. "DroidSheep".
9. "DroidSheep Blog".
10. "How Shutterfly and Other Social Sites Leave Your Kids Vulnerable to Hackers". Mother Jones. 3 May 2013.
11. "Schneier on Security: Firesheep". 27 October 2010. Retrieved 29 May 2011.
12. Burgers, Willem; Roel Verdult; Marko van Eekelen (2013). "Prevent Session Hijacking by Binding the Session to
the Cryptographic Network Credentials". Proceedings of the 18th Nordic Conference on Secure IT Systems
(NordSec 2013).
13. See "NetBadge: How To Log Out".
14. See also "Be Card Smart Online ­ Always log out".
External links
ArpON home page (http://arpon.sourceforge.net)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Session_hijacking&oldid=699125336"
Categories: Computer network securityComputer security exploitsWeb security exploits
This page was last modified on 10 January 2016, at 11:50.
Text is available under the Creative Commons Attribution­ShareAlike License; additional terms may
apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered
trademark of the Wikimedia Foundation, Inc., a non­profit organization.