BTW you don't need to send As
Anything other than a zero byte will do.
HPE servers running unpatched enterprise software are trivially easy to exploit with just one line of code, it has emerged. The script kiddie-friendly attack route dumbs down exploitation of a severe vulnerability dating from last year which stemmed from coding flaws in HPE's Integrated Lights-Out 4 (iLO 4), a tool for …
Anything other than a zero byte will do.
Yet, the A's make it so much funnier.
Err, erm even the current iLO4 release 4.60 unauthenticated, will leak crackable password hashes.
It's been there since iLO2.
To fix it disable IPMI support.
Another school boy bug still unpatched years later.
Top Google result for the CVE is the Cisco web site...you couldn't make this sh*t up!
Is this a shortening of a Doosra ( an off-spinner bowling to leg )?
No... "doozy" is actually a vestige of the Dusenberg car brand, which was quite an expensive and hot item, so "it's a doozy" means something out of the ordinary.
"doozy" is actually a vestige of the Dusenberg car brand
Alas, appealing though that is, <a href="https://en.wiktionary.org/wiki/doozy>it's a folk etymology</a>.
Dusenbergs <i>are</i> doozies, though, as anyone who's been to the ACD Museum knows. So they may have helped popularize the term.
(Dusenberg or Hispano-Suiza? Discuss.)
It's the Legendary Black Beast of Aaaaaaaaaaaaaaaaaaaaaaaaaaaaa
(hint: definitively not the saviour of the universe)
If I had a dollar for every time someone has unnecessarily written an HTTP server from scratch, I could retire right now and save myself an ulcer down the career.
There's a lot of "embedded HTTP server" libraries around... and it may be difficult to run Apache out of limited firmware resources. And still, you'd need to keep it patched (the only alternative being nginx, not that different).
Seriously using some full fledged webserver when you just want to return a static page, isn't the best idea.
However you should always know what you are doing. If you have unbound writes in your code, chances are that your CGI-script would have simmilar problems even if you used a pre-made webserver.
I'm well aware. And I don't even assume that they're using Linux or other full-fat OS. (Although they should.)
I'm also guilty of writing not just one, but two different HTTP servers for specialized hardware.
But for a product with this kind of volume (and a number 4 right there in the name), you'd think that stability'd be high enough on the list of requirements that they would use a proper library, instead of apparently parsing all the headers by hand.
No, they shouldn't.
That's why I always use my Bash HTTP Server.
Too late for me. This stupid crap has already given me ulcers.
We had to move from a simple reliable and secure serial LOM system to a LOM that just *had* to have network connectivity because the HP serial CLI is not *actually* feature complete, it just markets itself as such.
HP knows the majority of their customers will never use a CLI, and wants to reel in refugees from Oracle's Sun hardware, where you could wholly configure a machine with a single cut and paste *without* freaking out the serial link or needing to reboot the LOM *multiple* times. Enterprise quality.
Why is so much 'progress' *worse* than what came before?
... but often laziness kills.
How does that help since you'll have to open the port from one network to the management network to access the ILO. This exploit needs only the port to be open.
The usual trick is to use a "bastion host" to access the management network. This moves the problem to having to keep the bastion host secure, of course, but even desktop OS's usually have higher security than iLOs. The machine need not run any services other than SSH.
Not everybody should have access to the management VLAN - nor the access needs to be always on. That reduces the attack surface, as you can't just probe the network to find the management applications from any connected device.
I'm not saying this isn't a big bug, and easily exploitable - but this is a situation where a proper network configuration may mitigate the risk greatly.
<face> meet <palm>
Absolutely, deny access unless needed...revoken when no longer needed.
At the most basic level put an external grade VPN in front of the management lan and only allow access to those who actually need it.
When someone gets in this might just stop you being powned...assuming you've patched AND configured the rest of your systems safely.
There is a lot to be said for running your own OpenVas scans internally...from a user's network port.
That old adage: without physical security, there is no security.
Well, iLO puts the physical aspect of your server on the network, so you better be damn sure that the network you connect it to is secure. If you've done that right, you've no need to worry about this.
[/goes off to patch some boxen]
Do we get the BIOS update for free? Or do we have to "prove entitlement" and sign up for a "support agreement"?
Asking for a friend.
The firmware update is on their public site. Our repo picked it up about a week ago - and the 2.6 landed a few days ago. We *cough* use curl to check their repos and update every night.
BTW you don't need to send As
Anything other than a zero byte will do."
IT Guy 1: "Management just bought more HP servers"
IT Guy 2: "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
Will "ohsh**ohsh**wegonnadiewegonnadie" also work?
I've got an HPE microserver running Xpenology as my NAS software of choice. Ive never patched iLO because I assumed something needed to be connected to the dedicated Ethernet iLO port - am I safe if that's true - or can iLO be remotely attacked via the regular Ethernet port?
Never having used a Microserver am not sure if it's iLO capabilities are the same. But on Proliant DL systems anyway you can configure iLO to use either the dedicated port or share with onboard NIC. The default is dedicated.
I believe this holds true for Microservers as well.
I've seen a few machines that defaulted to failover mode, although they weren't Microservers.
Best to check the channel config and make sure the iLO doesn't have an IP address. Under Linux you can do this on the machine with ipmitool.
"There are several DoS attacks involving a simple telnet client that can be used against an NT server.
First, by telnetting to port 53, 135, or 1031, and then typing in about 10 or so characters and hitting enter will cause problems. If DNS (port 53) is running, DNS will stop. If 135 answers, the CPU utilization will increase to 100%, slowing performance. And if port 1031 is hit, IIS will get knocked down. Typically the fix is to reboot the server, as it will be hung or so slow as to render it useless." [c/o NMRC.org]
Been there, done that, laughed during the ensuing chaos :)
Yeah those kind of problems were a bit more understandable two decades ago.
"Those who cannot learn from history are doomed to repeat it" - George Santayana
Back in the old days there used to be a program called winnuke. It sent a single byte of Out of Band data to a Windows machine (it needed an open port as target, so DNS, SMB, etc were all common choices) and then windows choked and blue-screened. Allegedly.
On one of my webservers back in the day I used to see people probing those exploitable scripts that used to ship with Apache 0.9. None of which were on my server but (cough) someone may have installed winnuke under the name of the second common exploit... It must have brought tears of joy to those examining the logs to see 2 exploits probed and then radio silence. Allegedly.
Used Teardrop against a Win95 PC - and the hard drive crashed when I teardropped it.
Techie using the PC was very upset, but he did not know who b0rked his PC.
Biting the hand that feeds IT © 1998–2018