Well, you mispasted the last valid record, but your explanation suggests
you originally parsed it correctly (c00c024381). The trailing zeroes are in
bad form and if not for the clear statement that there can only be one auth
algorithm it could be understood why ipmitool might get confused and be
helpless (though the more accurate output for such a mistak would be a list
of valid auth algorithms rather than just the last seen). With that
wording this invalid output can be gracefully accomodated, but I think it's
still a lot of invalid bytes in the final cipher suite record if you
consider the spec.
I honestly wouldn't put too much stock in the results of that from an audit
perspective. I would instead try to actually go through the motions of
authentication of interest. After all, a BMC could do cipher suite 0 even
if not advertised and conversely not actually do cipher suite 0 even if
advertised. Auth of '0' is certainly the most interesting. The other
gotcha I could see is that integrity of 0 being allowed means Kg may not be
affording a level of protection the operator might have intuitively assumed
if they think Kg can significantly increase security. Of course, given
that Kg acts in most ways like Kuid I don't think Kg really adds much
anyway. I have had this same advise for some scanners that similarly
wanted to mark pass/fail based on what amounts to advisory data early in
the handshake.
From: dan farmer <zenf...@gmail.com>
To: "ipmitool-devel@lists.sourceforge.net"
<ipmitool-devel@lists.sourceforge.net>
Date: 05/12/2014 05:12 PM
Subject: [Ipmitool-devel] unauthenticated Get Channel Cipher Suites
command & possible bug…?
First of all, ipmitool doesn't seem to have an option to do a get channel
cipher suite command w/o authentication, so I wrote a script to do so;
those interested can get it here (I'm not a C programmer or I would have
patched ipmitool):
https://github.com/zenfish/ipmi/blob/master/ipmi-get-ciphers.py
I'm not sure if any of the various ipmi tools have an option to do this;
I've found it useful to use when looking at systems (those running cipher 0
are very, very clear.)
I've a protocol question, however, because my understanding of this
particular part is especially shaky (and thank god for the great comments
in ipmitool; I rarely look at the source, but I was desperate this time :))
Those familiar with the command might know that you have to send it in
pieces and continue until the target tells you to stop. Sample output on
some hosts, however, might look like this:
chunk [1]: c000004080c001014080c002014180c0
chunk [2]: 03014181c006024080c007024280c008
chunk [3]: 024281c00b024380c00c024381000000
chunk [4]: 00000000000000000000000000000000
chunk [5]: 00000000000000000000000000000000
chunk [6]: <= end of data
all data received (160 bytes):
c000004080c001014080c002014180c003014181c006024080c007024280c008024281c00b024380c00c0243810000000000000000000000000000000000000000000000000000000000000000000000
I've no idea *why* they send the extra zeros, but the ways of BMCs are
mysterious. Ipmitool reports this as:
ID IANA Auth Alg Integrity Alg Confidentiality Alg
0 N/A none none none
1 N/A hmac_sha1 none none
2 N/A hmac_sha1 hmac_sha1_96 none
3 N/A hmac_sha1 hmac_sha1_96 aes_cbc_128
6 N/A hmac_md5 none none
7 N/A hmac_md5 hmac_md5_128 none
8 N/A hmac_md5 hmac_md5_128 aes_cbc_128
11 N/A hmac_md5 md5_128 none
12 N/A none md5_128 aes_cbc_128
I believe that last line is wrong, but I could be way wrong myself; the way
I see it is that the last set of valid hex chars are c024381, which I
believe should output:
12 N/A hmac-md5 md5-128 aes-cbc-128
I think ipmitool is reading the zeros and says "hey, here's another auth
value!", and it overwrites the previous value. However bizarre the spec's
language on this area on one point it's clear, there may be only one
authentication algorithm number (section 22.15.1.) But… what do others
think? Of course who knows how vendors actually implement the damn thing
anyway. Many seem to not support it unauthenticated, although I the spec
clearly states its mandatory, and that "works at any privilege level, can
be sent prior to a session being established."
I've seen this multiple times, but it's doesn't seem super common, and I
don't know which vendor(s) might be doing this. Anyway, the only way I can
illustrate this with real data to show the difference between my tool above
and ipmitool is to choose a host that has authentication turned off
(because I broke all my BMCs, lol); I'll refrain from sending out a
vulnerable IP to the world, but if someone wants me to show the output of
the two with a valid IP address that may be verified, I'll do so in private
email.
Thanks for any clarifications, corrections, etc.
dan
_ /|
\'o.O'
=(___)=
U
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform
available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
