Awesome

The papers n things from http://fish2.com/ipmi

Here's a <a href="rak-the-ripper.pl"> little Perl program</a> 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 <a href="http://fish2.com/ipmi/remote-pw-cracking.html">little</a> 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... <a href="ipmi-get-ciphers.py">ipmi-get-ciphers.py</a>.

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 <a href="http://www.gnu.org/software/freeipmi/">FreeIPMI</a> 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".

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!)

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.

Supermicro has had some issues with password file disclosure from their BMC - for instance, see this and other write-ups:

To use this script simply say:

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>

Take all the weights, add up all the points and you have an IPMI
certainty level.  I've found in ad hoc testing that 15 points or
more are strong indicators that the system is running IPMI.

</p> <p>

Currently I have various thresholds (no, possibly, probably,
yes.) In tests - without having known access to any other servers
than my own - it seems to work reasonably well.  That is,
the things that I think are suspicious and my basic thought
model above does indeed bubble certain servers to the top and
leaves random hosts alone.  There are some real problems with
false positives, tho - many firewalls seem to imply to nmap that
there's something on any port (I've thought of tossing in a rare
port or two (if you listen to something like port 1 & 31313,
for instance, you're probably not *really* listening to it!)

</p> <p>

But this isn't meant to be the last word on the topic.  It should
be fairly simple to get some decent data on IPMI banners, my
guess is that it'd be by far the best way to rapidly scan large
amounts of systems.

Here are four pieces of Perl to implement the above; one scans, one interprets, and the other two are used for weighting. It's a research tool or a proof of concept, not a production scanner, but it does produce some reasonable output.

<strong>REQUIRED: Nmap version 6.</strong>

Usage is pretty simple, if a bit quirky. Should be run as root. Verbose (-v) for lots of output.

In this case I used the terse flag (-t) to cut the output to the bare minimum.

Here's a couple of small python programs that - using FreeIPMI tools - (a) sucks in the basic IPMI/BMC configuration of a server and (b) does a lil' security check on the results.

Because I... well, no good reason, actually. One is in python3 and the other in python2. I guess I'm testing your readiness. The programs are pretty heavily commented, especially ipmifreely.py, so check that for more details on what's going on. Requires simplejson and ConfigParser, maybe some more.

<span style="color: #ff0000;">YOU MUST</span> have <a title="FreeIPMI" href="www.gnu.org/software/freeipmi/" target="_blank">FreeIPMI</a> installed, which, as of this writing, kills off Mac and Windows chances at sucking down a cool JSON file from a server. And you really, really should have a recent version. Don't say I didn't warn you. But life goes on.

The data acquisition is done via a python program (I-check.py) that requires valid credentials to get data. It converts the results to JSON, which in turn may be checked by the audit tool (ipmifreely.py.) There is a sample policy in "IPMI-policy.ini", where I put some values for testing.

Sample use:

You can check out some <a href="/ipmi/bp.pdf">IPMI Security Best Practices</a> for more on what to check what I consider to be good things to do, security-wise.