Critical Bug Last Year Allowed Bypassing Authentication On HPE ILO4 Servers With 29 'A' Characters (bleepingcomputer.com) 59
Public exploit code has been published for a severe vulnerability which last year affected Hewlett Packard Integrated Lights-Out 4 (HP iLO 4), a tool for remotely managing the company's servers.
HPE "silently released" patches last August, an anonymous reader reports, adding "details only emerged this spring after researchers started presenting their work at security conferences." The vulnerability is an authentication bypass that allows attackers access to HP iLO consoles. Researchers say this access can later be used to extract cleartext passwords, execute malicious code, and even replace iLO firmware. But besides being a remotely exploitable flaw, this vulnerability is also as easy as it gets when it comes to exploitation, requiring a cURL request and 29 letter "A" characters, as below:
curl -H "Connection: AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
Because of its simplicity and remote exploitation factor, the vulnerability — tracked as CVE-2017-12542 — received a severity score of 9.8 out of 10.
HPE "silently released" patches last August, an anonymous reader reports, adding "details only emerged this spring after researchers started presenting their work at security conferences." The vulnerability is an authentication bypass that allows attackers access to HP iLO consoles. Researchers say this access can later be used to extract cleartext passwords, execute malicious code, and even replace iLO firmware. But besides being a remotely exploitable flaw, this vulnerability is also as easy as it gets when it comes to exploitation, requiring a cURL request and 29 letter "A" characters, as below:
curl -H "Connection: AAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
Because of its simplicity and remote exploitation factor, the vulnerability — tracked as CVE-2017-12542 — received a severity score of 9.8 out of 10.
Cleartext passwords (Score:2)
Re: (Score:2)
They sure picked the name right. They do a whole hell of a lot of huffing and puffing.
Re:Cleartext passwords (Score:5, Informative)
They used a shellcode exploit to return the contents of a file on the ILO processor that has the passwords in cleartext! They didn't publish that as far as I can see, but there is a published python program to add a new user with admin privileges and a password of your choice.
Bad HP! Go stand in the corner.
Is it just me or have HP servers been a bit flaky for the last 5 years or so?
Re: (Score:2)
must be nice to have that meany IPV4 address.
Re: (Score:2)
No matter your vendor, this is a dumb idea. Any 'firmware' or "appliance" should not be easily/directly on the internet.
First you have the problem that even 'reputable' companies lag far far behind the likes of Microsoft, RedHat, and such in changes. Even if they have the will and the resources, the security researchers go to other companies first and put them under embargo.
Second, no one keeps their firmware up to date, even if there exists firmware that does have all the fixes. The really fun part, com
Re: (Score:3)
the other day I bought a IBM M1015 SAS RAID card. I flashed it to be a LSI9211 (no RAID, just SAS). It wouldn't work unless I flashed a specific firmware version with a specific option rom BIOS version.
"Brand name" BIOS and firmware are horribly buggy compared to "just works" regular PC BIOS.
Re: (Score:1)
Second, no one keeps their firmware up to date, even if there exists firmware that does have all the fixes. The really fun part, companies that *do* routinely upgrade firmware get bitten when the vendor breaks them, and does so without a good rollback facility (after all, "downgrades" are a security risk, so a key change with a firmware update that *also* happens to be bad for your configuration, well sucks to be you).
Good example, I worked for a company that upgraded their HP branded Xenserver servers ILO firmware. When the servers rebooted it'd cause a kernel panic, nothing worked due to a bug in ILO or kernel module. Once we disabled the kernel module it booted again.
Re: (Score:3)
Agreed, that's a very bad idea, but not a prerequisite for the flaw to be a problem. It might also be a non-routed address but another machine in the same LAN segment gets compromised and used as a jumping off point, for example.
Re:Cleartext passwords (Score:5, Informative)
The password is used directly as a shared secret for HMAC in IPMI. Therefore to support the ipmi protocol, the server must be able to know the plaintext of the password to a) prove to the client that they know the secret and b) to validate the HMAC sent by the client.
Another potentially tricky one is SNMP. It's a shared secret, but at least you can localize the key. Of course it is localized to an snmp engine id, so while you may not directly have the cleartext password, you can spoof a matching snmp engine id to use the localized key as if you knew the password, at least to impersonate an snmp agent.
Even on the TLS side of things, in practice things are not rosy because the vast majority of this class of devices have a self-signed cert, with all automation disabling cert validation and all users blindly clicked 'continue' at the warnings (there's no harsher message for "we have a conflicting stored cert" than "this is a self signed cert we haven't seen before")
Re: (Score:1)
Re: (Score:2)
Interestingly enough, IPMI's current auth design was done in 2004. Somehow despite being at least two years after SNMP proved someone was thinking about how to derive a shared secret without using it directly.
Somehow despite SRP being a well known thing that would neatly slot into IPMI, no one has bothered to amend the IPMI spec to remove the need for the server to know the password, and also to amend the poor decision for the server to send HMAC first.
Programmers think about making things work right (Score:5, Insightful)
You may have hears the phrase "garbage in, garbage out".
That's how programmers used to think. The design and test code try to make it work right, when the user uses it right, of course. If the user mashes keys at random, random things might happen. That used to be an okay way of thinking.
The internet has changed that. Now the user (connecting over the internet) WILL mash keys at random. Well, their script will send random bytes. It's no longer okay for software to respond in random ways when it receives random input. Any software accessible via the network MUST be designed thinking about how things can go wrong, not just about how it should work correctly.
Many programmers, especially those who learned writing desktop applications, still think in terms of the program doing the right thing when it receives sane input. Insane input isn't handled securely. The programmers who wrote the ilo software made this mistake.
Specifically, the input is up to 16 characters long, so they failed to handle the case of very long input. Network. Software should be tested with these inputs, at least:
Empty input
Zero
The null character (ASCII 0)
Very long input
This is what happens (Score:5, Funny)
... when your network infrastructure was certified secure by the Fonz.
Aaaaaaaaaaaaaaaaaaaay.
Re: (Score:1)
Of course this has been fixed in [[Redfish]https://sourceforge.net/p/redfish-lab/wiki/Getting-started-with-the-iLO5-Redfish-API/] right?
"redfish-lab
Get started with the Redfish RESTful API from the DMTF
Brought to you by: fdonze"
Remove the "d" and you get "fonze". How's that for coincidence ;)
What would be a 10? (Score:2)
What would be a ten? No authentication at all?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Thanks Carly (Score:1)
HP has been garbage since Carly Fiorino was running the place. Why anyone would do business with them at this point is beyond me.
The Next Step (Score:2)
This is great research! Have they tried "AAAAAAAAAAAAAAAAAAAAAAAAAAAAB" yet?
understandable (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Putting the A (Score:2)
The A ind DEA
The A in other Agency.
So safe even the buddy system contractors can use it.
Also affects iLO 5 prior to v1.30 (Score:2)
Once I saw that the latest version is iLO 5, I figured it had to be vulnerable to the same exploit as iLO 4 and sure enough:
https://support.hpe.com/hpsc/d... [hpe.com]
"A security vulnerability in HPE Integrated Lights-Out 4, 5 (iLO 4 prior to v2.60, and iLO 5 prior to v1.30) could be remotely or locally exploited by an Administrative user to allow remote or local code execution."
Dumb implementation if this is a problem (Score:2)
Wiki entry (Score:2)
Wiki entry:
http://uncyclopedia.wikia.com/... [wikia.com]!