Be Careful what you Scan for!
After some fun and games at one customer site in particular, I found that the SSL services on the earlier versions of the HP Proiliant Servers iLo ports (iL01 and iLO2) are not susceptible to heartbleed.
However, their implementation of SSL is fragile enough that scanning them for the Heartbleed vulnerability will render them inoperable. This affects Proliants from G1 all the way up to G6, as well as many of the HP Bladesystems.
A complete power down of the entire system - as in remove both of the AC cables - is required to reset the iLo card and bring it back to life. While this may seem like a quick fix for a single server, if that server is running a Hypervisor, or if it's a bladesystem with Hypervisors running on the blades, this can multiply to be a huge issue. Especially if your client scanned the server subnet, and effectively bricked all their iLO cards before they realized there was a problem (oops)
(And yes, the fact that we worked this out Easter weekend is somewhat ironic.)
Full details are in HP Support Document c04249852
This illustrates that even when scanning for simple things (with NMAP, Nessus or any other scanning tool really), it's best to scan a few test systems first - or if you have a test VLAN that replicates your production systems, even better! This isn't a problem with the scanners, almost always the problem is the fragility of the service being scanned. Many services are only written to deal with "the right" inputs, which is not how most scanners (or most attackers) tend to operate.
Safe Scanning Everyone!
========================
Rob VandenBrink
Metafore
Comments
Anonymous
Apr 24th 2014
1 decade ago
Anonymous
Apr 24th 2014
1 decade ago
The HP iLO apparently doesn't respond well to unexpected queries against it's SSL stack - yet another reason why this type of device should be segmented off your network and certainly not internet accessible.
Anonymous
Apr 24th 2014
1 decade ago
Anonymous
Apr 24th 2014
1 decade ago
Anonymous
Apr 24th 2014
1 decade ago
Anonymous
Apr 24th 2014
1 decade ago
Nessus has several decision points along the path when checking for Heartbleed. It checks if the host is up, is the target port open, is SSL running, are heartbeats supported, THEN it checks for Heartbleed.
If the host in question doesn't run SSL or doesn't support the heartbeat extension, then the actual check is never run, because Nessus has determined that it is not vulnerable.
So - correct, Nessus does not crash these identified iLO hosts
but, the actual Heartbleed check is never executed, which is why Nessus does not.
+1 to Tenable for writing one of the more intelligent scanners in the industry. Many of their defaults are set with an eye towards "how can we NOT crash the target". However, once you start scanning "for real", you'll find that you need to change many of these defaults to do the best job. So knowing what you are scanning, scheduling potential service interruption windows and so on is a really good practice, no matter what tool you are scanning with.
Anonymous
Apr 24th 2014
1 decade ago
Anybody try Dell's iDrac?
Anonymous
Apr 24th 2014
1 decade ago
http://h20565.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay?javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken&javax.portlet.prp_ba847bafb2a2d782fcbb0710b053ce01=wsrp-navigationalState%3DdocId%253Demr_na-c02629048-2%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.tpst=ba847bafb2a2d782fcbb0710b053ce01&sp4ts.oid=3239482&ac.admitted=1397514098285.876444892.492883150
Seems old iLO just has a lousy networking stack and vulnerability scanners trigger bad things.
Anonymous
Apr 24th 2014
1 decade ago
Anonymous
May 1st 2014
1 decade ago