Hacking: Fight Back

Theft On The Web: Prevent Session Hijacking

Kevin Lam, David LeBlanc, and Ben Smith

At a Glance:

• TCP hijacking mechanics
• ACK packet storms
• UDP attacks
• Network attack prevention

TCP/IP

Network Security

When computers need to talk to each other, they simply do so. But, how do you know that your computer is really talking to the computer it thinks it's talking to?

How do you know that an attacker has not taken over the session between the computers and is passively monitoring the conversation, or even changing it? You would certainly know it—belatedly—if the order for 1,000 widgets that you sent to a business partner was received as an order for 100,000 widgets. This can happen, courtesy of a well-timed strike by an intruder.

Right now, you might be asking:

• "How does this work?"
• "Is my network susceptible to this?"
• "What can I do to prevent this from happening?"

Session hijacking works by taking advantage of the fact that most communications are protected (by providing credentials) at session setup, but not thereafter. These attacks generally fall into three categories: Man-in-the-middle (MITM), Blind Hijack, and Session Theft.

In MITM attacks, an attacker intercepts all communications between two hosts. With communications between a client and server now flowing through the attacker, he or she is free to modify their content. Protocols that rely on the exchange of public keys to protect communications are often the target of these types of attacks.

In blind hijacking, an attacker injects data such as malicious commands into intercepted communications between two hosts commands like "net.exe localgroup administrators /add EvilAttacker". This is called blind hijacking because the attacker can only inject data into the communications stream; he or she 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 will see shortly, this method of hijacking is still very effective.

In a session theft attack, the attacker neither intercepts nor injects data into existing communications between two hosts. Instead, the attacker creates new sessions or uses old ones. This type of session hijacking is most common at the application level, especially Web applications.

Session hijacking at the network level is especially attractive to attackers. They do not need host access, as they do with host-level session hijacking. Nor do they need to customize attacks on a per-application basis, as they do at the application level. Network-level session hijacking attacks allow attackers to remotely take over sessions, usually undetected. But successfully hijacking a session at the network level requires an attacker to overcome various obstacles, as you will see in the next few sections.

Hijacking a TCP Session

One of the key features of TCP is reliability and ordered delivery of packets. To accomplish this, TCP uses acknowledgment (ACK) packets and sequence numbers. Manipulating these is the basis for TCP session hijacking. As we mentioned earlier, the MITM attacker simply needs to be positioned so that communications between the client and the server are relayed through him or her. To understand how an attacker might sneak 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 1, the client first initiates a session with the server by sending a synchronization (SYN) packet to the server with initial sequence number 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 expects from the client. 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). The client and server are ready to start exchanging data.

The sequence number values just described are important for understanding how to successfully hijack this session later, so pay close attention to them in the paragraphs that follow. The same goes for ACK numbers, which are key to understanding TCP ACK storms.

Figure 1** TCP Three-Way Handshake **

For now, observe what happens to these sequence numbers when the client starts sending data to the server (see Figure 2). In order to keep the example simple, the client sends the character A in a single packet to the server.

Figure 2** Sending Data over TCP **

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 1 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 or she would need to:

• Spoof the client's IP address
• Determine the correct sequence number that is expected by the server from the client
• Inject data into the session before the client sends its next packet

The first and second tasks are easily accomplished, but the third is a bit trickier. Tricky, but not impossible. Essentially, the attacker needs a way to prevent 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, as shown in Figure 3. Or, he or she could perform a denial of service (DoS) attack on the client, or perhaps some tricks that use address resolution protocol (ARP) spoofing.

Figure 3** Blind Injection **

Here is how this might play out. 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 acknowledgment 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 did not 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 see later, this confusion can cause a TCP ACK storm, which can disrupt a network. In any case, the attacker has now successfully hijacked this session.

Attackers can automate the session hijacking process just described with tools such as Juggernaut, by Mike Schiffman, and Hunt, by Pavel Krauz.

Hijacking a UDP Session

Hijacking a session over a User Datagram Protocol (UDP) is exactly the same as over TCP, except that UDP attackers do not 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 4 shows how an attacker could do this.

Figure 4** Session Hijacking over UDP **

DNS queries, online games like the Quake series and Half-Life, and peer-to-peer sessions are common protocols that work over UDP; all are popular targets for this kind of session hijacking.

Determining Susceptibility

One obvious way to determine the susceptibility of your organization's networks 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 approach would be simply to find out if your organization uses transport protocols that do not use cryptographic protection (such as encryption) for transport security or digital signatures for authentication verification. Common examples of these protocols include Telnet, FTP, and DNS. If such network protocols exist in your organization's networks, sessions traveling over those unencrypted protocols are ripe for hijacking.

What countermeasures can you take to reduce your susceptibility to network-level session hijacking attacks? One technique is to implement encrypted transport protocols such as Secure Shell (SSH), Secure Socket Layers (SSL), and Internet Protocol Security (IPSec). An attacker attempting to hijack a session by tunneling in an encrypted transport protocol must, at a minimum, know the session key used to protect that tunnel, which should be 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. Even in the unlikely event that an attacker is able to attain the prized session key, digitally signing network traffic provides an extra layer of defense against the successful injection of malicious data into network sessions.

