Session Hijacking Attacks
In computer science, session 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 a hacker at point A on the network to participate in a conversation between B and C by encouraging the IP packets to pass through its machine.
If source-routing is turned off, the hacker can use “blind” hijacking, whereby it guesses the responses of the two machines. Thus, the hacker 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.
A hacker can also be “inline” between B and C using a sniffing program to watch the conversation. This is known as a “man-in-the-middle attack“.
Session hijacking was not possible with early versions of HTTP.
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.
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. 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.
- Alternatively, 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.
- 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.
Methods to prevent session hijacking include:
- Encryption of the data traffic passed between the parties; in particular the session key, though ideally all traffic for the entire session by using SSL/TLS. 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.
- 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. However this will not protect against attacks such as Firesheep.
In October 2010, a Mozilla Firefox extension called Firesheep has exploited and made it easy for users of unencrypted public Wi-Fi to be attacked by session hijackers. 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 users personal property. Only months later, Facebook and Twitter responded by offering (and later requiring) HTTP Secure throughout.
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.WhatsApp uses an XMPP infrastructure with unencrypted, plain-text communication.
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 Networks, WEP encrypted networks, and WPA/WPA2 encrypted networks (PSK only) This software uses libpcap and arpspoof. The apk was made available on Google Play but it has been taken down by Google. The source is available here
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. CookieCadger has been used to highlight the weaknesses of youth team sharing sites such as Shutterfly (used by AYSO soccer league) and TeamSnap.
Session Hijacking is one of the simple attacks on the internet, and with the implementation of Firesheep (http://cleverlogic.net/articles/firesheep-session-hijacking-made-easy), Session Hijacking have become very popular; this can be concluded by the fact that there has been over 1 million downloads of Firesheep and thousands of success stories and videos. Firesheep also have an average daily usage of 490 users (Mozilla Firefox, 2010).
Attackers’ use several session hijacking attacks to gain access to user sessions on a server, the most common of these attacks are listed and described below:
- Session Prediction – http://cleverlogic.net/tutorials/what-session-prediction
- Session Sidejacking – http://cleverlogic.net/tutorials/session-sidejacking-overview
- Session Fixation – http://cleverlogic.net/tutorials/session-fixation-overview
- Cross Site Scripting – http://cleverlogic.net/tutorials/cross-site-scripting-0
- Using Proxy Servers – http://cleverlogic.net/content/using-proxy-servers-session-hijacking
- Physical Access to Server
Preventing Session Hijacking
Since session hijacking is where the attacker steals a user’s Session Identifier, to prevent this attack, we would need to prevent the user’s Session Identifier. There are several things we can do to help to prevent this attack:
- Use Secure Connections (Achieved through Secure Socket Layer(SSL) – http://cleverlogic.net/articles/secure-socket-layer-overview) as much as possible, since SSL creates an encrypted connection between the client and server, any data the attacker steals during this transfer would be useless to them. However, SSL does not fully secure against this attack, and hackers can still use session hijacking even over HTTPS.
- Regenerate user’s session identifier often, therefore, even though the attacker may manage to steal a user’s session identifier, when it is regenerated, the Session Identifier he stole would be useless.
- You can implement an IP Address Check to match a user’s Session Identifier to his/her IP Address. However this may have its limitations.
- For my final year project titled “Mitigating HTTP Session Hijacking” i built an application to help prevent this attack. more on this can be found here: http://cleverlogic.net/articles/kochure. I would strongly advise implementing this application on your Web Server.
- Another method is to use HTTP only cookies, these are cookies that claim to be inaccessible from the DOM, However, some hackers have claimed to gain access to HTTP only cookies through the dom. HTTP only cookies would still make it harder to gain access to cookies using most of the session hijacking attacks. However if session Sidejacking is used, These cookies can easily be stolen from over a LAN network. Session Sidejacking is spoofing cookies over a LAN network, More can be found on the session Sidejecking page linked to above.
- More information about preventing each of the above listed Session Hijacking attacks can be found on the Attack’s Page.
To get a better understanding of how this attack is carried out, a step-by-step tutorial can be found at http://cleverlogic.net/tutorials/session-hijacking-facebook-accounts. Note this tutorial is only for informative purposes. Any questions can be posted below in the comments section.
- Firesheep – Session Hijacking Made Easy
- Session Hijacking Facebook Accounts
- Using Proxy Servers for Session Hijacking
- Session Fixation Overview