iSCSI Security Considerations in the Cloud

July 25, 2014 by

Dejan Lukan

Introduction to SCSI

The SCSI (Small Computer System Interface) defines a way to exchange data between a computer and its peripheral devices, like a hard drive, a tape drive, a scanner, etc [2]. The primary purpose of SCSI is to support multiple devices to be connected together over a fast bus, which can transfer 320 MB per second; it's also often used to control the RAID disks to read and write data at the same time. There are a number of SCSI variations as presented below [3], but basic specification identifies SCSI-1, SCSI-2 and SCSI-3, which have different bus width and bus speed directly affecting them throughout, which is also presented on the picture below.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

There are several variations of SCSI interfaces available, some of which are SPI (Parallel SCSI), SAS (Serial Attached SCSI), iSCSI (Internet Small Computer System Interface), etc. In this article we'll take a look at the iSCSI, which uses Ethernet cables as a medium to send/receive data.

Introduction to DAS/NAS/SAN

When iSCSI is used, the SCSI commands as well as data are sent over IP networks, which enables the SCSI to be used across networks. The iSCSI is commonly used over Gigabit Ethernet to provide a network storage to the iSCSI clients in order to centralize the storage. Traditionally, a DAS (Direct Attached Storage) was used to provide a storage to each physical machine, which is limited to each machine and doesn't enable sharing of storage devices with multiple machines across the network. To eliminate the disadvantages of DAS, solutions called NAS (Network Attached Storage) or SAN (Storage Area Networks) were created where each physical machine – whether a client computer or a dedicated server – was able to use shared centrally-managed storage devices over the internal network. With the adoption of virtualization, a need for a central data storage system became even greater. This is why centrally managed network storage systems have become a necessity in today's networks. With the widespread use of virtualization in most areas of computer technology, a common network today consists of physical machines running hypervisors like ESX/Xen/VirtualPC/etc providing CPU/RAM/Graphics, and NAS/SAN systems providing storage to virtual machines. Remember that each machine must still have some kind of DAS storage attached for the actual operating system: either a hypervisor or any other operating system, which is needed for the machine to boot up successfully. There are many benefits of using NAS/SAN systems, some of which are the following:

• Limit Unnecessary Storage Space: in DAS storage, each machine had to have its own physical hard drive connected to it, which resulted in large amounts of unneeded space that was just sitting there. The problem was that a hard drive of specific size had to be connected to the computer, which can only be used by that computer. In most cases, the applications running on that computer didn't actually need so much space, which resulted in wasted space that could be used by other applications in the network. By using NAS/SAN, a specific amount of space can be given to the computer, which is not regulated by the hard drive sizes.
• Easy Management of Storage Space: in DAS architecture it was hard to reassign the hard drive to the other system in case the system was being shut down. An administrator had to locate the physical server, unplug the hard drive from the machine, and plug it into the machines that needed additional space. In NAS/SAN architecture, this can easily be done from a web interface without requiring physically disconnecting and reconnecting the hard drives.
• File/Block Level Access: an advantage of DAS and SAN architectures over NAS is that they make the storage available to the system at block-level rather than file-level; for DAS this is true only for the local computer, but for SAN it's true for every device in the internal network. NAS supports sharing the storage at file-level (by using NFS/CIFS/SMB), which means the clients can manage the files, but not the filesystem used to store the files on the filesystem. When block-level access is available, the filesystem itself can also be managed by the clients, as well as managing partitions, data formatting, file management, etc. In DAS architecture, the block-level access is automatically supported, while in SAN architecture the block-level access can be supported if appropriate protocols are used: Fibre Channel, iSCSI, AoE (ATA over Ethernet), HyperSCSI, etc [1].
• Transfer Speed: in DAS architecture, the data is transferred at highest speed over the local bus, while in SAN/NAS architecture the data is transferred over a slower network cable. This is why we must always use Gigabit Ethernet interfaces, which must be supported by the clients, the switches, as well as the SAN/NAS storage itself: this minimizes the bottleneck of transferring data over local area network (LAN).
• Storage Replication: by using a central data center, using a storage replication like RAID-1 becomes really easy, since we only have to set it up once on each storage system. When using DAS architecture in the entire local network, we would have to buy an additional hard drive and attach and configure it separately for each machine for which data needed to be backed up.