As a rule, 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, extremely susceptible to hijacking when not protected inside encrypted tunnels.

Tricks and Techniques

Successfully hijacking a network session depends on a few conditions falling into place, so an attacker 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 or her. To make this happen, he or she can use tricks with Internet Control Message Protocol (ICMP) Redirect packets or ARP spoofing.

As you read through the attack strategies 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 cannot inject data into a session. Routing table modifications also quickly become a wasted effort for an attacker if they cannot interpret or modify data that gets routed through them. It is still useful and interesting, however, to know what your enemy has in his or her bag of tricks. Some common items include TCP ACK packet storms, ARP table modifications, TCP resynchronizations, and remote modifications of routing tables.

TCP ACK Packet Storms

If an attacker is not careful when hijacking TCP sessions in your organization's networks, those networks can be disrupted by TCP ACK packet storms.

To understand this threat, look at what happens when an attacker hijacks a TCP session from the TCP protocol's point of view. Assume 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 to the server-injected session data, the server will acknowledge the receipt of the data by sending to 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 will in turn contain a sequence number that the server is not expecting, 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 5.

Figure 5** ACK Storm **

As the attacker injects more and more data, the size of the ACK storm increases and can quickly degrade network performance. If neither the attacker nor the client explicitly closes the session, the storm will likely stop itself eventually when ACK packets are lost in the storm.

ARP Table Modifications

The address resolution protocol is used by each host on an IP network to map local IP addresses to hardware addresses or MAC addresses. Here is a quick look at how this protocol works.

Say that Host A (IP address 192.168.1. 100) wants to send data to Host B (IP address 192.168.1.250). No prior communications have occurred between Hosts A and B, so the ARP table entries for Host B on Host A are empty. As shown in Figure 6, Host A broadcasts an ARP request packet indicating that the owner of the IP address 192.168.1.250 should respond to Host A at 192.168.1.100 with its MAC address. The broadcast 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 will see shortly, this is not always the case.) All other hosts discard this request packet, but 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 can now send data to Host B.

Figure 6** Finding the Owner of a MAC Address **

Can you see the security problem here? Does Host A know that Host B really did send the ARP reply? The answer is no, 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 E0:E0:E0:E0:E0:E0 corresponds to Host B's IP address, as shown in Figure 7. Host A would then send any traffic intended for Host B to the attacker, and the attacker could choose to forward that data (probably after some tampering) to Host B.

Figure 7** Spoofed Reply **

Attackers can also use ARP packet manipulation to quiet TCP ACK storms, which are noisy and easily detected by devices such as intrusion detection system (IDS) sensors (see Figure 8). 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/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.

Figure 8** Stopping a TCP ACK Storm **

TCP Resynchronizing

To hide his or her tracks, an attacker who is finished with the session hijacking attack might want to resynchronize the communicating hosts. The problem is that after the attack, the two hosts whose session was hijacked will be at different points in the session. In other words, each host will be expecting different sequence numbers.

For example, the server might think 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, it's not possible with TCP stacks to manipulate the server so that its expected sequence number moves downward to match the client's sequence number.

In this situation, 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. Here is an example (note that the number 13 is used arbitrarily):

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. When the user has typed enough characters, Hunt will use more forged ARP reply packets to restore the correct values to the ARP table entries it modified on the client and server to avoid TCP ACK storms.

This technique of resynchronizing client and server TCP stacks is dependent on the user following instructions sent by the Hunt tool, and will probably not work against well-educated users or any protocol other than Telnet or possibly FTP.

Remotely Modifying Routing Tables

As discussed earlier, an attacker who wants to hijack a session at the network level wants to route all communications between a client and server through him or her, making it easy to monitor, modify, and inject data into the session, as in MITM attacks. This boils down to the attacker tricking one of the hosts, usually the client, into routing all its session traffic through the attacker. 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 ICMP Redirect (type 5) packets and advertise them as the route to take when sending data.

To protect Windows® hosts from forged ICMP redirect attacks, set the EnableICMPRedirect value to 0 under the registry key HKLM\System\CurrentControlSet\Services\AFD\Parameters.

Conclusion

Protecting network sessions that carry sensitive and important data such as credit card numbers, bank transactions, and administrative server commands is an important first step at improving the security posture of your organization. By removing an attacker's ability to inject data into those sessions, you raise the security bar and force your adversary to try other, more complex avenues that are less likely to compromise your organization's security.

Kevin Lam, David LeBlanc, and Ben Smith all work on security at Microsoft. Ben is the coauthor of Microsoft Windows Security Resource Kit and David is the coauthor of Writing Secure Code 2 (both from Microsoft Press).

This article is adapted from Chapter 21 of Assessing Network Security (Microsoft Press, 2004).

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.