Session hijacking

Definition

Session hijacking is the act of taking over an authorized, already established transaction (communication scenario) illegally, through various ways of obtaining a session identifier used for the rest of the transaction (communication scenario) between a web server and a client.

Introduction

Session hijacking is a serious issue in web applications. That is, it constitutes concerns that call for the attention of both web developers and users. With session hijacking, a lot is at risk, e.g. user data – including access credentials, credit card details, user profiles etc; corporate data, and the integrity of web applications and their developers, which may sometimes involve certain legal rights like law suits etc.

To adequately define what session hijacking is, and what it entails – the threats it posses and the necessary measures to help mitigate risks, there is the need to understand what a session is, and the “very-important” session identifier too. In telecommunication, a session is a series of interactions between two communication end points that occur during the span of a single connection. Typically, one end point requests a connection with another specified end point and if that end point replies agreeing to the connection, the end points take turns exchanging commands and data ("talking to each other"). The session begins when the connection is established at both ends and terminates when the connection is ended. With web applications, this is not as easy as such: reasons because HTTP, the communication bed-rock for web applications is stateless. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests. For example, when a web server is required to customize the content of a web page for a user, the web application may have to track the user's progress from page to page. Hence, it does not guarantee a session that lasts longer than a “request-and-response”. Now you guessed it, not many meaningful and useful transactions can be completed with just a “single” request-and-response operation in real life. Or if not, let’s consider an example: supposing you want to carry out an online transaction that requires user authentication, say, check mails, which requires you to log in with your username and password, or in other words, access credentials. Now supposing you asked the server for the mails and they asked you to tell who you are, that is requesting your access credentials, then you went ahead to provide the credentials, but on receive those credentials, the server/application no longer remembers what you wanted!! Or for better granularity, say after providing your access credentials and you are now provided with your web mail page, you then went ahead to access inbox, then the server asks again, who are you? Which means, it has already forgotten your credentials, which further means that, with every operation that requires access to secured data/information, you would always be asked to provide your access credentials… that would be pretty stupid right? But that’s what HTTP can provide, since it is stateless.

Now, web applications need to get around these short-live transactions (request-and-response long transactions) provided by HTTP, to make sense to web users and even from the application’s view point and/or domain. Hence, with respect to web applications, a session, or a web session, is a collection of related HTTP sessions (requests-and-responses) or different TCP network connections, that completes a meaningful and useful transaction from the user’s and/or applications view point. Sometimes a web session is also constrained by certain duration of inactivity, depending on the level security requirements and definitions of an application. For example, with e-banking, a session may be restricted to say only every one complete “transaction”, any further transaction(s), may be defined as a separate session to thwart hackers for example. And in other cases or applications such as the web mail, it may be duration constrained, say the system/application automatically ends your session (logs you out) after some time of idleness etc. Session management is the technique used by web developers to make the stateless HTTP protocol support this, otherwise known as “session state”. For example, once a user has authenticated herself to the web server, her next HTTP request (GET or POST) should not cause the web server to ask her for her account and password again. The session information is stored on the web server using the session identifier (session ID) generated as a result of the first (sometimes the first authenticated) request from the end user running a web browser. The "storage" of session IDs and the associated session data (user name, account number, etc.) on the web server is accomplished using a variety of techniques including, but not limited to: local memory, flat files, and databases. A common solution is the use of HTTP cookies. Other methods include server side sessions, hidden variables (when the current page is a form), and URL-rewriting using URI-encoded parameters, e.g., /index.php?session_id=some_unique_session_code. This session “unique” identifier is all that is needed for the remainder of a whole session, after the necessary authentication and verification processes, and can be communicated between the machines and not interrupting or otherwise annoying the web user with random authentication requests for each operation. This is when the attacker wants to strike, to obtain this session ID and continue with the session, by somehow stopping the legitimate user from participating (e.g. Denial of Service), hence, this session is said to be hijacked.

Session Hijacking

When you log onto a website that requires a username and password, that is when you tell Facebook, Yahoo, Amazon, or whoever it is who you are. At this point the website gives you a cookie. For the rest of the session the website is constantly looking at the cookie to determine who you are. If someone else has the cookie the website will not know it, but they will trust that it is you and provide the same access that you already have.

Session hijacking can be done at two levels: Network Level and Application Level. Network layer hijacking involves TCP and UDP sessions, whereas Application level session hijack occurs with HTTP sessions. Successful attack on network level sessions will provide the attacker some critical information which will then be used to attack application level sessions, so most of the time they occur together depending on the system that is attacked. Network level attacks are most attractive to an attacker because they do not have to be customized on web application basis; they simply attack the data flow of the protocol, which is common for all web applications.

TCP hijacks are meant to intercept an already established TCP sessions between any two communicating parties and then pretending to be one of them, finally redirecting the TCP traffic to the hacker by injecting spoofed IP packets so that the hacker’s commands are processed on behalf of the authenticated host of the session, as authentication is only required at the time of establishing connection. What is left now is how to alter the sequence and the acknowledgement numbers of the spoofed packets which the server is expecting from the client. Once it is altered, hijacker injects its own forged packet in the established session before the client can respond, ultimately desynchronizing the original session, because the server will now expect a different sequence number, so the original packet will be trashed, based on the anticipation of sequence numbers. TCP session hijacks can be implemented in two different ways: steal the packets then try to modify it to take over the session e.g. Man in the Middle Attack, Source-Routed IP (packet sniffing) or try to guess a valid packet e.g. the Blind attack (aka Brute Force Attack).

