Fibre Channel address weaknesses
A man-in-the-middle (MITM) attack is the act of an untrusted third party intercepting communication between two trusted entities. For example, when you call a friend on the telephone, you dial his or her phone number and wait for an answer. When your friend picks up the phone, you then begin communicating with him or her. In a MITM attack, a malicious user would intercept the connection between you and your friend. Instead of talking to your friend directly, you would actually be communicating through a malicious third party. The malicious third party would then connect you to your friend. Both you and your friend would begin communicating, not knowing that an unauthorized entity has connected you both and is listening to every word of the conversation. It is like a three-way call, but two of the three callers don't know that there is a third person listening.
In the digital world, the untrusted third party plays the role of a router, but unlike an authorized router, the untrusted third party should not have permission to view, modify, or intercept any of the communication between the two trusted entities. Figure 2.17 shows a high-level example of a man-in-the-middle attack.
Figure 2.17 Sample man-in-the-middle attack
Man-in-the-middle attacks were first introduced many years ago in the IP networking world. Unauthenticated OSI layer 2 Address Resolution Protocol (ARP) packets could update ARP tables (tables that match a node's IP address to their machine (MAC) address) in switches and/or operating systems. The purpose of the MITM is to sniff on a switch. A switch will only transmit information to the correct port, not allowing any other ports to see any communication that is not theirs. On the other hand, a hub is a dumber device that allows all ports to see all communication, making it quite easy to sniff a neighbor's traffic. Many switches are layer 2 devices, meaning that they can transmit packets from one port on a switch to another without the need for an IP address, but with a node's machine address (MAC). For example, on a Windows operating system, type ipconfig /all from the command line and then press Enter. Notice the physical address is the machine address of your node, which is actually the MAC address of your Network Interface Card (NIC). The MAC address comes from the manufacturer of the NIC to identify it. If your node wanted to speak to another node via a layer 2 switch, it would use the MAC address and not your IP address. Layer 2 routing is common for performance reasons, allowing switches to transfer packets quickly across the network. Once the packets get to a layer 3 device, such as a router, then a node's IP address can be used.
Since ARP is a layer 2 protocol, it uses a node's MAC address to identify nodes and transfer packets. ARP is similar to Name Servers in the Fibre Channel world, where Name Servers match the WWN of HBAs to the 24-bit fabric address (as well as a few other items, such as zones and LUN access).
Man-in-the-middle attacks -- IP
Before we can begin to understand the idea about a Fibre Channel man-in-the-middle attack, let's first understand the concept using the IP protocol. An entity using IP, such as a switch or an operating system, will send out ARP requests when it is trying to communicate with other entities. For example, if server A wanted to communicate with server B, which has the IP address of 172.16.1.1 and the MAC address of 00-0A-CC-69-89-74, server A would send out an ARP request asking, "Who is 172.16.1.1?" Then the switch or the operating system would respond, replying with its MAC address, which is 00-0A-CC69-89-74. The issue with ARP, which we will also address with Fibre Channel name servers, is that any malicious entity could send out an ARP reply instead of the actual server. For example, if you stepped outside your home and yelled out, "What is the address of the post-office," a malicious neighbor could say, "I am the post-office; please send your mail to me." If you believed this malicious neighbor without asking for proof, then your mail would be compromised. This is how ARP works, without any authentication. A malicious user could send out ARP replies with the incorrect information.
Since there is no authentication with ARP, similar to how there is no authentication with PLOGI in Fibre Channel fabrics, an entity receiving an ARP reply from an attacker would update their routing table with the incorrect information. Furthermore, even if a node did not send out an ARP request, which would request the MAC address of a specific IP address, it doesn't mean it won't receive an ARP reply and update its own routing table. For example, a malicious user could send out ARP replies to the entire network segment, telling each entity that the MAC address of the router, which is 172.16.1.1, is actually the MAC address of the malicious entity. When one node tries to communicate to any other node by going through the default router, it will actually be going to the malicious entity first, since it is using the MAC address of the malicious entity for layer 2 routing.
Assessment exercise: IP man-in-the-middle attack
Let's attempt an IP man-in-the-middle attack using the following steps to better understand the issue:
- Ensure you are on a test network and you have full permission from your network administrator because a man-in-the-middle attack will cause network disruption.
- In our example using Figure 2.17, servers A and B will try to communicate with one another and server C will intercept that traffic.
- Download Cain and Abel to server C from http://www.oxid.it/cain.html.
- Type ipconfig on server A. Notice that is the default route listed as "Gateway Address." In our example, the default gateway is 172.16.1.1. Therefore, when server A tries to communicate to server B, it would go through its router first, which is 172.16.1.1 (see Figure 2.18).
- Still on server A, ping its gateway address by typing ping
, such as ping 172.16.1.1. See Figure 2.19. Now that server A has pinged the router, it will have its MAC address in its ARP table. Type arp –a to see the dynamic ARP table in the system (see Figure 2.19).
- Switch to server C (the malicious user). Use Cain and Abel to enable server C to send out ARP replies to the network segment, telling everyone that the address of 172.16.1.1 is actually associated with the MAC address of 00-00-86-59-C8-94, which is the MAC address of server C, not the MAC address of the router. The MAC address of the router is 00-00-C5-0E-57-63, which we know from the arp –a command that told us the MAC address of the default router (172.16.1.1). Perform the steps in the next exercise on server C.
Figure 2.18 Server A's IP address and gateway.
Figure 2.19 Server A's ARP table.
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
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
|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 @stakes 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.|