When you watch movies these days—especially ones that involve computer security—you really need to take them with a grain of salt. Only in Hollywood can you crack a 1119781325-bit encryption algorithm, by hand of course, within seconds of the bomb detonating. Here’s a personal favorite: creating and uploading a computer virus into an alien operating system using only a few keystrokes. The sensationalism is sometimes so out there that disengaging your brain for a couple of hours is usually a good idea.
Seriously though, the real world and the movie world do agree on some threats. One of them is the topic of this chapter: session hijacking. This chapter first covers the fundamentals of session hijacking. It then explores common ways attackers are able to intercept and modify communications as well as provides some tricks and techniques attackers use. The following types of session hijacking are discussed:
Network-level hijacking
Host-level hijacking
Application-level hijacking
In a session hijacking attack, an attacker takes control of or modifies any communications between two hosts. Communications can be anything from a Telnet session, an instant messaging (IM) conversation, or a domain name lookup to a local user’s keystrokes. As the authors of Hack Proofing Your Networking: Internet Tradecraft (Syngress Publishing, 2000) have suggested, all the different types of session hijacking share the goal of trying to exploit established trust between two hosts. Session hijacking takes advantage of the fact that most communications are protected from the beginning at session setup, such as by providing credentials, but not during the session.
Session hijacking attacks generally fall into the following three categories:
Man-in-the-middle (MITM) attacks. In this type of attack, an attacker intercepts all communications between two hosts. He positions himself so that communications between a client and server must flow through him, which allows him to modify the communications. Protocols that rely on the exchange of public keys to protect communications, for example, are often the target of these types of attacks. Figure 21-1 shows an MITM attack.
Blind hijack attacks. In addition to intercepting communications between two hosts, an attacker can inject data such as malicious commands into those communications, for example, net.exe local-group administrators/add EvilAttacker. This type of attack is called blind hijacking because the attacker can only inject data into the communications stream; he cannot see the response to that data, such as "The command completed successfully." Essentially, the blind hijack attacker is shooting data in the dark, but as you’ll see shortly, this method of hijacking is still very effective. Figure 21-2 shows a blind hijack attack.
Session theft attacks. In a session theft attack, the attacker is neither intercepting nor injecting data into existing communications between two hosts (as in the case of MITM and blind hijack attacks). Instead, the attacker creates new sessions or utilizes old sessions. This type of session hijacking attack is most common at the application level, such as a Web application. Figure 21-3 shows a session theft attack.
Session hijacking at the network level is especially attractive for attackers. They don’t need to have access on a host as they do with host-level session hijacking. Nor do they need to customize attacks on a per-application basis as they have to at the application level. Network-level session hijacking attacks allow attackers to remotely take over sessions, usually undetected. An opportunity like this, however, rarely comes for free, and as you will see in the next few sections, the attackers must first get by various hurdles to successfully hijack a session at the network level. Let’s consider the following protocols:
TCP
UDP
One of the key features of TCP is reliability and the in-order delivery of packets. To accomplish this, TCP uses acknowledgement (ACK) packets and sequence numbers; manipulating these is the basis for TCP session hijacking.
As you learned earlier, for an MITM attack, the attacker simply needs to be positioned so that communications between the client and the server are relayed through him. To understand how an attacker might sneak himself into the TCP session in a blind session hijack attack, you need to look at what happens when a client initiates a TCP session with the server.
As shown in Figure 21-4, the client initiates a session with the server by first sending a SYN packet to the server with an initial sequence number of X. The server responds with a SYN/ACK packet that contains the server’s own sequence number P and an ACK number for the client’s original SYN packet. This ACK number indicates the next sequence number the server is expecting from the client, so in our example, this is X+1 because the client’s original SYN packet counted as a single byte. The client acknowledges receipt of the SYN/ACK packet by sending back to the server an ACK packet with the next sequence number it expects from the server, which in this case is P+1 (the server’s initial SYN packet sequence number plus one). At this point the session is good to go, and the client and server are ready to start exchanging data.
Important
The sequence number values described in the preceding paragraph will be key to understanding how to successfully hijack this session later, so pay close attention to these numbers. ACK numbers will also be important for you to understand when TCP ACK storms are explained, so keep an eye on these as well.
Now observe what happens to these sequence numbers when the client starts sending data to the server. (See Figure 21-5.) To keep the example simple, the client sends the character A in a single packet to the server.
The client sends the server the single character in a data packet with the sequence number X+1. The server acknowledges this packet by sending back to the client an ACK packet with number X+2 (X+1 plus one byte for the A character) as the next sequence number expected by the server. Enter the attacker. If the attacker wanted to inject data into the TCP session as the client, he would need to be able to do the following:
Spoof the client’s IP address.
Determine the correct sequence number the server is expecting from the client.
Inject data into the session before the client sends its next packet.
The first item in the list is easy to accomplish—as you learned in Chapter 20, IP spoofing is easy for attackers to do. The second item is easy, too, and nothing a good network sniffer can’t figure out. (See Chapter 19.) The third item in the list, though, is a little trickier, but definitely not impossible for the attacker. Essentially the attacker needs a way to "hold down" the client from sending into the session new data that would shift sequence numbers forward. To do this, the attacker could just send the data to inject and hope it is received before the real client can send new data. (See Figure 21-6.) Or she could do things such as perform a denial of service (DoS) attack on the client or perform some tricks that use address resolution protocol (ARP) spoofing, which is discussed later in this chapter.
The attacker sends a single Z character to the server with sequence number X+2; the server accepts it and sends the real client an ACK packet with acknowledgement number X+3 to confirm that it has received the Z character. When the client receives the ACK packet, it will be confused either because it didn’t send any data or because the next expected sequence is incorrect. (Maybe the attacker sent something "nice" like mv 'which emacs' /vmunix && shutdown -r now and not just a single character.) As you will learn later in this chapter, this confusion can cause a TCP ACK storm, which can disrupt a network. In any case, the attacker has now successfully hijacked this session.
Hijacking a session over a User Datagram Protocol (UDP) is exactly the same as over TCP, except with UDP, attackers don’t have to worry about the overhead of managing sequence numbers and other TCP mechanisms. Since UDP is connectionless, injecting data into a session without being detected is extremely easy.
Figure 21-7 shows how an attacker, for example, could inject data into a UDP session. DNS queries, online games like the Quake series and Half-Life, and peer-to-peer sessions are common protocols that work over UDP and are popular targets for this kind of session hijacking.
One obvious way to determine whether your organization’s networks are susceptible to network-level session hijacking attacks is to try to hijack actual network sessions using common attacker tools such as Juggernaut or Hunt. Using live attacker tools against your organization’s production networks, however, is not recommended. A safer litmus test would be to simply determine whether your organization uses transport protocols that do not use cryptographic protection such as encryption for transport security or digital signatures for authentication verification. Common example protocols include Telnet, File Transfer Protocol (FTP), and Domain Name System (DNS). If such network protocols exist in your organization’s networks, sessions traveling over those unencrypted protocols have strong potential to be hijacked.
The preceding section alluded to some countermeasures you could take to reduce your susceptibility to network-level session hijacking attacks. In case you missed them, here they are: defeating network-level session hijacking threats can be done by implementing encrypted transport protocols such as Secure Shell (SSH), Secure Socket Layers (SSL), and Internet Protocol Security (IPSec). An attacker wanting to hijack a session tunneled in an encrypted transport protocol must at a minimum know the session key used to protect that tunnel, which in most cases (you hope) is difficult to guess or steal. Any data the attacker can inject into network sessions without using the correct session key will be undecipherable by the recipient and rejected accordingly. In the unlikely event that an attacker is able to attain the prized session key, digitally signing network traffic can also provide an extra layer of defense against the successful injection of malicious data into network sessions.
Important
As a good rule of thumb, do not communicate with highly critical systems unless you do so over protocols that use a strong encryption algorithm for secure transport. By themselves, protocols such as Telnet and FTP are poor choices and are extremely susceptible to hijacking when not protected inside encrypted tunnels.
Successfully hijacking a network session requires that a few conditions fall into place for the attacker, so he has several tricks and techniques for creating these conditions. For instance, to conduct a true MITM attack, the attacker must get hosts to route traffic through him, and to make this happen, he can use tricks with ICMP Redirect packets or ARP spoofing. As you read through the tricks and techniques discussed here, keep in mind that many can be easily defeated by the countermeasures for network-level session hijacking. TCP ACK storms, for example, are not possible when the attacker is not able to successfully inject data into a session. Routing table modifications also quickly become a wasted effort for an attacker if he cannot interpret or modify data that gets routed through him. It’s still useful and interesting, however, to know what your enemy has in his bag of tricks. Some common items include:
TCP acknowledgement packet storms
ARP table modifications
TCP resynchronizations
Remote modifications of routing tables
If an attacker is not careful (bad guys rarely are) when hijacking TCP sessions in your organization’s networks, those networks can be disrupted by TCP ACK packet storms.
To understand this threat, let’s see what happens when an attacker hijacks a TCP session from the TCP protocol’s point of view. Assuming that the attacker has forged the correct packet information (headers, sequence numbers, and so on) at some point during the session, when the attacker sends data to the server-injected session, the server will acknowledge the receipt of the data by sending the real client an ACK packet. This packet will most likely contain a sequence number that the client is not expecting, so when the client receives this packet, it will try to resynchronize the TCP session with the server by sending it an ACK packet with the sequence number that it is expecting. This ACK packet in turn will contain a sequence number that the server is not expecting either, and so the server will resend its last ACK packet. This cycle goes on and on and on, and this rapid passing back and forth of ACK packets creates an ACK storm, as shown in Figure 21-8.
As the attacker injects more and more data, the size of the ACK storm increases and can quickly degrade the performance of networks. If the attacker or client does not explicitly close the session, at some point, the storm will stop itself when ACK packets are lost in the storm.
The address resolution protocol (ARP) is a protocol used by each host on an IP network to map local IP addresses to hardware addresses or Medium Access Control (MAC) addresses. Let’s take a quick look at how this protocol works. Say, for example, that Host A (IP address 192.168.1.100) wanted to send data to Host B (IP address 192.168.1.250) and that no prior communications were made between Hosts A and B (so that ARP table entries for Host B on Host A are empty). In Figure 21-9, Host A broadcasts an ARP request packet indicating for the owner of the IP address 192.168.1.250 to respond to Host A at 192.168.1.100 with its MAC address. The broadcasted packet is sent to every machine in the network segment, and only the true owner of the IP address 192.168.1.250 should respond. (As you’ll see very shortly, this is not always the case.) All other hosts will discard this request packet. Host A receives an ARP reply packet from Host B indicating that its MAC address is BB:BB:BB:BB:BB:BB, Host A updates its ARP table, and now Host A can send Host B data.
Can you see the security problem here? How does Host A know that Host B really did send the ARP reply? It doesn’t know, and attackers take advantage of this. In our example, attackers could spoof an ARP reply to Host A before Host B responded, indicating that the hardware address EE:00:EE:00:EE:00 corresponds to Host B’s IP address. (See Figure 21-10.) Host A would then send any traffic intended for Host B to the attacker, and the attacker could choose to forward that data (most likely tampered with first) to Host B.
Attackers can also use ARP packet manipulation to quench TCP ACK storms, which are noisy and quite detectable by devices such as intrusion detection system (IDS) sensors. (See Figure 21-11.) Session hijacking tools such as Hunt accomplish this by sending unsolicited ARP replies. Most systems will accept these packets and update their ARP tables with whatever information is provided. In our Host A and Host B example, an attacker could send Host A a spoofed ARP reply indicating that Host B’s MAC address is something nonexistent like C0: C0: C0: C0: C0: C0, and send Host B another spoofed ARP reply indicating that Host A’s MAC address is also something nonexistent such as D0: D0: D0: D0: D0: D0. Any ACK packets between Host A and Host B that could cause a TCP ACK storm during a network-level session hijacking attack are sent to invalid MAC addresses and lost.
To hide her tracks, an attacker who is finished with her session hijacking attack might want to resynchronize the communicating hosts. The problem is that after she is finished with the attack, the two hosts whose session she hijacked will be at different points in the session. In other words, each host will be expecting different sequence numbers. The server might think, for example, that it is 40 bytes into the session when really the client might have sent only 29 bytes. Thus, the expected sequence numbers on each side will differ. Since sequence numbers move in only a positive direction, manipulating the server so that its expected sequence number moves downward to match the client’s is not possible with TCP stacks. The attacker needs some way to move the client’s sequence numbers to match the servers. Tools like Hunt try to solve this problem by sending a message to the client like the following. (The number 13 is an arbitrary number and presented only for the sake of our example.)
msg from root: power failure - try to type 13 chars
Hunt will replace this value with whatever number of bytes the client is required to send to be resynchronized with the server. The hope is that the user will comply, and when the user has typed enough characters, Hunt will use more forged ARP reply packets to restore the ARP table entries it modified on the client and server to avoid TCP ACK storms to the correct values.
As discussed earlier, ideally, an attacker who wants to hijack a session at the network level needs to be positioned so that all communications between a client and server pass through her, enabling her to easily monitor, modify, and inject data into the session, à la MITM attacks. This boils down to the attacker tricking one of the hosts, most commonly the client, into routing all its session traffic through the attacker so that the attacker can intercept and then forward that data to the correct recipient. When an attacker is local to the host whose traffic is being intercepted, one popular way to modify the routing table of the host is to forge Internet Control Message Protocol (ICMP) Redirect (type 5) packets and have them advertise as the route to take when sending data.
Note
To protect Windows hosts against this type of attack, set the EnableICMPRedirect value to 0 under the registry key HKLMSystemCurrentControlSetServicesAFDParameters.
More information about this registry setting can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HTHardTCP.asp.
An attacker who gains access to a host can either hijack sessions locally on that host or hijack remote sessions with other hosts. What might surprise you as you read through this section is that in some instances, an attacker does not need to be highly privileged to successfully hijack a session. Here are the common host-level session hijacking attacks we’ll cover:
User session hijacking
Server port hijacking
If an attacker gains root access on a UNIX host, one way to hijack a user session is through the tty. A tty on UNIX systems is any terminal controlling a particular job or process. Hijacking a session’s tty allows attackers to intercept and modify all session information, such as keystrokes. Several tools that enable attackers to do this have been published, including one tool in an article on attacking Linux kernels by Halflife for Phrack magazine (http://www.phrack.org/phrack/50/P50-05). Another way to hijack a user session on a UNIX host that also requires root access is by hijacking file descriptors, as described by Orabidoo in another Phrack magazine issue (http://www.phrack.org/phrack/51/P51-05). Also, if an attacker is able to gain administrator-level access and install rootkits onto a Windows host (see Chapter 22), he can intercept user session information.
So what if the attacker has administrative access on a host and he can read user session information such as keystrokes? The attacker can do almost anything on that host, right? Well, being able to intercept user session information, even with root access, is still a threat. Those users could log on to other remote hosts in your organization from the compromised host, allow attackers to compromise those remote hosts, and gain further access into your organization.
In addition to using modified tty and file descriptors, another interesting way attackers can hijack a session at the host level is through server port hijacking. When a server binds a socket to a port and indicates that the socket should listen for client activity on all network interface cards (NICs), such as with the following code, that port on most systems can be hijacked by a local attacker.
// C# code to bind socket to all interfaces on the host, this
// is equivalent to INADDR_ANY in C/C++ or 0.0.0.0:
//
// ...
// servaddr.sin_addr.s_addr = htonl (INADDR_ANY);
// servaddr.sin_family = AF_INET;
// servaddr.sin_port=htons(ServerPort);
// size_t size = sizeof(servaddr);
// if (bind(listenfd, (struct sockaddr *)&servaddr,
// sizeof(servaddr))!= 0) {
// printf("Error binding socket to port %d", port);
// exit(1);
// }
//
IPEndPoint IpLocal = new IPEndPoint(IPAddress.Any, ServerPort);
ServerSocket.Bind(IpLocal);An attacker could bind his own socket to the same port using the socket reuse address option:
// Set the ReuseAddress option, this is equivalent to
// SO_REUSEADDR socket option in C/C++, and will allow
// us to bind to the socket we want to hijack =)
//
// ...
// setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR,
// (char *)&optval, sizeof(optval));
//
HijackerSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Reuse
Address, 1);
// Bind socket to an explicit address. C/C++ equivalent:
//
// servaddr.sin_addr.s_addr = inet_addr("SomeSpecificIP");
// servaddr.sin_port = htons(ServerPortToHijack);
//
IPEndPoint IpLocal = new IPEndPoint(IPAddress.Parse("SomeSpecificIP"),
ServerPortToHijack);
HijackerSocket.Bind(IpLocal);Important
The attacker can bind his socket to a port even when he has a different access level from the server application.
Here’s where it gets even more interesting. If both the server and the attacker have sockets bound to the same port, who is the client really connecting to: the server or the attacker? The network libraries decide this based on which binding is more specific. In the preceding example, the server bound its socket to all interfaces (equivalent to 0.0.0.0) on the host, but the attacker could bind his socket to a more specific address, such as 192.168.1.104. The attacker, in this case, would win. Any clients intending to connect to the server would connect instead with the attacker’s socket. The attacker could then forward the request to the real server, intercept the response, and forward a modified reply to the client. Voilà! An MITM attack!
Important
Server port hijacking is not limited to TCP streams even though, in this chapter, the examples and discussion about this topic so far have focused on this protocol. UDP datagram ports can also be hijacked in this fashion.
All right—enough with the theory. Now it’s time to move on to an example and watch this problem in action.
On the CD
This example is based on two programs (with C# source code) that you can find on the companion CD. The first program is a server program named TCPTimeServer.exe that listens on TCP port 13 on all interfaces. Clients who are connecting to this port see the server’s date and time information displayed. The second program, HijackTCPTimeServer.exe, hijacks the TCPTimeServer port through the reuse address socket option and explicit binding, and modifies responses from the real server to the client.
Run the TCPTimeServer.exe program. This will bind the server to all network interfaces on the host on port 13.
When you Telnet to the host’s IP address (for example, telnet.exe 192.168.1.104 13) on this port, the server’s date and time are displayed, and you should see something like this:
1/27/2004 10:44:45 PM
Run the HijackTCPTimeServer.exe program, passing it an explicit IP address on the host. Again, this address could be 192.168.1.104. You should also run this program with a different user account, preferably one with lower privileges than the user employed to start the TCPTimeServer program, so that you can simulate a real attacker.
runas.exe /user:DifferentUserName "HijackTCPTimeServer.exe 192.168.1.104"
Telnet to the host again just like you did in Step 1. Notice now that the response is different and was modified by the hijacking program to contain the message -- Psssss, this port was hijacked!
1/27/2004 10:44:45 PM -- Psssss, this port was hijacked!
Let’s see what just happened here. In Step 1, you started the TCPTimeServer on port 13. Clients that Telnet to the host on port 13 connected to the real server, as shown in Figure 21-12.
The attacker’s hijacking program was invoked, which took control of TCP port 13. If you review the source code, you’ll see that it was able to do this because the hijacking program used the reuse address socket option, and the program was more specific than the server during binding. In true MITM attack fashion, when a client connected to this port, the attacker forwarded the connection to the real server, modified the response, and sent the response back to the client. This process is illustrated in Figure 21-13.
Detecting whether an existing port can be hijacked is easy: programmatically try to bind to an existing socket using the reuse address socket option. A C# program that could do this would look like the following:
try {
Socket TestSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);
// Set the ReuseAddress option, this is equivalent to
// SO_REUSEADDR socket option in C/C++, and will allow
// us to bind to the socket we want to hijack ... er,
// I mean test =)
TestSocket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReuseAddress, 1);
// Bind socket to the address specified by the caller
IPEndPoint IpLocal = new IPEndPoint(IPAddress.Parse(IpAddress),
ServerPortToTest);
TestSocket.Bind(IpLocal);
TestSocket.Close();
// If we succeeded then the socket is hijackable
System.Console.WriteLine("Attention! The socket on port {0} appears to be
hijackable!", ServerPortToTest);
}
catch (Exception) {
System.Console.WriteLine("The socket on port {0} appears to be resistant to
socket hijacking!", ServerPortToTest);
}If this code is able to bind to the port, the port can potentially be hijacked by attackers.
On the CD
The companion CD contains a tool named DetectHijackablePort.exe that has source code that uses the technique just described to detect TCP sockets that are potentially exposed to socket hijacking.
Regular code reviews or your organization’s socket applications are also an effective way of detecting this problem.
Any application developed by your organization that binds a socket to a port should set the exclusive address use socket option when binding, as shown in the following code. Doing so prevents attackers from using the socket reuse address option to hijack ports. In the .NET Framework, this option is specified in the System.Net.Sockets.SocketOptionName enumeration under ExclusiveAddressUse (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemnetsocketssocketoptionnameclasstopic.asp).
ServerSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ExclusiveAddressUse, 1);
In C/C++, the equivalent option is SO_EXCLUSIVEADDRUSE (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_so_exclusiveaddruse.asp).
setsockopt(sockfd, SOL_SOCKET, SO_EXCLUSIVEADDRUSE, (char *)&optval, sizeof(optval));
More Info
Sockets in Microsoft Windows Server 2003 are protected from such hijacking attacks with DACLs. Access to the socket is given only to the invoking user and administrators, so setting socket options like System.Net.Socket.SocketOptionName.ExclusiveAddressUse or SO_EXCLUSIVEADDRUSE are typically not necessary.
Additionally, your organization’s developers could develop their applications so that all interfaces are enumerated on a host and then bound explicitly to each interface. This particular solution is a little more involved than the previous one in terms of the amount of additional code needed, because the state of interfaces on a host can be highly dynamic.
Any attempt to hijack a socket after countermeasures have been applied should return a binding error:
Error creating socket: System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions at System.Net.Sockets.Socket.Bind(EndPoint localEP) at InsideNetworkSecurity.TestingYourDefenses.HijackTCPTimeServer.Main(String [] Args)
Attacks in which an attacker takes control of or modifies the communications between two hosts by exploiting a flaw in a server application are known as application-level session hijacking attacks. The exploit method varies from application to application; however, here are some examples of common mistakes application developers make:
Not timing out an unused session after a period of time. An application that does not expire unused sessions after a period of time could potentially have these sessions hijacked. Attackers could, for example, sniff the URLs of Web application clients and access those sessions later if the clients did not properly log off, such as by closing the browser instead of clicking a logoff button.
Setting predictable cookies. Any application that relies on cookies for session identification might be open to session hijacking attacks, especially if the Web server is setting cookies whose values are highly predictable. The companion CD contains a tool named DetectPredictableCookies.exe along with source code that can be used to illustrate and detect this issue on Web servers. The tool works by making 10 separate connections to a given Web server over HTTP or HTTPS and returning the cookie set by the server, if any exists:
C: >DetectPredictableCookies.exe http://TestWebSite CookieID=AABBCCDDEEFFGGHHIIGG0001; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0002; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0003; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0004; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0005; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0006; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0007; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0008; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0009; path=/ CookieID=AABBCCDDEEFFGGHHIIGG0010; path=/
Notice in the preceding code example that the cookie values are increasing in a predictable manner, that is, they are incrementing by 1. If an attacker was assigned a cookie value of AABBCCDDEEFFGGHHIIGG0006, she could potentially hijack other sessions on the Web server by making reasonable guesses at values for their cookie IDs, such as AABBCCDDEEFFGGHHIIGG0007 or AABBCCDDEEFFGGHHIIGG0003. If the cookie values were more random, such as IGJHINPAHAOCEIJKPJJJKFAL and KHJHINPA3IEFJOPPFE1JBFLH, guessing values would be much more difficult for the attacker.
One final issue to note about session hijacking at this level is that it is a favorite among attackers. Attackers don’t have to worry about race conditions, matching packet sequence numbers, or creating noisy packet storms like they do for network-level session hijacking. They also, in most cases, don’t require local access on a host as they do for hijacking sessions at the host-level. Attackers are like little electrons—if they can take the path of least resistance to reach their goals, they will. Of the three levels of session hijacking—network, host, and application—session hijacking at the application-level usually offers the fewest number of hoops for attackers to jump through.
Exploiting application-level hijacking attacks is largely dependent on the application’s architecture and implementation, and so your ability to detect these flaws will vary from application to application. The following techniques will be useful in detecting hijacking vectors in most situations:
Lie! Lie! Lie! How do your organization’s applications differentiate one client from another? Can this identification marker be modified or easily forged? For instance, if your organization’s applications assign session information through a session ID in a URL query string such as http://website/vulnapp.asp?SessionID=1, can you view other sessions by lying and specifying another ID such as http://website/vulnapp.asp?SessionID=100? Is the session ID information embedded in Web pages as a hidden input tag, and can you modify this information without being detected?
<input name=SessionId value= INSTYD0000010>
If an attacker can forge this data and not be detected, you’ve found a potential vector.
Review application code. If you have managed to gain access to the application code, you should review it for common coding mistakes. For instance, does the application blindly trust user input? Are sessions properly expired after a period of time or when a client logs off?
Here are some effective countermeasures against application-level session hijacking:
Educate developers. Your organization’s application developers should be educated about the threat of application-level session hijacking attacks. Having this education prior to developing code can greatly reduce common programming mistakes that could open the door to session hijacking attacks.
Design secure applications. Your organization should be designing its applications with the threat of session hijacking in mind. Appropriate mitigations to foil hijacking attempts should be built into the design of applications.
Use digital signatures. Keep the amount of critical data the attacker could potentially forge, such as session IDs and cookies, at zero or very close to it. Digitally signing this data makes it very difficult for attackers to mimic data or inject data into existing sessions, or to reuse old sessions. The less an attacker can lie about when interacting with your organization’s applications, the less likely she will be able to hijack sessions.