One of the difficult parts of compromising a system is to find a valid password that can be used to gain access. Especially if strong passwords
password or capture it another way, it is useless, because it changes the next time the user logs on to the system. Trying to find out a user’s password is one way to gain access, but because it is not always
successful, there is a better way. For example, let’s say an attacker waits for users to make a remote connection to a server via telnet. After the user successfully provides her password, the attacker takes over her current session and becomes that user. By doing this, the attacker does not need access to the user’s password, but still has an active,
authenticated connection to a server, where he can execute any command on the system.
Session hijacking is the process of taking over an existing active session.
One of the main reasons for hijacking a session is to bypass the authentication process and gain access to a machine. With session hijacking, a user makes a connection with a server by authenticating, which is done by providing his user ID and password. Here’s how it works:
After users authenticate, they have access to the server, and as long as they stay connected and active, they do not have to re-authenticate. That original authentication is good for the remainder of the session, whether the session lasts five minutes or five hours. This leaves the door open for an attacker to take over that session, which is usually done by taking the user offline (usually with a denial of service attack) and impersonating that user, which gives the attacker access to the server without ever having to log on to the system.
By hijacking a session, an attacker can steal a session, which involves taking over for the authenticated user. He can also monitor the session, where he just watches everything that is going by. When monitoring the session, he can record everything that is happening, so he can replay it at a later time. This is useful from a forensics standpoint for gathering
evidence for prosecution. It can also be useful from an attacker’s standpoint, for gathering information like user IDs and passwords. An attacker can also watch a session but periodically inject commands into the session. The attacker has full control of the session and can do what ever he wants, which ranges from passive attacks to very active attacks or anything in between.
When performing session hijacking, an attacker concentrates on session-oriented applications. This makes sense, because if an attacker’s goal is to gain access, he wants to take over a session where he can interact with a machine and execute commands. What is the value is taking over an HTTP or DNS session? By concentrating on session-oriented applications like telnet and FTP, the power of session hijacking techniques increases.
In this chapter, we will cover what session hijacking is, how it works, why it is so damaging, and what can be done to protect against it. As you will see throughout this chapter, one of the reasons why session hijacking can
be so damaging is that an attacker can perform these types of attacks across the Internet, which gives him access to a remote server or network Spoofing versus Hijacking
Spoofing and hijacking are similar, but there are some differences worth pointing out. A spoofing attack (see Chapter 4, “Spoofing”) is different from a hijack in that an attacker is not actively taking another user offline to perform the attack. Instead, he pretends to be another user or machine to gain access. While an attacker is doing this, the party he is spoofing can be at home or away on vacation for that matter—the real user plays no role in the attack. Therefore, the attacker is not actively launching an attack against a user’s session. With hijacking, an attacker is taking over an existing session, which means he is relying on the legitimate user to make a connection and authenticate. Then, he can take over a session.
This is done by actively taking the user offline.
One main difference between the two types of attacks is that spoofing only requires two parties to be involved—the attacker and the machine he is attacking. Figure 5.1 illustrates the spoofing process.
Figure 5.1. An attacker spoofing a victim named Bob.
As you can see, Bob plays no role in the spoofing attack at all. It doesn’t matter if Bob’s machine is turned on or even connected to the network.
From a session hijacking standpoint, Bob plays an active role, as shown in Figure 5.2.
Figure 5.2. An example of session hijacking.
With session hijacking, Bob has to make a connection and authenticate for the session to be hijacked. In this case, Bob must be active and make a connection for hijacking to be successful.
Types of Session Hijacking
With hijacking, there are two basic types of attacks: active and passive.
With a passive attack, an attacker hijacks a session, but just sits back and watches and records all of the traffic that is being sent back and forth.
This is useful for finding out sensitive information, like passwords and source code.
In an active attack, an attacker finds an active session and takes over.
This is done by forcing one of the parties offline, where the user can no longer communicate, which is usually done with a Denial of Service attack.
(For additional information on Denial of Service attacks, please see Chapter 6, “Denial of Service Attacks.”) At that point, the attacker acts like that user, takes over the session, and executes commands on the system that either give him sensitive information or allow him access at a later time.
There could also be hybrid attacks, where the attacker watches a session for a while and then becomes active by taking it over. Another variant is to watch a session and periodically inject data into the active session without actually taking it over.
Now we will briefly cover some TCP/IP concepts that you need to understand to see how session hijacking works in detail
TCP/IP Concepts
In most cases, when two computers want to communicate, the underlying protocols they use are either TCP or UDP and IP. The following is a list of the seven layers in the OSI model that are used for communication:
7) Application 6) Presentation 5) Session 4) Transport 3) Network 2) Datagram 1) Physical
For our discussion, we are concerned with layers 3 and 4. TCP and UDP are at layer 4, the transport layer. IP resides at layer 3, the network layer.
So, whether you use TCP or UDP, you still use IP as your layer 3 protocol.
TCP is reliable and UDP is unreliable. With session hijacking, because we are concerned with sessions or connection-oriented applications like telnet and FTP, we are also concerned with TCP.
TCP
Because TCP is a reliable protocol, it is connection oriented. It can guarantee whether or not two parties in a communication have
successfully received packets. If one of the parties does not receive a packet, TCP automatically resends it. For TCP to work properly, there has to be a connection established and some way to acknowledge that each packet or a group of packets has been received. This is done through the three-way handshake and sequence numbers.
Three-Way Handshake
For two parties to establish a connection using TCP, they perform what is called a three-way handshake. The three-way handshake initializes the connection and exchanges any of the necessary parameters that are needed for the two parties to communicate. Figure 5.3 illustrates how a three-way handshake works.
Figure 5.3. Illustration of the three-way handshake.
Bob wants to initiate a connection with the server. During the first leg of the three-way handshake, Bob sends a packet to the server with the synchronization (SYN) bit set saying, “I want to communicate with you.”
Having the SYN bit set indicates that the value in the sequence number (SN) field is valid. So, not only does Bob set the SYN bit, but also he sends a value for the initial sequence (ISN) number, which is sequence number for Bob (SN-B). (Sequence numbers will be covered in the section that follows). After the server receives this packet, it sends back a packet with the SYN bit set and an ISN for the server. It also sets the ACK bit acknowledging that it received the first packet and increments Bob’s SN by 1. That completes the second part of the three-way handshake. The last piece occurs when Bob sets the ACK bit saying that the machine acknowledges recipient of the packet and does that by incrementing the SN-S or the sequence number for the server by 1. At this point, the two machines have established a session and can begin communicating.
Sequence Numbers
Sequence numbers are very important to provide reliable communication but they are also crucial to hijacking a session. Sequence numbers are a 32-bit counter, which means the value can be any of over 4 billion
possible combinations. In the simplest sense, sequence numbers are used to tell the receiving machine what order the packets should go in when they are received.
Also, the receiving machine uses sequence numbers to tell the sender which packets have been received and which ones have not, so that the sender can resend the lost packets. For example, if the sender sends four packets with sequence numbers 1258, 1256, 1257, and 1255, the
recipient uses these numbers to put the packets back into the correct order, which is sequential. Also, the recipient uses the sender’s sequence number to acknowledge the receipt of the packets. In this case, the recipient sends back an acknowledgement of 1259, which says, “1259 is the next packet that I am expecting from the sender.”
Another key point of sequence numbers is that there is one for the sender and one for the receiver. Whenever the sender sends a packet, it uses the sender’s sequence number; and whenever the recipient acknowledges receiving a packet from the sender, it also uses the sender’s sequence number in the acknowledgement. On the other end, the receiver uses its own sequence numbers when sending data back. For example, if Bob and Alice are communicating, there are two different sequence numbers: one for Bob and one for Alice. Bob uses his sequence number for sending packets to Alice, and Alice uses Bob’s sequence numbers for
acknowledging which packets she received from Bob. Then, Alice uses her sequence number to send packets to Bob, and Bob uses this sequence number to acknowledge which packets he received from Alice.
Let’s briefly look at how sequence numbers are chosen. This is for an implementation of Linux but can be different, depending on how the operating system vendors implemented the TCP/IP protocol stack. First, when the system boots up, the sequence number is set to 1. The
sequence number is then incremented every second, usually by 128,000.
Now, if you calculate the math, this means that the sequence number wraps approximately every nine hours, if no connections are made.
However, if a connection is made, the sequence number is incremented by 64,000.
One reason sequence numbers are somewhat predictable is to prevent overlapping of sequence numbers. For example, if a packet gets caught up in a routing loop, it could arrive and have the same sequence number as an existing session, which could cause a lot of problems. This presents an interesting dilemma because as you will see, from a security standpoint, you would want the sequence numbers to be as random as possible; but from a functionality standpoint, the less random the better. The following example is sniffer output from an initial connection showing how the sequence numbers work. The computer with the IP address of
10.246.68.46 sends a packet to computer 10.246.68.48 with the SYN bit set and an initial sequence number of 2881395377, as follows:
03:12:26.309374 eth0 P 10.246.68.46.3419 >
10.246.68.48.telnet: S
2881395377:2881395377(0) win 8192 <mss 1460,nop,nop,sackOK>
(DF)
Next, computer 10.246.68.48 replies to 10.246.68.46 with the SYN bit set and an initial sequence number of 2427498030. Because this is the
second leg of the three-way handshake, it also has the ACK bit set and is saying that the next byte it is expecting from machine 10.246.68.46 is 2881395378, which is the initial sequence number plus 1, as follows:
03:12:26.309435 eth0 P 10.246.68.48.telnet >
10.246.68.46.3419: S
2427498030:2427498030(0) ack 2881395378 win 32120 <mss 1460,nop,nop,sackOK> (DF)
Finally, computer 10.146.68.46 completes the last leg of the three-way handshake by sending a packet back to 10.246.68.48 with the ACK bit set, as follows:
03:12:26.309538 eth0 P 10.246.68.46.3419 >
10.246.68.48.telnet: .
The preceding shows a three-way handshake for a telnet session. Here you can see the initial sequence numbers that are sent in the first two packets. After that, you can see the acknowledgement of subsequent sequence numbers and the next packet each side is expecting.
What Is TCPdump?
TCPdump is a sniffer program that is available on most versions of Linux. Depending on which installation options were used to install the software, it might be installed by default. If you type tcpdump and the program does not start, you might have to manually
install it off of the distribution CDs.
As you can see from the preceding examples, TCPdump is a good program for pulling off network traffic and seeing what is occurring on your network. It has numerous options that can be used to filter certain fields. For additional information, you can type man tcpdump on your system to get additional information and
examples of how it can be used on your network.
There is also a port of TCPdump for the Windows platform called windump. It runs in a DOS window but has similar features and functionality.
At this point, you have enough information to understand the basics of session hijacking and the topics presented in this chapter. Now it is time to look at session hijacking up close. For a more detailed explanation of the TCP/IP protocols, please refer to TCP/IP Illustrated, Volume 1 by Stevens.
Detailed Description of Session Hijacking
Let’s take a closer look at exactly what has to happen to hijack a session.
The following are the main steps that must be taken to perform an active session hijack, where the goal is to take over an existing session:
1. Find a target.
2. Perform sequence prediction.
3. Find an active session.
4. Guess the sequence numbers.
5. Take one of the parties offline.
6. Take over the session.
Find a Target
This might seem obvious, but to hijack a session, the attacker must find a suitable target. There are some key points he observes when searching for a suitable target. First, he usually wants the target to be a server that allows session-oriented connections like telnet and FTP. Also, from a firewall standpoint, the attacker probably wants to make sure he can get access to the target beforehand to sample the sequence number. For example, if a firewall only allows a certain address through the firewall to the server, he might be able to hijack that session; but it is difficult to perform because he could not access the server ahead of time and find out some initial information.
Perform Sequence Prediction
Depending on the session he is taking over and whether he can observe the traffic before hijacking the session, the attacker might have to be able to guess the sequence number. This can be easy or difficult depending on which operating system is being used. The following is output from nmap that shows the level of difficulty with guessing sequence numbers on various operating systems (to have nmap perform operating system fingerprinting, you would type the following command nmap –O ip-address):
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on (10.246.68.46):
(The 1516 ports scanned but not shown below are in state:
closed)
Port State Service 25/tcp open smtp 79/tcp open finger 106/tcp open pop3pw 107/tcp open rtelnet 110/tcp open pop-3
139/tcp open netbios-ssn 427/tcp open svrloc
TCP Sequence Prediction: Class=trivial time dependency Difficulty=1 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98 Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on (10.246.68.48):
(The 1510 ports scanned but not shown below are in state:
closed)
Port State Service 21/tcp open ftp 23/tcp open telnet 25/tcp open smtp 79/tcp open finger 98/tcp open linuxconf 111/tcp open sunrpc 113/tcp open auth 513/tcp pen login 514/tcp open shell 515/tcp open printer 948/tcp open unknown 1024/tcp open kdm 6000/tcp open X11
TCP Sequence Prediction: Class=random positive increments Difficulty=1872725 (Good luck!) Remote operating system guess: Linux 2.1.122 - 2.2.14
Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
One of the things nmap uses to determine the operating system is the predictability of the sequence numbers on the remote operating system.
In this case, you can see that Windows operating systems have very predictable sequence numbers, whereas Linux has very hard-to-guess sequence numbers.
Also, to show you how sequence number prediction is done, the attacker connects to a machine several times to see how the numbers change over time. The following are some sample sequence numbers from trying to connect to a Linux system from a Windows system several times. Only the initial sequence numbers are shown for each side. Essentially, the first two legs of the three-way handshake are shown, which means there are two packets for each connection, and I connected five times:
1st connection
04:54:35.209720 eth0 P 10.246.68.46.3428 >
10.246.68.48.telnet: S
2887495515:2887495515(0) win 8192 <mss 1460,nop,nop,sackOK>
(DF)
04:54:35.209887 eth0 P 10.246.68.48.telnet >
10.246.68.46.3428: S
321765071:321765071(0) ack 2887495516 win 32120 <mss 1460,nop,nop,sackOK> (DF)
2nd connection
04:54:40.195616 eth0 P 10.246.68.46.3429 >
10.246.68.48.telnet: S
2887500502:2887500502(0) win 8192 <mss 1460,nop,nop,sackOK>
(DF)
04:54:40.195694 eth0 P 10.246.68.48.telnet >
10.246.68.46.3429: S
332010905:332010905(0) ack 2887500503 win 32120 <mss 1460,nop,nop,sackOK> (DF)
3rd connection
04:54:46.799968 eth0 P 10.246.68.46.3430 >
10.246.68.48.telnet: S
2887507109:2887507109(0) win 8192 <mss 1460,nop,nop,sackOK>
(DF)
04:54:46.800040 eth0 P 10.246.68.48.telnet >
10.246.68.46.3430: S
338617656:338617656(0) ack 2887507110 win 32120 <mss 1460,nop,nop,sackOK> (DF)
4th connection
04:54:52.001391 eth0 P 10.246.68.46.3431 >
10.246.68.48.telnet: S
2887512311:2887512311(0) win 8192 <mss 1460,nop,nop,sackOK>
(DF)
04:54:52.001473 eth0 P 10.246.68.48.telnet >
10.246.68.46.3431: S
339459049:339459049(0) ack 2887512312 win 32120 <mss 1460,nop,nop,sackOK> (DF)
5th connection
04:54:56.805266 eth0 P 10.246.68.46.3432 >
10.246.68.48.telnet: S
2887517117:2887517117(0) win 8192 <mss 1460,nop,nop,sackOK>
(DF)
04:54:56.805348 eth0 P 10.246.68.48.telnet >
10.246.68.46.3432: S
334021331:334021331(0) ack 2887517118 win 32120 <mss 1460,nop,nop,sackOK> (DF)
Table 5.1 is a summary chart showing the ISN (initial sequence numbers) for each side of the connection.
Table 5.1. Comparison of sequence numbers on a Windows and Linux system.
Connection Number Windows Client Linux Server
1 2887495515 321765071
2 2887500502 332010905
3 2887507109 338617656
4 2887512311 339459049
5 2887517117 334021331
As you can see, this information confirms what nmap already told us—
Windows sequence numbers are much more predictable than Linux sequence numbers.
Find an Active Session
Now let’s look at how an attacker finds an active session. Because he is actively taking over a session, there needs to be a legitimate user’s connection that he can take over. Therefore, contrary to most attacks,
Now let’s look at how an attacker finds an active session. Because he is actively taking over a session, there needs to be a legitimate user’s connection that he can take over. Therefore, contrary to most attacks,