Detecting Session Hijacking

Session hijacking can be difficult to detect and goes completely unnoticed in most cases unless the attacker causes severe damage or draws attention to his presence in the system. Users might notice a few symptoms during a hijacking. For example, their client application (Telnet) session stops responding or freezes. Another symptom is a burst of network activity for a short period, which slows down the computer.

Another common symptom is when the client application hangs for some time because you are actually competing with the hijacker, who is also sending data to the server. This causes the program to become confused and wait for a response from Layer 4. Next is the network that becomes busy because of an ACK storm between the original client and the server when the hijacked client attempts to send more data to the server that is out of sync with what the server is expecting. However, normal and even advanced computer users rarely report these two symptoms because the problems look so much like other common issues, such as applications crashing, busy servers, or a network under heavy load-dropping connections.

A user who is experiencing a "hanging" application usually just closes the original and opens another. In the meantime, the hacker is probably having a heyday with the previously authenticated session created by the real user.

Security professionals can use a few tools to help in detection. Packet sniffers and IDSs are the two discussed in the sections that follow. Always monitor SANS or other great security websites for newer tools to use.

Tip

Switches cannot completely stop session hijacking; however, implementing a switched network can make attacks significantly more difficult for the attacker.

Note

Session hijacking can affect all operating systems because it is not really an operating system issue. The problem lies within the TCP and how it was engineered its primary purpose being to ensure highly reliable data transmission.

The sections that follow examine both of these tools in action when monitoring and detecting a standard session being hijacked. To set the scene, Figure 6-18 displays the network with all connections via a simple hub.

Figure 6-18. Detection Network

The parameters for this network are as follows:

• Typical client

  - OS: Linux

  - IP address: 192.168.200.21

  - MAC address: 00-11-2F-0F-6E-DB

  - Application: Telnet client

• Telnet server (victim)

  - OS: Windows 2003 Server

  - IP address: 192.168.200.100

  - MAC address: 00-50-56-00-EE-EE

  - Application: Telnet server (port 23)

• Attacker (Evil Jimmy the Hacker)

  - OS: Windows 2000 Professional

  - IP address: 192.168.200.13

  - MAC address: 00-50-56-00-0B-AD

  - Application: T-sight (for attack)

• Ethereal (packet sniffer)

In Figure 6-18, the Linux client will be connecting to the Windows 2003 Server via Telnet. You might wonder why anyone would want to control a Windows server in this way. Well, no good old-timer *nix or Linux person would use a GUI to administer a server (even a Windows one). If you dig deep into Windows 2003, it is rare for an administrative task to be exposed to command-line entry, which is quite handy. Administrators can add, update, and remove items via the command line (Telnet) to active directory. In reality, the demonstration holds for several scenarios, and you might equally be Telneting to a Cisco router or PIX Firewall with the Telnet server feature enabled and witness the same results.

Detecting Session Hijacking with a Packet Sniffer

You can use a packet sniffer to monitor a hijacking; however, it can be a little difficult if you do not know which traffic is significant. You need to watch out for three things:

• ARP updates (repeated)

• Frames sent between client and server with different MAC addresses

• ACK storms

Keep these three items in mind as you move through the process.

Configuring Ethereal

