[Ipmitool-devel] unauthenticated Get Channel Cipher Suites command & possible bug…?

[dan farmer]

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

[Jarrod B Johnson]

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 <***@gmail.com>
To: "ipmitool-***@lists.sourceforge.net"
<ipmitool-***@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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

[dan farmer]

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.

RE: final sentence, very true. However, from an audit perspective there are some substantial difference between using Get Channel Cipher Suite and other methods (such as simply trying to execute an IPMI command on a remote system.) Perhaps the most important difference is that one method remotely executes commands directly on a system vs. simply using publicly advertised network services, which might matter if you're examining systems that you don't own or have authorization to scan. Also, given the fragility of BMCs I know which one I'd recommend when auditing critical infrastructure that has up/down time concerns.

Differences in accuracy are interesting has well; of course actually authenticating requires a valid account name (even if null ;)) While you can know with near 100% accuracy when you succeed, a failure may or may not mean that C0 is active. Of course GCCS isn't always right either, but I would hope (at least!) that for classes of systems they'd produce similar results.

Of course you don't have to choose one over the other. Using GCCS as a filter to drive authentication attempts seems reasonable to me.

dan

[Jarrod B Johnson]

Well, there are commands that are innocuous enough (e.g. stopping after
RAKP4, or proceeding onto set session privelege level and then stopping).
But point about awareness of username being required is something that
slipped my mind as being a harder thing...



From: dan farmer <***@gmail.com>
To: Jarrod B Johnson/Raleigh/***@IBMUS
Cc: "ipmitool-***@lists.sourceforge.net"
<ipmitool-***@lists.sourceforge.net>
Date: 05/13/2014 10:36 AM
Subject: Re: [Ipmitool-devel] unauthenticated Get Channel Cipher Suites
command & possible bug
?




On May 13, 2014, at 7:09 AM, Jarrod B Johnson <***@us.ibm.com> wrote:


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.


RE: final sentence, very true. However, from an audit perspective there
are some substantial difference between using Get Channel Cipher Suite and
other methods (such as simply trying to execute an IPMI command on a remote
system.) Perhaps the most important difference is that one method remotely
executes commands directly on a system vs. simply using publicly advertised
network services, which might matter if you're examining systems that you
don't own or have authorization to scan. Also, given the fragility of BMCs
I know which one I'd recommend when auditing critical infrastructure that
has up/down time concerns.

Differences in accuracy are interesting has well; of course actually
authenticating requires a valid account name (even if null ;)) While you
can know with near 100% accuracy when you succeed, a failure may or may not
mean that C0 is active. Of course GCCS isn't always right either, but I
would hope (at least!) that for classes of systems they'd produce similar
results.

Of course you don't have to choose one over the other. Using GCCS as a
filter to drive authentication attempts seems reasonable to me.

dan