Then you've already lost.
The BMC needs to be ideally on a physically isolated network, or at least a separate one that has no route from the outside nor on the machine itself.
Anything that makes privileges escalation exploits more damaging is a real problem. I’m getting tired of how these are being dismissed as if admin access should mean that you can ignore any security issues. There are things that even admin accounts should not be able to change at the hardware level, or if they can they must be reversible in the future by another user with admin access.
> The BMC needs to be ideally on a physically isolated network, or at least a separate one that has no route from the outside nor on the machine itself.
This is good practice but it shouldn’t excuse poor security at the hardware level.
Supermicro motherboards also commonly default to having a feature that bonds the BMC network interface to one of the main NICs if you don’t plug a cable into the BMC interface. It’s common for people to be surprised that their BMC is exposed on their main network because they didn’t plug in a cable on the BMC NIC port at all.
Some of the Supermicro boards don't even have a separate BMC NIC, the only choice is to bond it to one of the main NICs or sacrifice one of them to be BMC only. I try to pay attention to that now after being surprised by that once on some servers we bought.
Yes, all of which can be reversed by another admin in the future. That is expected.
It should not be the case that getting admin access one time can result in modifying the hardware in a way that can’t be reversed by future admin, short of physically reflashing the chip on the board.
If you have admin on windows you can flash the bios on regular motherboards with firmware that refuses to change.
It's really the "permanently" which is the design flaw. Boards should have a mechanism to recover from bad firmware, and the same mechanism is useful to recover from a bad flash.
Make the flash chip removable, or leave a JTAG. Or have a bit of actual ROM with the write lines not even connected and just enough of a firmware to be able to reflash the main one.
The vendors even sell this as downgrade prevention!
If administrator access is equivalent to ownership, then I strongly disagree.
Even if you changed the default from "failover" in the firmware you're just one CMOS reset (for whatever reason) away from it reverting back to putting the BMC on whatever network interface. This should really be something you can jumper off.
So you'd definitely have to have it connected to the internet somehow, even if very indirectly, and in an independent manner (different network with no direct routes).
Flashing data? Fine.
Permanent? Not so much.
It is common to keep admin and backup functions on separate network interfaces, on a disconnected network. You have to physically connect to the network in a secure location to use it.
How do you track the chain of custody of your servers? Do you sample them at random to ensure they aren't compromised?
Bloomberg never backed away from their story about Chinese implants in Supermicro servers. Perhaps this is why?
This is exactly the kind of barrier you want for something with so much power over the system, otherwise you're not much better off than where you started as physical access allows for quick swaps of chips.
Meanwhile it provides no meaningful resistance against physical access because someone with physical access can swap the entire board or a dozen other things.
There are others here more qualified to comment, but I do have some old rack mount enterprise servers making a racket in my basement, so I can provide some sort of half-informed opinion here--
Besides the security issue with the BMC here, it sounds like SuperMicro _also_ has absolutely insane defaults.
Every system I have has a separate, dedicated NIC for the BMC. There is an _option_ which is disabled by default to instead have it share one of the other interfaces. So the only ways you're going to "accidentally" put the BMC on an insecure network are:
1. Rebooting the server, going into the BIOS configuration, going into the options for the BMC, and explicitly telling it which other network device to use.
2. Physically accessing the server, attaching an ethernet cable to a clearly labelled BMC port, and attaching the other end to an insecure network.
From what I'm reading here, SuperMicro's default approach is apparently more "eh, just use whatever happens to be plugged in at the time". So even if you do have it running on a separate, secure interface... if someone unplugs it, it's going to switch to using whatever other connection is available!
To connect to the BMC on my servers you first need to be on the internal network already. Then you connect via wireguard to the router on the rack. Then you can connect to it and given a username/password you can log in. I would be pretty pissed if a cable got unplugged and that meant that the server decided to instead throw the BMC _on the interface connected directly to the public friggin' internet_. And this is just equipment I use for play and hosting my own random junk!
Should every software config require buying new hardware because the initial config gets permanently flashed with an e-fuse to only allow a single write? You could even make a security argument for such a setup, but good luck getting approval for your 15th motherboard this quarter because you typo'd the config.
Also, dban and degaussing is not entirely equivalent -- from a practical perspective the equivalent is hard drive shredding (because the hardware cannot be used again in the old/non-malware config -- dban and degaussing are more like factory default resets). Do some organisations need to do this? Sure. Should we design systems with the assumption that any mistake means that the hardware is destined for the shredder? I would hope not...
It’s not common in modern IT, and the only time I do it myself is in the course of preserving vintage hardware
And if you need to desolder to remove the malicious code, it's pretty reasonable to call it unremovable.
If you are magnetically destroying hard drives as part of decommissioning, that's not really the same thing. You're not using admin access to do it, and you're not making a change that permanently applies to all future use of the device (because there is no future use).
You don't go ahead and erase the same disk once a week. Decommissioning isn't something that occurs for the same project, once a month.
Its not the same operational process.
Is this documented?
If it's documented, it's not an excuse for not reading documentation. You're not supposed to throw stuff (hardware or software) in production without reading the documentation.
You might see that as a facetious comparison. But the number of orgs which actually would desolder the chips in that circumstance is very close to the number which actually would scrap and replace. And if 99% of orgs won't actually do it when needed, then a "works in theory" method of re-securing servers is real-world useless.
> infect it with unremovable backdoor
> stop paying server so company rents server to somebody else
> ????
> profit!
What chip are you using to bit bang? Is that chip directly or indirectly controlled by the firmware? Usually it is.
True in the common case, but this can/should be guarded against by disk encryption and secured boot chains.
Anyone can delete a file. Nobody wants to ban deleting files.
More generally, when you get down to the bottom of the pile of elephants, you are requesting some software currently running on your computer to write some bits to some kind of storage medium.
But there is no law of physics that says the software must to do as you ask! If the software is malicious, it can refuse. It could even pretend that it updated the bits but not actually do so.
"Oh, but I booted into $OTHER_PROGRAM and it writes the bits!"
Maybe. But how do you know that the boot loader faithfully loaded it? You don't. Maybe the boot loader is malicious and patches your firmware updater so that it won't actually write new firmware.
If you squint and tilt your head, it kinda looks like Ken Thompson's "Reflections on Trusting Trust".