Fibre Channel and IP session hijacking assessment exercise

Assessment exercise: session hijacking

In order to better understand session hijacking, we will demonstrate an example using an IP network and also using the tool called Hunt, which works solely on the Unix/ Linux platform. While Hunt is a great tool, you might have to try it several times to get it to work correctly. Based on Figure 2.6, server C will be the malicious user hijacking a session from server A to server B. The following steps outline the method to perform session hijacking:

1. On server C, download Hunt from http://lin.fsid.cvut.cz/~kra/#HUNT.
2. Unzip Hunt: a. cd /usr/local/bin b. gunzip --c hunt.tar.gz | tar xvf –
3. Compile Hunt: c. cd /usr/local/bin/hunt-1.5 d. make e. make install
4. Execute Hunt: f. ./hunt
5. On server A, telnet to server B, using the telnet command: g. telnet serverB
6. On server C, choose option A (see Figure 2.7).
7. On a hub (or a switch using arpspoof), you should see the Telnet session from server A (10.10.80.122) to server C (128.101.81.1) with Hunt.
8. At the choose conn> prompt, enter 0 to hijack the session (see Figure 2.8).
9. Accept all the defaults (labeled in brackets) until you see the target session (see Figure 2.9).

   

   Figure 2.7 Hunt's options.

   

   Figure 2.8 Telnut session with Hunt

   

   Figure 2.9 Hunt's defaults.

10. Ensure the user on server A continues to type and is not sitting idle with the telnet prompt.
11. Back on server C, if the user on server A is using the Telnet session, you will be able to either watch the session or hijack it at any time by pressing the Enter key a couple of times (preferably after the user has su to root!!!). Once you have hijacked the session, Hunt will inform you that "you took over the connection."
12. Done. Server C has now hijacked the Telnet session from server A to server B due to poor session information in the Initial Sequence Number of the TCP header (see Figure 2.10).

Based on our attack here, the IP session hijacking will be classified as a high security risk, since authentication can be subverted from a malicious attacker. Additionally, the attacker will also get a high business risk, since a successful IP session hijack attack will allow an unauthorized user to gain access to machines containing sensitive data. See Figure 2.11 for an SBR chart.

Figure 2.10 Successful hijacked session from server A.

Figure 2.11 SBR chart for IP session hijacking.

In a Fibre Channel architecture, in order for two Fibre Channel nodes to communicate with each other, an established session must be made. The session information is managed by the Sequence Count number (Seq_CNT) and the Sequence Identification number (SEQ_ID). The definitions for Sequence Count numbers and Sequence Identification numbers are as follows:

• Sequence Count (SEQ_CNT) -- A number identifies individual frames within a sequence. For each frame transmitted in a sequence, SEQ_CNT is incremented by 1, allowing the frames to be arranged in the correct order.
• Sequence ID (SEQ_ID) -- A static number transmitted with each frame in A sequence that identifies the frame as part of a session. Each frame in the same session has the same Sequence ID.

The session information between two FC nodes is the entity that is in charge of maintaining a session. For example, if 100 frames were delivered from several nodes to another single node, there needs to be a method to understand which frame came from which node and to organize the frames in their correct order. In order to complete this, the Seq_ID and Seq_CNT are used. The Seq_ID and Seq_CNT will tie each frame to a particular session and place it in its correct order.

The issue with session management starts with the lack of Fibre Channel authentication when sending or receiving frames. Similar to the IP and Hunt example earlier, in order to break in and hijack a session, a malicious user could send frames to an authorized node with the correct Seq_ID and Seq_CNT (using the source address (S_ID) as the attacker and not the original session holder), thus, transferring the session's control to the malicious user. Furthermore, since the Seq_ID never changes (which makes it very easy to guess), and the Seq_CNT number increments by the value of one (which makes it very easy to predict), the hijacking process of the session is quite trivial.

Although the attack is very trivial, as demonstrated with IP/Hunt as well as web applications and session identifiers, currently there are no automated tools to perform this type of attack. A Fibre channel analyzer would have to be used to actually perform session hijacking on FC frames, rendering the attack as a high security threat, but a low risk item (see Figure 2.12).