In the following example, Ethereal (http://www.ethereal.com) will be used as the packet sniffer to monitor a session hijacking attempt. The steps to configure Ethereal are as follows:

Step 1.	Start Ethereal.
Step 2.	Select Start from the Capture menu on the toolbar or press Ctrl-k. (See Figure 6-19.) Figure 6-19. Ethereal
Step 3.	In the Capture Options dialog box, in the Display Options section, select and enable the following: - Update list of packets in real time. - Automatic scrolling in live capture. - Hide capture info dialog. (See Figure 6-20.) Figure 6-20. Ethereal: Capture Options Click OK.
Step 4.	Ethereal should now be in sniffing mode. When traffic starts to be detected, you will see packets of data.

Watching a Hijacking with Ethereal

Now that you have your packet sniffer up and running, you will be watching a connection from start to finish. First, notice the initial ARP requests that translate IP-to-MAC address between the client and server. (See Figure 6-21.) Next in frames 3 through 5, observe the three-way handshake between the Linux client (00-11-2F-0F-6E-DB) and the Telnet server (00-50-56-EE-EE-EE).

Figure 6-21. Ethereal: Three-Way Handshake

At this point, the hijacker just waits in the background for the Linux user to log in. The hijacker could be merely looking to capture the password or perhaps waiting until the authentication has been completed before taking over the session. (See Figure 6-22.) Even though Telnet passwords are readable from a standard network sniffer, some implementations use one-time passwords (OTPs), which are not reusable. Session hijacking comes in quite handy in these cases.

Figure 6-22. Ethereal: Normal Telnet Data

One thing to point out is that the ARP tables of both client and server correctly map to one another. Example 6-6 shows the output of the Windows arp command to demonstrate what the current IP-to-MAC is on the server.

Example 6-6. Determining the IP-to-MAC Address Mapping

C:/>arp -a Interface:   Internet Address   Physical Address      Type   192.168.200.21     00-11-2F-0F-6E-DB    dynamic

Note

The Windows ARP cache automatically removes idle entries after two minutes, whereas active entries are flushed after ten minutes. Manual entries are not flushed. However, you can amend these parameters in most operating systems.

Normal traffic flows between the client and the server. Next, see what happens when the hacker tries to take over this Telnet session. When T-Sight begins a hijacking, he attempts to force a new IP-to-MAC address mapping into the ARP table of the server. Three ARP replies are sent to the server, as shown in frames 109 to 111 of Figure 6-23. (This could be the first symptom of a hijacking.)

Figure 6-23. Ethereal: Forcing an ARP Entry

This fools the server into thinking that the MAC address for the client at IP address 192.168.200.21 has changed and the server should update its internal ARP cache to reflect the change. After the server has changed its ARP cache, all IP packets sent to 192.168.200.21 are encapsulated into a frame that is actually destined to the hacker computer via Layer 2. Note that T-Sight uses a custom MAC of EA:1A:DE:AD:BE:EF (which spells "dead beef"). Example 6-7 shows the server ARP table before and after the hijacking.

Example 6-7. Server ARP: Before and During Hijacking

! Before Hijacking Attempt                                  C:/>arp -a Interface:   Internet Address     Physical Address    Type   192.168.200.21       00-11-2F-0F-6E-DB   dynamic ! After Hijacked Attempt                                    C:/>arp -a Interface:   Internet Address     Physical Address    Type   192.168.200.21       EA-1A-DE-AD-BE-EF   dynamic

The server starts, unknowingly, to respond to the hacker computer (MAC address). Next, T-Sight picks up where the last sequence numbers left off and allows the hacker to start sending data and commands straight to the server. Figure 6-24 shows hijacked traffic, which is virtually identical to normal traffic.

Figure 6-24. Ethereal: Hijacked!

Layer 3 IP traffic looks like normal traffic, so how can you tell if it is involved in a session hijacking? This brings up the second item to look out for. Taking a closer look, you can see a slight flaw in the Layer 2 frames. The T-Sight hijacker is spoofing frames with the real MAC address of the Linux client (00:11:2f:0f:6e:db) and not his own MAC address. This is a good way to cover his tracks, except the server in reply is responding and sending frames back, not to (00:11:2f:0f:6e:db) but to the MAC address in its current ARP table (EA:1A:DE:AD:BE:EF) the hacker! See frames 112 and 113 in Example 6-8; they show the different MAC address in the frames. This is not normal on a network; MACs in both directions should be the same.

Example 6-8. Spoofed MAC Address

---------- Frame 112 sent from hijacker to server ---------- Source               Destination 192.168.200.21-----> 192.168.200.100 Ethernet II, Src: 00:11:2f:0f:6e:db, Dst: 00:50:56:ee:ee:ee     Destination: 00:50:56:ee:ee:ee (192.168.200.100)     Source: 00:11:2f:0f:6e:db (192.168.200.21)                           Internet Protocol,     Src Addr: 192.168.200.21 (192.168.200.21)     Dst Addr: 192.168.200.100 (192.168.200.100) Transmission Control Protocol     Src Port: 32772 (32772)     Dst Port: telnet (23)     Seq: 150, Ack: 544, Len: 1 ---------- Frame 113 Response from server to the client (hacker) ---------- Source                   Destination 192.168.200.100-----> 192.168.200.21 Ethernet II, Src: 00:50:56:ee:ee:ee, Dst: ea:1a:de:ad:be:ef     Destination: ea:1a:de:ad:be:ef (192.168.200.21)                          Source: 00:50:56:ee:ee:ee (192.168.200.100) Internet Protocol,     Src Addr: 192.168.200.100 (192.168.200.100)     Dst Addr: 192.168.200.21 (192.168.200.21) Transmission Control Protocol     Src Port: telnet (23)     Dst Port: 32772 (32772)     Seq: 544, Ack: 151, Len: 1

The final symptom is the activity of an ACK storm. As a reminder, while the client and server communicate, the sequence numbers increase in proportion to the amount of data they have sent between each other, as explained previously. When a hijacker takes over a session, the sequence numbers continue to increment as data is sent between the two. If enough data is transmitted while the hijacker and server are communicating, the original client (Linux in this case) goes out of sync. This is not a problem as long as the original client does not send packets. However, if the original client types even one character resulting in the sending of a packet to the server, the sequence number it sends is goes out of sync. This is because it sends the last one remembered, say SEQ 199, which is now out of sync for the server (which is expecting SEQ 325). The server that is receiving this older packet responds with an ACK back to the client to SEQ 325, not SEQ 199.

This is where it starts to get especially interesting. The client resends its data with SEQ 199; however, the server responds again with an ACK for SEQ 325. The client again sends data for SEQ 199, and the ACK storm begins. The two battle to try to resync each other, which theoretically could go on forever. Figure 6-25 shows an example of an ACK storm monitored with Ethereal.

Figure 6-25. Ethereal: ACK Storm

If you look closely, you can see Ethereal detailing TCP Dup ACK and TCP Out-of-Order messages. Should you see these scrolling across your network sniffer or IDS, a hijacking might well have taken place. Now the original client is trying to communicate during the hijacking.

Tools such as Hunt help prevent ACK storms by changing MACs in ARP tables and making them hard to detect. This adds to the likelihood of a hijacking going unnoticed. Therefore, bear in mind that you might not always see ACK storms when a hijacking takes place.

Detecting Session Hijacking with Cisco IDS

As outlined in the previous section, you can use packet sniffing to aid in hijacking detection. The effort and amount of time it would take a network administrator to visually monitor the traffic in real-time, however, does not make for a practical solution for the enterprise. On the other hand, IDSs such as the Cisco network-based 4200 series IDS systems have built-in signatures that can detect some forms of hijacking. This section provides examples of how a 4215 might behave during a session hijacking. To set the scene, Figure 6-26 displays a network with an IDS and a backend console with IDS Event Viewer (IEV) installed to monitor alarms.

Figure 6-26. Ethereal: IDS Network

This example of detecting session hijacking with Cisco IDS assumes the following network setup:

• Typical client

  - OS: Linux

  - IP address: 192.168.200.21

  - MAC address: 00-11-2F-0F-6E-DB

  - Application: Telnet client

• Telnet server (victim)

  - OS: Windows 2003 Server

  - IP address: 192.168.200.100

  - MAC address: 00-50-56-00-EE-EE

  - Application: Telnet server (port 23)

• Attacker (Evil Jimmy the Hacker)

  - OS: Windows 2000 Pro

  - IP address: 192.168.200.13

  - MAC address: 00-50-56-00-0B-AD

  - Application: T-Sight (for attack)

• IDS Sensor (DAWN-IDS)

  - Model: Cisco 4215 Sensor

  - Standard install

  - Web interface IDS Device Manager (IDM) to configure the sensor

• IDS Console

  - OS: Windows XP

  - IEV to monitor events

Cisco 4215 has three basic signatures on which to focus during the detection of session hijacking:

• 1300 TCP Segment Overwrite

• 3250 TCP Hijack

• 3251 TCP Hijacking Simplex Mode

First, you log in to the IDM IDS Management Center web interface to access the Network Security Database (NSDB) and the signature engine. The steps to do this are as follows:

Note

Cisco IDS 4200 series sensors run on Red Hat Linux and come with at least two interfaces (network cards). One interface is for sensing, and the other is designed to link to a secure LAN used to control and configure alarm monitoring.

Step 1.	On the computer that is connected to the Command and Control LAN, open Internet Explorer to the default path of https://10.1.9.201.
Step 2.	Enter your login credentials. (See Figure 6-27.) Figure 6-27. IDS Login Dialog Box
Step 3.	You should now be at the default page. (See Figure 6-28.) Figure 6-28. Default IDS Device Manager Page

Signature 1300: TCP Segment Overwrite

The segment overwrite does not always show up, but it is noticed quite often during a T-Sight session hijack. The NSDB provides the best description for this signature:

This signature fires when one or more TCP segments in the same stream overwrite data from one or more segments located earlier in the stream. This may indicate an attempt to hide an attack. Overwriting TCP segments do not normally occur and should be treated with suspicion.

To open the NSDB database for more detail about TCP Segment Overwrite, click the NSDB link in the top-right corner of the IDS Device Manager web page. Then navigate to Signature 1300. Figure 6-29 displays the NSDB entry for TCP Segment Overwrite.

Figure 6-29. Signature 1300: TCP Segment Overwrite

Signature 3250: TCP Hijack

The 3250 signature can be a little touchy in firing off. To make it a little more sensitive, you need to modify a few of its basic parameters. The NSDB provides the best description for this signature:

Triggers when both streams of data within a TCP connection indicate that a TCP hijacking may have occurred. The current implementation of this signature does not detect all types of TCP hijacking, and false positives may occur. Even when hijacking is discovered, little information is available to the operator other than the source and destination addresses and ports of the systems being affected. TCP hijacking may be used to gain illegal access to system resources.

Figure 6-30 shows the NSDB entry for the TCP Hijack signature.

Figure 6-30. Signature 3250: TCP Hijack

The TCP Hijack signature is enabled right out of the box, although its settings might be a little too lenient by default and fail to fire during a legitimate hijack. Table 6-1 shows the two basic settings to change before beginning with detection.

Table 6-1. Parameters to Modify for the TCP Hijack Signature

Parameter	Default	Change to (Tuned)	Description
CapturePack	False	True	Set to True to include the offending packet in the alarm
HijackMaxOldAck	200	20	Maximum number of old dataless client-to-server acknowledgments is allowed before triggering a hijack

To configure the signature:

Step 1.	From the IDM, click the Configuration tab.
Step 2.	Click the Sensing Engine link on the top.
Step 3.	On the left under Virtual Sensor Configuration, click Signature Configuration Mode. (See Figure 6-31.) Figure 6-31. Signature Configuration Mode
Step 4.	Click the All Signatures link.
Step 5.	On the web pull-down called Page, select the signature range that includes 3250. (See Figure 6-32.) Figure 6-32. All Signatures
Step 6.	Check the square box next to the 3250 signature; then click Edit. (See Figure 6-33.) Figure 6-33. Editing a Signature
Step 7.	Now change the CapturePack to True and hijackMaxOldAck to 20. Click OK. (See Figure 6-34.) Figure 6-34. Modifying and Accepting a Signature
Step 8.	Click the Activity icon in the upper-right corner of the page to save your settings to the IDS.

Signature 3251: TCP Hijacking Simplex Mode

The 3251 signature is the simplex mode hijacking, whereby a command is injected and then followed by a TCP reset. Again, the NSDB provides the best description for this signature:

Triggers when both streams of data within a TCP connection indicate that a TCP hijacking may have occurred. The current implementation of this signature does not detect all types of TCP hijacking, and false positives may occur. Even when hijacking is discovered, little information is available to the operator other than the source and destination addresses and ports of the systems being affected.

TCP hijacking can be used to gain illegal access to system resources.

Simplex mode means that only one command is sent, followed by a connection RESET packet, which makes recognition of this signature different from regular TCP Hijacking (sigID 3250).

Figure 6-35 shows the Network Security Database entry for the TCP Hijacking Simplex Mode signature.

Figure 6-35. Signature 3251: TCP Hijacking Simplex Mode

Note

The Cisco IEV is a Java-based application that enables you to view and monitor up to five different IDS sensors at the same time. IEV supports real-time alarm monitoring or historical analysis. IEV integrates with Ethereal for packet analysis and with the NSDB for alarm and signature descriptions.

Watching a Hijacking with IEV

Now that the Cisco IDS is ready to go, this section shows how you can see alarms and events within IEV. First, open your IEV application and make sure it is configured to connect to your IDS device. Then open the Realtime Dashboard. (See Figure 6-36.)

Figure 6-36. Opening the IEV Application

This dashboard is a great place to monitor alarms and events while they happen. Now as your session hijacking takes place, the dashboard pulls the alarm from the IDS sensor and displays it on the screen. As Figure 6-37 displays, the sensor picked up the TCP Hijack signature alarm. This alarm usually fires when the original client tries to send data after the hijacking is in progress rather than when a hijacking first took place. When the original client attempts to send data during a hijacking in progress, this causes an ACK storm, which is monitored by the sensor for the count of 20. On the twenty-first event, the alarm is triggered and the packet is recorded. One thing to point out is that the IDS reports an alarm only if the original client sends data traffic. If the original client never sends data, the IDS does not generate an alarm.

Figure 6-37. TCP Hijack Signature Detected

Now you have an alarm and packet recorded. You can open the offending packet that triggered the alarm with Ethereal. Figure 6-38 shows how to right-click the alarm and select Show Captured Packet from the resulting drop-down menu. Figure 6-39 displays the captured packet within Ethereal.

Figure 6-38. Launching Ethereal from the Realtime Dashboard

Figure 6-39. Ethereal Displaying the Offending Packet Details

Note

The Cisco IEV interlinks with Ethereal if it is installed for packet analysis.

In a controlled environment with T-Sight, you might see the 1300 signature alarm first, and then shortly after a TCP Hijack, you might see signature 3250. Figure 6-40 shows both signatures picked up during a single session hijacking.

Figure 6-40. Multiple Signatures Detected by IEV