Fibre Channel frame weaknesses
The following sections discuss the weaknesses with Fibre Channel at the frame level.
Sequence weaknesses
A sequence is a set of frames transmitted unidirectionally from one entity to another in order to maintain a session between two nodes. A frame uses a (Seq_ID)
and a Sequence Count (Seq_CNT) in each frame to identify, control, and maintain the
session. Each frame includes the Sequence ID (Seq_ID) that identifies the unique session
that the frame belongs to. For example, if a node were communicating with several different entities, each session would have a unique Seq_ID to identify which frame belongs to which session. In addition to the Sequence ID, the Sequence Count is used also. The Sequence Count is used to ensure frames are placed in the right order by the entities. Each Seq_CNT is incremented by 1 for each subsequent data frame.
The Sequence ID and Sequence Count have similar responsibilities in a Fibre Channel frame as the Initial Sequence Number (ISN) in an IP packet. The ISN in an IP packet is also responsible for maintaining a session between two nodes on an IP network.
In order for a session to be maintained between two nodes, all session information
must be maintained. The security weakness with IP networks is the predictable (guessable) ISN. An ISN is the core component to allow packets to become a part of an established session. If the ISN is predictable, it would potentially allow unauthorized packets to join or hijack the session. A third-party entity could inject packets with the next relevant ISN and take control of the established session. For example, for simplicity's sake, let's say two of the first three packets in a session have the ISN of 123 for packet number one and 456 for packet number two. An attacker could probably predict that the third packet should have an ISN of 789 to be part of the existing session. If the attacker sends their packet to the target first and uses the ISN of 789, the session will then be handed over to the attacker and not the legitimate node. This means that if an entity was able to guess the next ISN in the sequence and the entity was able to inject packets in an established session, the entity would own the session. See Figure 2.5 for more details.
Figure 2.5 ISN session hijacking attack
As shown in Figure 2.5, a weak or predictable ISN can leave an established and trusted session vulnerable to a session hijacking attack. A predictable value to allow/deny entities into a trusted session should not be used. ISN values must be unpredictable and unique, not unpredictable or unique. This premise has also plagued HTTP (web) applications. Session identifiers in cookies used in HTTP applications, known as the Session ID, are being used to maintain sessions in the stateless HTTP protocols. While applications distribute cookies with unique Session IDs, the Session IDs are not necessarily unpredictable. This allowed unauthorized users to guess or predict the Session ID and log into applications using another user's existing sessions. For example, if a legitimate user and a malicious user logged on to their favorite webmail service, they would receive a cookie from the webmail site that contains a Session ID. Both users would present their cookie to the site each time they want to check email. If the site granted a Session ID of 100 to the legitimate user and 101 to the malicious user, then an attacker could guess/predict that the Session IDs is a three-character digit being incremented by one for any new session. The attacker could access the site under the legitimate user's profile by changing their Session ID in their cookie to 100 and send it to the site. Once the site receives the cookie from the malicious user that contains the Session ID of 100, it would recognize the attacker as the legitimate user because the site recognizes the user based on the Session ID in a user's cookie. This would allow the attacker to log to the legitimate user's session and give them access to profile pages, credit card pages, and account information.
As stated in the Preface, attacks don't change, but they do get modified. Similar to the session hijacking weaknesses in IP ISN packets, which was introduced over 15 years ago, and Session IDs in HTTP cookies, the Sequence ID and Sequence Counts in Fibre Channel frames are unique values, but they are predictable. The Sequence Count value is incremented by one, a very predictable pattern. Furthermore, the Sequence ID is a
unique number, but is also a static number that does not change within the session.
Therefore, of the two entities that maintain the session in a Fibre Channel frame, one is a
static value and the other is a value that increments by one, both of which can allow an
unauthorized entity to predict or guess values and inject their own frames to hijack a
session. For example, let's say two nodes are communicating on a Fibre Channel network—they have a Sequence ID of 12, and the first frame has a Sequence Count of
1117171342 and the second frame has a Sequence Count of 1117171343. An unauthorized node could inject frames to the target node with the Sequence ID of 12, since the frame is in clear-text and the value does not change, and predict the next Sequence Count of 1117171344 in order to hijack the session. Notice that although 1117171342 is a long and unique number, the first four digits is the date (November 17th or 1117) and the last six digits is time (5:13 and 42 seconds or 17:13:42). By doing some simple pattern matching and predictions, it is easy to figure out that the next few frames will have the Sequence Count of 1117171344, 1117171345, and 1117171346.
What does this mean? Well, this does not mean that you can go download Hunt,
Ettercap, or WebProxy and begin to perform session hijack attacks on Fibre Channel
SANs (Hunt, Ettercap, and WebProxy are IP/Application tools to hijack sessions in IP
networks or web applications). Although the weaknesses are there in a Fibre Channel
frame, the threat and exposure is relatively low. A Fibre Channel analyzer is required to
modify frames and inject them into established session. With speeds up to 2gb/sec, this is
not an easy task. Nonetheless, the weakness of session management with the Seq_ID and
Seq_CNT fields in a Fibre Channel frame do exist, which tells us that security may have
not been a significant factor when developing session management for Fibre Channel or
Fibre Channel-enabled products.
Session hijacking
Session hijacking is the act of an untrusted third party intercepting and controlling
(hijacking) a valid session between two trusted entities. Telnet is a good example of a
trusted session between two entities that can be hijacked by an anonymous third party
on the segment if weak ISNs are being used for the TCP packets. Figure 2.6 shows a
high-level example of session hijacking.
Figure 2.6 Sample session hijacking between two trusted entities.
Initial Session
Session hijacking was first introduced many years ago in the IP networking world
for weak and predictable Initial Sequence Numbers in TCP headers for IP packets.
The attack became quite easy to execute with IP tools such as Hunt (http://lin.fsid.
cvut.cz/~kra/#HUNT) and Ettercap (http://ettercap.sourceforge.net/). Session hijacking
resurfaced in the application world when weak and predictable session IDs became
apparent in application cookies to maintain state in web (HTTP) communication.
Similar to our discussion in Chapter 1 on how several attacks don't change, but get modified, the idea of session hijacking can be applied to Fibre Channel frames also.
Use the following table of contents to navigate to chapter excerpts or click here to view SANs: Fibre Channel
Security in its entirety.