February 5, 2013 at 04:21Haunted House: IIPM Vulnerabilities
Recently, browsing through one of my favorite English-language blogs, I came across an article by Dan Farmer (the very one who created one of the first vulnerability scanners in history), the title of which can be (albeit somewhat freely) translated as “IIUP: the train goes to HELL” .
Having examined the Habr that is dear to my heart, I did not find any mention of this laudable article and decided to correct this omission, all the more so since it was completely in my interests (there was no need to investigate as such - Dan investigated everything before us, but scandal-intrigues are quite traceable).
So, first things first. Who is IIIUP and why did he send some train to hell?
Those from Khabrovsk residents who work in large and beautiful data centers know what it is (and probably use it to the full), for those who are unlucky to work in a large and beautiful data center, I note that IIUP (in the IPMI people, in other words, Intellectual Platform Management Interface) is an intelligent platform management interface. It is present on all server motherboards, and is something like a built-in KVM "on steroids."
This laudable little thing allows the administrator to access the server regardless of the vagaries of the BIOS, OS, and even the CPU - which means that the component responsible for the operation of the IIC (BMC, Baseboard Management Controller, Controller Board) continues to work, even when the server itself is turned off (but not de-energized) or freezes.
Actually, the IIPM is generally extremely resistant to various "troubles", and can transmit data (and provide access) in very diverse "catastrophic" situations. Of course, in addition to the management itself, BMC also monitors, journals,erotic massage, coffee and many other good and laudable things.
Delicious? Not really ...
For example, a reasonable question arises - how does this wonderful aggregate solve authentication issues?
And here the problems begin.
Authentication takes place using the username / password pair, the password is not longer than 20 characters, while some BMCs are stupidly stored in their native form (Dell, however, hashes ... but without salt. Twenty-first century, however ...).
Many of them support RADIUS, etc. (not always adequate), but almost always there is the possibility of switching to “emergency” basic authentication (which is actually quite logical - the IIPM should continue to work in emergency situations in which the authentication server may itself be unavailable).
But the most interesting thing is that if someone is logged on to a specific server with administrator rights, he automatically receives full admin rights with respect to the BMC of that particular server.
Thus, if someone (well ... Mallory is there, for example) root'nered the server, then this attacker can further annoy the victim by “creatively processing” the list of the IIPM users of the machine or, even better, stealing the IIPM logins / passwords (I think already said that storing passwords in the Navy is often not very well thought out, right?), because the IIPM architecture is such that password reuse is likely. In principle, the problem of reusing passwords can be solved to some extent using RAKP (a special key exchange protocol), but its application requires serious skills and is not well described in the literature (it is also worth remembering that RAKP will not help to prevent Mallory in a BMC server on which Mallory has already obtained administrative rights).
Many Naval Forces have their own web server (because, of course , where would they be without it, in a low-level monitoring and administration system ...), which theoretically expands the possible repertoire of “friendly rallies” that Mallory can produce after capturing BMC on a single machine .
Updating BMC firmware is also not too well thought out - firstly, only a specially signed image from the supplier can be flashed “normal” (which means that if a hole was found in your IIMP version, then you have nothing to do but wait when the vendor deigns to write an official update), and secondly, for a number of “relatively budget” server motherboards, the Navy itself is produced by a third party, which turns the update into a task with two (or even more, because the firmware could also be “outsourced”) by unknown .
It is worth noting that during the preparation of his material, Farmer found an exploit that allows SSH to get root on the BMC of the “major vendor” (the details have not been disclosed, because as a responsible person, he decided to give the vendor the opportunity to release the update)
It’s too early to summarize - surprisingly, Farmer’s article is almost the first material trying to generalize information about the IIPM security problems (moreover, the material is being actively updated with interesting details, so watch this space ), but one thing is certain - security IIUP is damn interesting.
I hope, dear Khabrovites, my humble, fluent retelling of a wonderful article not only amused you, but also perhaps interested in another funny and unusual problem.
Having examined the Habr that is dear to my heart, I did not find any mention of this laudable article and decided to correct this omission, all the more so since it was completely in my interests (there was no need to investigate as such - Dan investigated everything before us, but scandal-intrigues are quite traceable).
So, first things first. Who is IIIUP and why did he send some train to hell?
Those from Khabrovsk residents who work in large and beautiful data centers know what it is (and probably use it to the full), for those who are unlucky to work in a large and beautiful data center, I note that IIUP (in the IPMI people, in other words, Intellectual Platform Management Interface) is an intelligent platform management interface. It is present on all server motherboards, and is something like a built-in KVM "on steroids."
This laudable little thing allows the administrator to access the server regardless of the vagaries of the BIOS, OS, and even the CPU - which means that the component responsible for the operation of the IIC (BMC, Baseboard Management Controller, Controller Board) continues to work, even when the server itself is turned off (but not de-energized) or freezes.
Actually, the IIPM is generally extremely resistant to various "troubles", and can transmit data (and provide access) in very diverse "catastrophic" situations. Of course, in addition to the management itself, BMC also monitors, journals,
Delicious? Not really ...
For example, a reasonable question arises - how does this wonderful aggregate solve authentication issues?
And here the problems begin.
Authentication takes place using the username / password pair, the password is not longer than 20 characters, while some BMCs are stupidly stored in their native form (Dell, however, hashes ... but without salt. Twenty-first century, however ...).
Many of them support RADIUS, etc. (not always adequate), but almost always there is the possibility of switching to “emergency” basic authentication (which is actually quite logical - the IIPM should continue to work in emergency situations in which the authentication server may itself be unavailable).
But the most interesting thing is that if someone is logged on to a specific server with administrator rights, he automatically receives full admin rights with respect to the BMC of that particular server.
Thus, if someone (well ... Mallory is there, for example) root'nered the server, then this attacker can further annoy the victim by “creatively processing” the list of the IIPM users of the machine or, even better, stealing the IIPM logins / passwords (I think already said that storing passwords in the Navy is often not very well thought out, right?), because the IIPM architecture is such that password reuse is likely. In principle, the problem of reusing passwords can be solved to some extent using RAKP (a special key exchange protocol), but its application requires serious skills and is not well described in the literature (it is also worth remembering that RAKP will not help to prevent Mallory in a BMC server on which Mallory has already obtained administrative rights).
Many Naval Forces have their own web server (because, of course , where would they be without it, in a low-level monitoring and administration system ...), which theoretically expands the possible repertoire of “friendly rallies” that Mallory can produce after capturing BMC on a single machine .
Updating BMC firmware is also not too well thought out - firstly, only a specially signed image from the supplier can be flashed “normal” (which means that if a hole was found in your IIMP version, then you have nothing to do but wait when the vendor deigns to write an official update), and secondly, for a number of “relatively budget” server motherboards, the Navy itself is produced by a third party, which turns the update into a task with two (or even more, because the firmware could also be “outsourced”) by unknown .
It is worth noting that during the preparation of his material, Farmer found an exploit that allows SSH to get root on the BMC of the “major vendor” (the details have not been disclosed, because as a responsible person, he decided to give the vendor the opportunity to release the update)
It’s too early to summarize - surprisingly, Farmer’s article is almost the first material trying to generalize information about the IIPM security problems (moreover, the material is being actively updated with interesting details, so watch this space ), but one thing is certain - security IIUP is damn interesting.
I hope, dear Khabrovites, my humble, fluent retelling of a wonderful article not only amused you, but also perhaps interested in another funny and unusual problem.