Or… Notes on the IPMI Protocol Security Model.
I wrote in Sold Down the River about the curious aspects of channels and authentication and users and all that stuff. Here’s a slimmed down model… and as a bonus a program that iterates through all the channels, users types, and authentication for a host, which is quite a bit of checking.
In any case I’m almost certain that I really don’t understand all the implications of the specification, but here’s a brief summary of how I think it works.
User IDs are numerically based and have names (e.g. “ADMIN”, “root”, etc.) associated with them, with user ID 1/one permanently associated with the NULL user name. Duplicate names are allowed, and while some commands use IDs and others usernames, if there are ambiguities the system will grant or deny access or authorization based on the lowest matching numeric ID username that is matched by the username.
Authentication is done via a password of up to 16 or 20 characters, but may be bypassed or controlled on a per user and channel basis. Most vendors have also added support for LDAP, Active Directory, or Radius network authentication. Users may also be disabled regardless of their authentication settings.
IPMI also allows multiple channels of communication that may be used in different ways over different interfaces or transport protocols, such as the LAN, internal buses, serial lines, VLANs, etc. (version 1.5 only had 9 channels, while version 2.0 has 14.) Each channel is completely independent of the others and may operate in the same or different mediums.
In my testing I only examined the default channels, which are actually a sliver of the overall potential of what IPMI can do, so there may well be additional undetected problems, both similar and unknown, lurking out there.
While LAN and serial channels share many characteristics with the basic channel settings, serial users have additional options and limitations with respect to access, authentication, and session management.
Channels have an access mode associated with them, granting access based on the state of the server. These modes are configurable and include pre-boot only, always available, shared, or disabled.
There are also 5 privilege levels that are associated with commands and users: callback, operator, user, administrator, and an OEM/vendor chosen one. Each user may be granted a maximum privilege level, and all commands have a minimum privilege level that must be met in order to be executed.
There are also a set of commands to manage and limit access of other commands (I count over 160 commands in the specification, plus OEMs and vendors are free to add to the set) in the terribly and misleadingly named firmware firewall, which allows individual commands to be limited on a per channel and per user basis. Commands may also be bridged or routed to other interfaces and media.
IPMI calls the data in its protocol payloads, which in version 2 were greatly expanded; they may be used to transmit both IPMI and non-IPMI commands and data. Payloads may use their own set of port numbers, and transports. Non-IPMI data is perhaps most commonly used for Serial Over LAN (SOL), but vendors may add just about anything here.
Channels also have support for different algorithms for authentication as well as data confidentiality and integrity; this also is set on individual channels and may be set for individual sessions, command or payloads.
In addition the vendors have the capacity to expand the protocol to do whatever they want. Part of the problem with analyzing IPMI security is that no one outside the various vendors knows what its actual capabilities are.
In any case what this all creates is a rather sizeable multidimensional matrix of possibilities. When I first saw all this I initially thought that no one would use all these options, but unfortunately some in fact do, and I’ve seen different settings, configurations, and restrictions for users, privileges, and commands on discrete channels.
This sets up an unfortunate situation where you might think you have disabled some undesirable setting (say, cipher zero to disallow unauthenticated access), but you might not be looking at all the users or channels. Or perhaps you only disabled it for the wrong privilege level on the right channel. Or… pick your confusion.
I know of no software that manages or reports on all this, but to my eyes it vastly too complex to understand any reasonably sized implementation that span multiple servers. Detecting someone who has set up unauthorized or backdoor access by simply using stock IPMI commands would be a sizable challenge, and all you need is one command on one single channel.
I think to understand a BMC’s basic channel security one would need to (at least):
• Enumerate through all the channels to examine all the various privilege levels assigned to commands and payloads
• Look at the cipher support for each channel and traffic
• Enumerate all the privilege constraints for each channel
• Enumerate all users, payloads, and commands on all channels and map their
capabilities as granted and constrained by the various constraints and rights granted by the firmware firewall and other commands
• Possibly do all or most of the above explicitly for both 1.5 and version 2.0 of the specification, since they possibly have different command flows and most definitely interpret the commands differently at times.
Mind you, doing all of this on a BMC might well crash or wedge it into a sullen silence, as they are very easy to DoS into submission even unwittingly (I’ve completely broken BMCs from my testing both Dell and HP servers.)
The python program on git does at least some of this… for only one command, one that they all have to answer (RE: the spec, at least), but it really should be done 160 times or so, one for each command. And I don’t know the usernames a priori, so I basically just ignore them as well. Still… I found the results somewhat interesting.
Sorry, the comment form is closed at this time.