Packet sniffer comes in two categories: Active and Passive sniffers. Passive sniffers monitors and sniffs packet from a network having same collision domain i.e. network with a hub, as all packets are broadcasted on each port of hub. Active sniffers works with Switched LAN network by ARP spoofing. Once the hijacker reads the TCP header, he can know the sequence number expected by the server, the acknowledgement number, the ports and the protocol numbers; so that hijacker can forge the packet and send it to the server before the client does so. Another way of doing so is to change the default gateway of the client’s machine so that it will route its packets via the hijacker’s machine. This can be done by ARP spoofing (i.e. by sending malicious ARP packets mapping its MAC address to the default gateways address so as to update the ARP cache on the client to redirect the traffic through the hijacker).

If the attacker is not able to sniff packets, the attacker has to implement “Blind Session Hijacking”, which requires the attacker to brute force the packets.

Since UDP does not use packet sequencing and synchronizing; it is easier to hijack than a TCP session. The hijacker has simply to forge a server reply to a client UDP request before the server can respond. If sniffing is used then it will be easier to control the traffic generating from the side of the server and thus restricting server’s reply to the client in the first place.

These same techniques could be successfully applied to the HTTP sessions at the application layer to obtain the session ID.

In general, there are three primary techniques for hijacking sessions:

1. Brute Force or Blind attack - the attacker tries multiple IDs until successful.
2. Calculate - in many cases, especially HTTP session IDs at the application layer, are generated in a non-random manner and can be calculated.
3. Steal - using different types of techniques (packet sniffing), the attacker can acquire the Session ID.

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.

Countermeasures

Defending a network against session hijacking requires implementing security measures at both the Application level and Network level. Network level hijacks can be prevented by ciphering the packets so that the hijacker cannot decipher the packet headers, to obtain any information which will aid in spoofing. This encryption can be provided by using protocols such as IPSEC, SSL, SSH etc. Internet protocol security (IPSEC) has the ability to encrypt packets on some shared key between the two parties involved in a communication. IPsec runs in two modes: Transport and Tunnel. In Transport Mode only the data sent in the packet is encrypted while in Tunnel Mode both packet headers and data are encrypted, so it is more restrictive. To Prevent Application sessions from being hijacked, it is recommended to use Strong Session ID’s so that they cannot be easily brute forced or use encryption as well. SSL (Secure Socket layer) and SSH (Secure Shell) also provides strong encryption using SSL certificates so that session cannot be hijacked, but tools such as Cain & Bell can spoof the SSL certificates and decipher everything! Expiring sessions after a definite period of time requires re-authentication which will futile the hacker’s tricks.

In general, most common methods to prevent session hijacking include:

• SecureSessionModule used by Applications developed on the ASP.NET platform. SecureSessionModule modifies cookies by appending a hashed message authentication code (MAC) to the session ID. The MAC is generated from the session ID, the network address portion of the requestor's IP address (for example, the 192.16 in 192.16.0.14), the User-Agent header received in the request, and a secret key stored on the server. Before allowing a request containing a session ID cookie to continue through the pipeline, SecureSessionModule validates the cookie by regenerating the MAC from the requestor's IP address, the User-Agent header, and the secret key. If the freshly computed MAC matches the one in the cookie, the MAC is stripped from the cookie and the request is allowed to proceed. If the MACs don't match, SecureSessionModule throws an InvalidSessionException, The Framework's System.Security.Cryptography.HMACSHA1 class makes the task of generating the MAC really quite easy.
• An open source solution is ArpON "Arp handler inspectiON". It is a portable ARP handler which detects and blocks all Man In The Middle attacks through ARP poisoning and spoofing attacks with a static ARP inspection (SARPI) and dynamic ARP inspection (DARPI) approach on switched or hubbed LANs with or without DHCP. This requires an agent on every host that is to be protected.
• 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 he has logged in.
• Encryption of the data passed between the parties; in particular the session key. 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.
• 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, preventing the back button from working properly, on the web).
• Users may also wish to log out of websites whenever they are finished using them.

Conclusion

Session hijacking remains a serious threat to Networks and Web applications as most of the systems are vulnerable to it. Networks should be tested and monitored continuously in order to make them impenetrable by the intruders.

Building a foolproof (total) security is nearly impossible. Or better still, too costly to adopt reasonably. For example, buying end-to-end encryption may be the only winning complete solution to session hijacking until say, the crypto is broken… which presently, not everybody on the web can afford, too expensive; consider hardware and power requirements for example.

SecureSessionModule raises the bar for hackers who hijack sessions using stolen session IDs by factoring evidence about the session owner into the session ID cookie. That evidence isn't conclusive because neither network addresses nor User-Agent headers can be used reliably to distinguish one user from another, but it nonetheless places an additional hurdle in the path of hackers who are actively seeking to compromise your Web servers by connecting to other users' sessions and grabbing their data.

Web developers have to brave up to the task of appropriately and adequately protecting web sites from session hijacking by finding the appropriate techniques to apply against this perilous practice of session hijackers.

Security is all about raising the bar. The harder you make it for a hacker to execute a successful attack, the less likely it is that successful attacks will occur.