Everything You Need To Know About iSCSI If You Have 5 Minutes To Learn

Thomas Ptacek | October 25th, 2005 | Filed Under: Bitching About Protocols, Matasano, New Findings

iSCSI is a network protocol that creates the illusion, on behalf of a network storage system, that network storage clients have directly attached SCSI disks (LUNs). It does this by proxying SCSI commands (CDBs) over the network. Since modern Ethernet is faster than modern SCSI drives, this works pretty well.

Until you get to the security aspects, that is:

1. We broke the market-leading implementation. I believe this is the first real iSCSI security finding (I’m happy to be corrected about this). The break is, as I mentioned earlier, pretty bad: a small piece of exploit code that works on any vulnerable Filer gives you carte blanche to every iSCSI LUN, without a password.

2. iSCSI is a complicated protocol. It combines everything we love about text key-value negotiation with the rich, chocolatey goodness of a binary protocol with multiple length fields that can conflict with each other, one of which is expressed in different units from the rest.

3. Session management in iSCSI is painful. iSCSI runs over TCP. TCP goes through some lengths to ensure that all TCP connections share bandwidth fairly. This struck the iSCSI designers as a bad idea, so they came up with a session management system that allows a single iSCSI client to bundle together multiple TCP connections to claim more bandwidth. For some reason, which may or may not be defensible, this requires multiple session-ID fields and a state machine. Is it possible for an iSCSI attacker to “hijack” a preexisting iSCSI session by playing games with these fields? I can’t say.

4. iSCSI creates new, interesting vectors for attackers to exploit. For example: at some point, an iSCSI-wrapped SCSI CDB becomes an unwrapped SCSI CDB, where it is sent to SCSI firmware. In order words, attackers now have a viable avenue to attack SCSI firmware directly (before, to get to this point, you already had to be at the game-over point of owning the SCSI firmware’s host OS kernel). To put this in perspective: the errata list for Adaptec SCSI firmware was so scary they refused to publish it to OpenBSD.

5. iSCSI creates new, interesting vectors for attackers to exploit. For example: iSCSI asks you to run a filesystem over the network. This is a subtle, awful difference from the way NFS and CIFS work: in those protocols, you work in terms of filenames and the actual underlying filesystem is transparent, encapsulated in the server. In the SAN universe, the underlying filesystem metadata is just another set of storage blocks, flying over the network. Put differently: has anyone audited the NTFS driver code for clientside vulnerabilities?

In theory, iSCSI is supposed to be run on backchannel networks, and over IPSEC. In practice, you can scan networks for TCP:3260 to see how true this is.

Is this alarmist? Sure. That’s why it’s in a blog post. But —- and I know I’m a total geek about this —- I am fascinated by the extent to which things like iSCSI create new, weird security vulnerabilities. To quote one of my business partners: on internal networks, things are getting worse before they get horrible.