iDRACula Vulnerability Impacts Millions of Legacy Dell EMC Servers

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Dawg10

Associate
Dec 24, 2016
220
114
43
This vulnerability will no doubt be quickly patched, but is there an upside for homelab users?

Could a hypervisor be loaded onto the BMC? Could it effectively control the server?
 

sean

Member
Sep 26, 2013
67
33
18
CT
This might be the best source for default passwords when trying to access a new system. I can either dig through documentation or remember STH has them all.
 
  • Like
Reactions: MiniKnight

fohdeesha

Kaini Industries
Nov 20, 2016
2,727
3,075
113
33
fohdeesha.com
This vulnerability will no doubt be quickly patched, but is there an upside for homelab users?

Could a hypervisor be loaded onto the BMC? Could it effectively control the server?
The SuperH/RISC cpus in the bmc's do not have anywhere near the power required for a hypervisor, but your usual linux scripts, absolutely. That was probably part of the reason uh, whoever found this wanted it in the first place. cough
 

MiniKnight

Well-Known Member
Mar 30, 2012
3,072
973
113
NYC
If someone posts this on Reddit, people there are going to have a field day.

Hey, if they need the security hardware for iDRAC 9 wouldn't they need it for iDRAC 8? If that's the case, they ultimately can't patch it completely as @Dawg10 suggested. Just the fact that they added the new hardware to fix this means they've been aware for some time right?

Before the Reddit crowd comes, I agree with @cesmith9999 that this was done well.
 
  • Like
Reactions: fohdeesha

mstone

Active Member
Mar 11, 2015
505
118
43
46
I am wondering why this was taking a long time to show up on other news feeds
because it's basically just a twist on "if you expose your management interface you're already f'd" so there's not really that much to see.
 

cesmith9999

Well-Known Member
Mar 26, 2013
1,417
468
83
Where I just left there are over 20K server that we managed. 20K BMC/iLo/iDRAC that could be running mining or a an easy way to destroy a whole company/environment.

We did change the default passwords as a normal measure. however even changing from the default to a new default has its (own) issues.

Chris
 

PigLover

Moderator
Jan 26, 2011
3,184
1,545
113
IPMI and its various extensions (iDRAC/iLO/etc) have always been weak links in the security chain. I know perimeter security is not considered sufficient in today's world, but this is one place you need to build fences and do things to make the management interfaces almost impossible to breach. They need to be on separate NICs (disable all forms of NIC sharing with production traffic). They need to be on isolated, dedicated physical networks (don't even trust VLAN separation - physically separate). These networks need to be almost impossible to access from outside (private address spaces, tightly controlled "jump servers", for human access and well managed gateways for automation). And you need to be diligent beyond measure about logging and analyzing activity on these jump/gateway servers.

All of this remains true even after vendors like Dell implement trusted compute methods to protect the iDRAC flash.
 

zir_blazer

Active Member
Dec 5, 2016
355
128
43
They need to be on separate NICs (disable all forms of NIC sharing with production traffic). They need to be on isolated, dedicated physical networks (don't even trust VLAN separation - physically separate). These networks need to be almost impossible to access from outside (private address spaces, tightly controlled "jump servers", for human access and well managed gateways for automation).
You are pretty much answering a question that I did recently. Dedicated NIC and Switches for the BMC > shared NIC.


I would love to see this being a push for OpenBMC and Coreboot. At the very least end users can actually audit that code instead of being a complete black box. It also makes possible for a community effort to upgrade and maintain it, otherwise, the manufacturer holds you hostage whenever you want a feature, and typically forces you to purchase newer Hardware when what you want could be backported.
Is like when Intel introduced Firmware support for NVMe boot in their 9x Series Chipsets for Broadwell, BIOS modders at WinRAID managed to transplant the NVMe Firmware Driver to previous generations Intel Motherboards and it worked well. If the Firmware was open source instead of having to rely on a multitude of BIOS hacking tools, doing so would have been easier. Alas, Intel wouldn't have given you what they touted as one of the major selling points of the 9x Chipsets for free.
 

Evan

Well-Known Member
Jan 6, 2016
3,346
598
113
I agree with separate including the dedicated remote management NIC but different switch is really not needed just a seperate secure vlan and ports really.

This is certianly not the first remote management exploit and won’t be the last, remember was it last year HPE iLo v4 had an issue.
 

kapone

Well-Known Member
May 23, 2015
1,095
642
113
I agree with separate including the dedicated remote management NIC but different switch is really not needed just a seperate secure vlan and ports really.

This is certianly not the first remote management exploit and won’t be the last, remember was it last year HPE iLo v4 had an issue.
I'm adamant about IPMI/Mgmt ports being on a physically different switch. These ports are by far the most important ports in your network. If BMCs can have a vulnerability ... who's to say a switch firmware can't? I will not trust these ports to just VLAN segmentation.

In fact in my setup, the IPMI/Mgmt ports are on a different switch, connected to the router/firewall on a dedicated interface and have very tight firewall rules on that interface. This switch even has port security and MAC address restrictions enabled so that you can't just plug something in, physically, to get access.