At SANSFIRE this year I had a fun presentation on Fibre Channel (FC) recon and attack (which I promise to post as soon as I get a chance to update it!). In that talk we went through various methods of doing discovery and mapping of the fiber channel network, as well as some nifty attacks.



Today I'll add to that - we'll use WMI (Windows Management Instrumentation) and Powershell to enumerate the Fibre Channel ports. Using this method, you can map a large part of your FC network from the ethernet side using Windows.

Microsoft has built Fiber Channel support into Powershell for quite some time now (I've used it on Server 2003) - you can review what's available by simply listing the file hbaapi.mof (found in %windir\system32\wbem and %windir%\system32\wbem) - it makes for an interesting read. Or you can browse to Microsoft's Dev Center page on HBA WMI Classes, (which as of today is located at http://msdn.microsoft.com/en-us/library/windows/hardware/ff557239%28v=vs.85%29.aspx ). Today we'll be playing with the MSFC_FCAdapterHBAAttributes class.



You can list the attributes of all the HBA's (Host Bus Adapters) in your system with the Powershell command:



Get-WmiObject -class MSFC_FCAdapterHBAAttributes –computername localhost -namespace "root\WMI" | ForEach-Object { $_ }

This dumps the entire class to a form that's semi-readable by your average carbon-based IT unit, giving you output similar to:

PS C:\> Get-WmiObject -class MSFC_FCAdapterHBAAttributes -computername localhost -namespace "root\WMI" | ForEach-Object { $_ }





__GENUS : 2

__CLASS : MSFC_FCAdapterHBAAttributes

__SUPERCLASS :

__DYNASTY : MSFC_FCAdapterHBAAttributes

__RELPATH : MSFC_FCAdapterHBAAttributes.InstanceName="PCI\\VEN_1077&DEV_

5432&SUBSYS_013F1077&REV_02\\4&320db83&0&0020_0"

__PROPERTY_COUNT : 18

__DERIVATION : {}

__SERVER : WIN-QR5PCQK3K3S

__NAMESPACE : root\WMI

__PATH : \\WIN-QR5PCQK3K3S\root\WMI:MSFC_FCAdapterHBAAttributes.Insta

nceName="PCI\\VEN_1077&DEV_5432&SUBSYS_013F1077&REV_02\\4&32

0db83&0&0020_0"

Active : True

DriverName : ql2300.sys

DriverVersion : 9.1.10.28

FirmwareVersion : 5.07.02

HardwareVersion :

HBAStatus : 0

InstanceName : PCI\VEN_1077&DEV_5432&SUBSYS_013F1077&REV_02\4&320db83&0&002

0_0

Manufacturer : QLogic Corporation

MfgDomain : com.qlogic

Model : QLE220

ModelDescription : QLogic QLE220 Fibre Channel Adapter

NodeSymbolicName : QLE220 FW:v5.07.02 DVR:v9.1.10.28

NodeWWN : {32, 0, 0, 27...}

NumberOfPorts : 1

OptionROMVersion : 1.02

SerialNumber : MXK72641JV

UniqueAdapterId : 0

VendorSpecificID : 1412567159



We're mainly interested in:

What is the card? (major vendor)

What is the full card description?

Is it active in the FC network?

And, most importantly, what is it's WWN? - note that in the example above, the WWN is mangled to the point it's not really readable.

We can modify our one-liner command a bit to just give us this information:

$nodewwns = Get-WmiObject -class MSFC_FCAdapterHBAAttributes -Namespace "root\wmi" -ComputerName "localhost"

Foreach ($node in $nodewwns) {

$NodeWWN = (($node.NodeWWN) | ForEach-Object {"{0:X2}" -f $_}) -join ":"

$node.Model

$node.ModelDescription

$node.Active

$nodeWWN

}

Which for a QLogic node will output something similar to:

QLE220

QLogic QLE220 Fibre Channel Adapter

True

20:00:00:1B:32:00:F6:78

Or on a system with an Emulex card, you might see something like:

LP9002

Emulex LightPulse LP9002 2 Gigabit PCI Fibre Channel Adapter

True

20:00:00:00:C9:86:DE:61

Note that in all cases I'm calling out the Computer Name, which is either a resolvable hostname or an IP address. Using this approach it gets very simple to extend our little script to scan an entire subnet, a range of IP's or a Windows Domain (you can get the list of servers in a domain with the command NETDOM QUERY /D:MyDomainName SERVER )



Where would you use this approach, aside from a traditional penetration test that's targeting the storage network? I recently used scripts like these in a connectivity audit, listing all WWPNs (World Wide Port Names) in a domain. We then listed all the WWNN's on each Fibre Channel Switch, and matched them all up. The business need behind this exersize was to verify that all Fiber Channel ports were connected, and that each server had it's redundant ports connected to actual redundant switches - we were trying to catch disconnected cables, or servers that had redundant ports plugged into the same switch.



Microsoft has a nice paper on carrying this approach to the next step by enumerating the WWPN's at http://msdn.microsoft.com/en-us/library/windows/hardware/gg463522.aspx.



This approach is especially attractive if a datacenter has a mix of Emulex, Qlogic, Brocade and other HBAs, each which have their own CLI and GUI tools. Using WMI will get you the basic information that you need in short order, without writing multiple different data collection utilities and figuring out from the driver list which one to call each time.

Depending on what you are auditing for, you might also want to look closer at firmware versions - maintaining firmware on Fibre Channel HBAs is an important "thing" - keep in mind that HBAs should be treated as embedded devices, many are manageable remotely by web apps that run on the card, and all are remotely managable using vendor CLI tools and/or APIs. I think there are enough security "trigger words" in that last sentance - the phrase "what could possibly go wrong with that?" comes to mind ....

===============

Rob VandenBrink

Metafore