Introduction to iSCSI

So far we've seen that iSCSI interface is used to provide block-level access to the storage over Ethernet networks, which is a widely deployed solution nowadays. On the picture below we can see a typical scenario of how iSCSI is used (picture was taken from [5]), where we can see three scenarios. In the first scenario, we can see servers with iSCSI initiators connected to iSCSI targets over LAN. In the second scenario, the iSCSI initiators are set up over the Internet, where a firewall must enable transmission of iSCSI packets used to initialize the connection as well as transfer data. The third scenario presents iSCSI initiators, which are connected directly to the Gigabit switch in order to achieve maximum performance/throughput.

The picture above presents many components that form a iSCSI architecture, which are important to understand and are also presented below:

• iSCSI Initiator: a client endpoint that initiates the iSCSI connection with the iSCSI target by sending SCSI commands over the established session.
• iSCSI Target: a server endpoint waiting for iSCSI initiators to establish a session and transfer data blocks. The targer must have at least one LUs (Logical Unit) available, which the iSCSI initiator can use (often the LUN term is used instead, but it actually means Logical Unit Number). Usually the iSCSI targer is listening on port 3260 for incoming iSCSI commands from iSCSI initiators.

iSCSI uses a naming convention to differentiate between iSCSI endpoints – this works similarly to how IP is used to differentiate between different computers. The naming convention is called iSCSI Qualified Name (IQN) and is divided between four fields. The first field is the literal 'iqn' string, followed by the date in yyyy-mm format, which is the second field. The third field is a reverse domain name, while the last field is an optional storage target name. An example of IQN name is the following: "iqn.1992-01.com.example:storage.tape1.sys1.xyz", which is broken down into four fields as such:

• Field 1: 'iqn'
• Field 2: '1992-01'
• Field 3: 'com.example'
• Field 4: 'storage.tape1.sys1.xyz'

We must also talk about iSNS servers (iSCSI Simple Name Services), which allows automated discovery, management and configuration of iSCSI devices [6] and usually listens on TCP port 3205. The iSNS provides different services, but the most notable of them is allowing all iSCSI enabled devices to register and query the iSNS database [1]. Each connected party can request information about any other connected party, which can be used to get a list of connected clients in the network.

iSCSI Security

When talking about iSCSI security, we have to provide the basis of securing different parts of the iSCSI internal workings.

• Authentication: before an iSCSI initiator can use the iSCSI target, it must first authenticate. An iSCSI initiator can use the following protocols to authenticate to iSCSI target:
  • None: when no authentication is configured, any iSCSI initiator can connect to the iSCSI target and get access to the data.
  • CHAP (Challenge-Handshake Authentication Protocol): the iSCSI endpoints must exchange the correct hash generated from the CHAP ID, a challenge and a secret password. If the hash matches, the initial link is established, otherwise the access is denied. CHAP is vulnerable to various attacks described later in this article.
• Network Isolation: iSCSI targets should be available only to internal trustworthy machines, which can be easily achieved with proper network isolation. We can physically separate iSCSI targets and iSCSI initiators from the rest of the network, which provides best security. Alternatively, we can use VLANs to logically separate the network, so unauthorized access to iSCSI targets is prohibited.
• Authorization: when an iSCSI initiator wants to get access to an iSCSI target, it must first authenticate by using CHAP. Once the iSCSI initiator is authenticated, its IQN name is used to authorize in order to get access to a target LUN; the iSCSI initiator must not be allowed to get access to other LUNs, since otherwise it would allow the client to access data it's not allowed to see. From that we can gather that only IQN names are used to authorize the iSCSI initiator to give it access to a certain LUN. Therefore, if an attacker is able to get his hands on the IQN names, he can spoof it in order to get his hands on the data he otherwise wouldn't be able to access; note that the attacker can easily sniff the IQN names from the network, since the iSCSI traffic is exchanged between the endpoints in cleartext.
• Data Encryption: the data exchanged between the iSCSI initiator and iSCSI target is not encrypted, which is why an attacker who is able to sniff the data of the wire will also be able to reconstruct the data, or more precisely, the files and directories transferred between the two parties. Additionally, an attacker might also be able to inject his own data into the traffic, thus creating/modifying/deleting arbitrary files on the iSCSI target. To mitigate the risk, the IPsec ought to be used to properly encrypt the communication between the iSCSI endpoints.