Figure 2.12 SBR chart for Fibre Channel session hijacking.

In order to fully understand the Fibre Channel hijacking attack, the following steps describe the attack process according to Figure 2.13:

1. Node Kusum makes an established connection with node Neeraja.
2. Node Kusum and node Neeraja exchange frames for communication.
3. Using a Fibre Channel traffic analyzer, the malicious user, Lakshman, identifies the static value for the Seq_ID and the Seq_CNT number.
4. Lakshman then injects frames to Neeraja with the Seq_ID, taken from the frames between Kusum and Neeraja, and then increments the Seq_CNT number by one, which will identify the next frame in the session.
5. Neeraja receives the frame(s) from Lakshman, and because the frames have the correct Seq_ID and the correct value for the Seq_CNT, the frames are regarded as the next set of frames in the session.
6. Because the S_ID of the Lakshman's frames are from a different address, the session is then handed to that node wherever the session last left off. 49
7. Lakshman has hijacked the session from Kusum and now has an established connection to Neeraja without any authentication or authorization.
8. Despite the fact that Lakshman has hijacked the session, Neeraja still thinks the established connection is with Kusum.

Figure 2.13 Topology for session hijacking.

The technical details of the attack are obviously more complicated, but generally follow the steps outlined beforehand. The first step would be to enumerate the frame information from the two trusted entities. Using any type of Fibre Channel fabric analyzer or IP sniffer with an IP to Fibre Channel connector, there are a variety of methods to do this attack depending on the type of architecture. For example, if a fabric loop topology had been deployed (FC_AL), the analyzer can see all the traffic in the loop of every node connected to the fabric. In a switched architecture, the analyzer would need to be connected to the core FC switch and also within the same routing segment of the target. Once the targets have been identified and enumerated by the traffic analyzer, the following fields in the header part of the frame are important for the attack: S_ID, D_ID, OX_ID, RX_ID, Seq_ID, and Seq_CNT.

Within Fibre Channel layer 2, you would modify the header information with your traffic analyzer of the frame that you will generate in order to complete the attack. When crafting the frame, the S_ID would change from the original source fabric address to the fabric address of the attacker. The D_ID would remain the same, which is the fabric address of the target (while both entities are technically targets, the entity that is on the receiving end of the session is the real target). The OX_ID and RX_ID values would have to be consistent with the original source (Kusum in our previous example) since the malicious node would need to be able to send and receive the same amount of frames as the original source and consequently send the correct amount of frames to the target specified in the original RX_ID field. The Seq_ID field will also need to remain identical to the original in order to ensure the target node considers the frame(s) as part as the legitimate session. Unlike the Seq_ID, the Seq_CNT field will not remain identical but rather will need to be incremented by one in order for the target to consider that frame as the next legitimate frame in the session. This is probably the trickiest part of the attack; even though the act of incrementing the Seq_CNT by one is a trivial procedure, it is not as easy to determine what Seq_CNT is the last one. For example, using your traffic analyzer, you are able to view the Seq_CNT number of all sessions, but by the time you send your frame(s), the legitimate source may already have sent a frame with that Seq_CNT, thus leaving your frame useless. Although this attack takes some trial and error, a good way to ensure that the attack works correctly is to estimate what the Seq_CNT number will be by the time you have the opportunity to send your frame(s) and to set up multiple instances of malicious frames, each using a Seq_CNT that could possibly be the next legitimate one by the time it reaches the target. After you have successfully done this with your traffic analyzer, you will notice that your node will start receiving the frames from the target with the same Seq_ID and Seq_CNT from the original session, despite the fact that you have not officially logged into the node (NLOGIN).

Use the following table of contents to navigate to chapter excerpts or click here to view SANs: Fibre Channel Security in its entirety.

Securing Storage: A Practical Guide to SAN and NAS Security
  Home: SANs: Fibre Channel Security: Introduction
  1: SAN risks
  2:Fibre Channel risks
  3:Clear-text communication
  4:SAN hacking
  5:Fibre Channel frame weaknesses
  6:Session hijacking: assessment exercise
  7:Fibre Channel address weaknesses
  8: Fibre Channel man-in-the-middle attacks
  9: Fibre Channel address weaknesses: assessment exercise