Threat Level: green Handler on Duty: Remco Verhoef

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2013-08-21 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Fibre Channel Reconnaissance - Reloaded

Published: 2013-08-21
Last Updated: 2013-08-21 18:43:41 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

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

0 comment(s)

Psst. Your Browser Knows All Your Secrets.

Published: 2013-08-21
Last Updated: 2013-08-21 17:08:34 UTC
by Alex Stanford (Version: 1)
8 comment(s)

 

This is a "guest diary" submitted by Sally Vandeven. We will gladly forward any responses or please use our comment/forum section to comment publically. Sally is currently enrolled in the SANS Masters Program.

I got to wondering one day how difficult it would be to find the crypto keys used by my browser and a web server for TLS sessions.  I figured it would involve a memory dump, volatility, trial and error and maybe a little bit of luck.  So I started looking around and like so many things in life….all you have to do is ask.  Really.  Just ask your browser to give you the secrets and it will!  As icing on the cake, Wireshark will read in those secrets and decrypt the data for you.   Here’s a quick rundown of the steps:

Set up an environment variable called SSLKEYLOGFILE that points to a writable flat text file.  Both Firefox and Chrome (relatively current versions) will look for the variable when they start up.  If it exists, the browser will write the values used to generate TLS session keys out to that file.  

The file contents looks like this:

SSL Key File

 

64 byte Client Random Values
96 byte Master Secret
16 byte encrypted pre-master secret
96 bytes pre-master secret

The Client_Random entry is for Diffie-Hellman negotiated sessions and the RSA entry is for sessions using RSA or DSA key exchange.  If you have the captured TLS encrypted network traffic, these provide the missing pieces needed for decryption.  Wireshark can take care of that for you.  Again, all you have to do is ask.

Wireshark SSL Session

 

This is an encrypted TLS session, before giving Wireshark the secrets.

Point Wireshark at your file $SSLKEYLOGFILE.  Select Edit -> Preferences -> Protocols -> SSL  and then OK.

Wireshark SSL Configuration

 

To see the decrypted data, use the display filter “ssl && http”.  To look at a particular TCP session, right click on any of the entries and choose to “Follow  SSL Stream”.  This really means “Follow Decrypted SSL Stream”.   Notice the new tab at the bottom labeled “Decrypted SSL data”.  Incidentally, if you “Follow TCP Stream” you get the encrypted TCP stream.

wireshark decrypted session

 

Wireshark’s awesome decryption feature.

Below is a sample of a decrypted SSL Stream.  It contains a login attempt with username and password, some cookies and other goodies that web servers and browsers commonly exchange.  

Reassembled SSL Sesion

 

Remember: if you have a file with keys in it and the captured data on your system then anyone that can get their hands on these can decrypt too.  Hey, if you are a pen-tester you might try setting be on the lookout for an $SSLKEYLOG variable on your targets.  Interesting.

Give it a try but, as always, get written permission from yourself before you begin. Thanks for reading.

 

This exploration turned into a full blown paper that you can find here:
http://www.sans.org/reading-room/whitepapers/authentication/ssl-tls-whats-hood-34297

 

8 comment(s)
Diary Archives