CHAP Security

CHAP is used to authenticate the endpoint, which is often used together with a PPP protocol by modems to authenticate to our ISP. When a clients needs to authenticate to the server, the following happens [7]:

1. The iSCSI initiator connects to the iSCSI target, which responds by sending it the CHAP ID and a challenge message.
2. The iSCSI initiator responds by sending the iSCSI target the calculated hash. Usually a MD5 hash function is used, which is calculated by using: MD5(ID + password + challenge), where the ID and challenge were sent back by the iSCSI targer and password is shared among the iSCSI target and iSCSI initiator, but never sent over the wire.
3. The iSCSI target checks whether the hash matches the expected value, in which case the iSCSI initiator is authenticated; otherwise the connection is terminated.

We've seen that when the iSCSI initiator wants to talk to the iSCSI target, the client must first authorize with the target. Since the authentication is optional, it's often not turned on and enables every iSCSI initiator to successfully connect with the iSCSI target. If the authentication is required, CHAP is used, which is vulnerable to several attacks.

• Sniffing the Traffic: since the iSCSI traffic is sent in clear-text, an attacker can be able to sniff the packets of the wire by executing a MITM attack.
• Offline Password Bruteforce Attack: an attacker that is able to sniff the iSCSI communication in a network will eventually also gather the CHAP challenge handshake. Since the CHAP ID, the CHAP challenge, and the resulting MD5 hash will be known, the attacker can brute-force the password that was used to calculate the resulting MD5 hash.
• Message Reflection Attack [8]: a reflection attack can be used when both endpoints use the same protocol to authenticate the other side. The attack works by an iSCSI initiator (controlled by an attacker) establishing the first connection to an iSCSI target, which responds by sending it an ID and a challenge message; at this point the attacker can't simply respond with an MD5 hash, since he doesn't know the secret password. This is why the iSCSI initiator (the attacker) opens a separate connection to the iSCSI target and sends it the received ID and challenge. The iSCSI target will respond with the correct MD5 hash, which an attacker can then use to authenticate to the iSCSI target in the first connection. If the MD5 hash is accepted by the iSCSI target, the attack will be successful.

Conclusion

In this article we've seen that it's imperative to properly secure the iSCSI traffic, since it plays a major role in our network. If an attacker were to get access to the iSCSI data storage, it would be the same as if he compromised an entire range of virtual machines residing on that storage, which is why it's imperative that we properly secure the network.

References:

[1] iSCSI, https://en.wikipedia.org/wiki/ISCSI.

[2] SCSI, https://en.wikipedia.org/wiki/SCSI.

[3] SCSI, http://computer.howstuffworks.com/scsi1.htm.

[4] iSCSI Security (Insecure SCSI), Himanshu Dwivedi, iSEC, https://www.blackhat.com/presentations/bh-usa-05/bh-us-05-Dwivedi-update.pdf.

[5] Introduction to iSCSI Technology, http://www.addonics.com/technologies/iscsi_tutorial.php.

[6] Internet Storage Name Service, https://en.wikipedia.org/wiki/Internet_Storage_Name_Service.

[7] Cheating CHAP, http://www.rootsecure.net/content/downloads/pdf/cheating_chap.pdf.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

[8] Reflection attack, https://en.wikipedia.org/wiki/Reflection_attack.