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 …
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!
This post has been deleted by its author
"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.)
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.
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.
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?
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.
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]
This post has been deleted by its author
"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 :)
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.