IPMI stuff from DARPA work
I wrote some software to explore IPMI; here are some of results. I thought I'd do the usual detect, get data, and audit sort of cycle. Each of these turned out to be fairly interesting problem on its own, at least to me.
**BTW/FYI ** - I released a new tool to explore IPMI - https://github.com/zenfish/zipmi - as well as a set of Qemu recipies/images/etc. to run BMCs as virtual systems under Qemu at https://github.com/zenfish/zbmc.
The papers n things from http://fish2.com/ipmi
Here's a little Perl program that tries to guess an account on a remote BMC, extract its hash, and then try to crack its (HMAC hashed) password. I wrote up a little bit on this for the curious. Heavily commented, it may provide some utility.
The IPMI spec says that you can get a remote system's cipher without any authentication, but I'm not aware of any tool that actually does this (they all require auth, although of course you could input the raw hex bytes if you wanted!) So I wrote this little one to do so; it mostly tries to follow the ipmitool output; in doing so I believe I found a bug in that utility (in the final line sometimes systems emit some garbage that appears to be misinterpreted), but who knows, I don't have enough systems to test. Anyway... ipmi-get-ciphers.py.
If nothing else, useful for spotting Cipher0 systems (note - this merely points out ciphers that are supported - it doesn't mean that they're actually turned on), but there are interesting things out in the wild.
Two programs here, one is a simple Python remote prober (starting to hate Perl, let me tell you) and a second that uses utilities from FreeIPMI to grab credentialed configuration data.
A small python program (over 50% inline comments, 2.5k gzip'd) that sends a single packet to a BMC and mulls over the response. What can you do with only a single packet, one might ask? 10+ different security tests for IPMI, for starters. Well, for starters and for enders, it's only a packet :) Requires python, a BMC and an open path to UDP port 623 to work. Usage is simply "ipmi-get-auth.py target".
ipmi-get-auth.py /
A very small description
Taking this to extremes... well, here's a sort of mega version of the above that does it for all channels, all privs, all... well, you get the drift. For the monomaniacal (read comments or the post I wrote about it to see why it does what it does!)
mega_chan.py /
Mega mega mega ... chan chan chan...
And here's a simple program to send a Get Device ID packet (see p250 of the IPMI v 2 spec) to a system. This should, in theory, work without authentication. In a little survey I took about 90% of systems responded to this (although not all with valid info!) You can, at times, get the vendor and other information, such as model numbers and such, but more interestingly is actually getting a unique ID, traditionally a hard thing to get via the net.
get-ipmi-guid.py /
Get Device ID
Supermicro has had some issues with password file disclosure from their BMC - for instance, see this and other write-ups:
a-penetration-testers-guide-to-ipmi
To use this script simply say:
dump_SM.py password_file
Works for me, no warranty implied, guaranteed, etc.
Well, if you can talk to UDP port 623, it's pretty simple to find out if a remote system is running IPMI. Unless you're inside a data center, however, most folks block UDP. And even if they don't... UDP scanning is about as slow as can be imagined. So I'm currently using two basic methods, leveraging the venerable Nmap and ipmiping (from the FreeIPMI Gnu tools.) The easiest thing to do is:
</p> <p>
Since Nmap is far more efficient at scanning large scale networks
than ipmiping this method is only used if Nmap says that a hosts
has UDP 623 open.
</p> <p>
For better or worse this port is often blocked, so much of the
time other methods are more likely to find out obliquely whether
or not IPMI is running.
</p> <p>
Ports are weighted by their indicative ability and whether or not
Nmap finds them open, filtered, or in other states.
</p> <p>
Nmap also can show the banners of services connected to. I use
regular expressions to hunt for targets - for instance the strings
"iLO" and "DRAC" are good indicators that a system might be running
HP's Integrated Lights Out service, or iLO.
</p> <p>
<strong>Note:</strong> Currently I do NOT use the broadcast
ping method (a very quick way to zip through the subnet you're
residing in); I simply don't have any data on the effectiveness
on this; while very fast when it works I didn't feel like it
allowed for the control and reliability of arbitrary scans.
Two out of three of my systems (Dell and HP) responded to an
RMCP ping. None responded to a broadcast ping by idiscover
(ipmiutil discover.) All did, however, respond to my Python
audit tool below.
</p> <p>
Unfortunately (of course!) the spectre of communications and
networks comes into play - nmap gives a bunch of different reasons
as to why a port is open or not (open, closed, filtered, etc.)
Yet another table has a set of weights that gives more points to
an open port than to a "open|filtered" (as Nmap might say) hit.
Interpreting nmap and weighting is a bit on the frustrating side,
but c'est la vie.
</p> <p>