Fibre Channel frame weaknesses
The following sections discuss the weaknesses with Fibre Channel at the frame level.
A sequence is a set
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 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.
|About the book:|
|Securing Storage: A Practical Guide to SAN and NAS Security is an indispensable resource for every storage and security professional, and for anyone responsible for IT infrastructure, from architects and network designers to administrators. You've invested heavily in securing your applications, operating systems, and network infrastructure. But you may have left one crucial set of systems unprotected: your SAN, NAS, and iSCSI storage systems. Securing Storage reveals why these systems aren't nearly as secure as you think they are, and presents proven best practices for hardening them against more than 25 different attacks. Purchase Securing Storage: A Practical Guide to SAN and NAS Security the book from Addison-Wesley Publishing|
|About the author:|
|Himanshu Dwivedi is a founding partner of iSEC Partners, a digital security services and products organization. Before forming iSEC Partners, Himanshu was the Technical Director for @stake s San Francisco security practice, a leader in application and network security. His professional experience includes application programming, infrastructure security, and secure product design with an emphasis on storage risk assessment.|
This was first published in April 2007