Hacker News Reader

Comment by qualsiasi | Hacker News Reader

I'm no expert, but wouldn't be more efficient to completely replace the BMC with a malicious one? That way it should be virtually impossible to detect

View on HN

The cons to that approach is the work it takes to design a BMC without knowing how the existing one is designed. Replicating all of the BMC behavior is hard. Differences in behavior might be easily spotted, whereas this can lie dormant until triggered. "Why does unit #4322 have a faster/slower ping response?" Oops, discovered!

You don't have to redesign the BMC. Just repackage them with additional dice to take over I/O pins as needed.

Or just reflash the firmware. They should, but most people don't reflash the bios and BMC firmware when they install a new server. In fact I routinely encounter servers that are 5+ years in service that have never been reflashed.

otoh you have to consider the probability that flashing the firmware will brick your server (p >> 0.0 in my experience).

Absolutely, and I think that is why a lot of people are reluctant to do it. It's a fragile process and if you lose power or have a random cosmic ray hit at the wrong time it's game over.

I know more than one vendor who's dumped firmware from BMCs to compare to the vendor image. Simply reflashing the firmware would be caught by this, an implant wouldn't.

Apple, at least, claims they do[1]: "As a matter of practice, before servers are put into production at Apple they are inspected for security vulnerabilities and we update all firmware and software with the latest protections."

[1] https://www.apple.com/au/newsroom/2018/10/what-businessweek-...

They surely don't write their own firmware for Supermicro boards? So "update firmware .. with the latest protections" means update from the hardware vendor?

There's quite a lot of embedded firmware that isn't derived or controlled or affected by BIOS/UEFI firmware updates. e.g. Thunderbolt (PCIe) firmware.

In true HN fashion, I’m not an expert either, but I can think of two plausible reasons.

1) Directly compromising via software the BMC is easy to detect if you bothered to look. (i.e. checksums don’t match), and would only last as long as the BMC isn’t flashed.

2) It’s simply currently easier to make a second component, rather than to integrate it into the main chip directly. Of course, if I was in charge of this project, I’d already be investing resources into exploring this option.

3) the purpose of the operation was to produce headlines and fear in the western press. A few bytes changed in some firmware, or even a malicious BMC design (presumably they're gate-array designs, not full-custom) wouldn't allow for macro photos of a chip the size of a grain of rice and all that.

Or even why two SPI roms?

Why not just one with special code? It's not like anyone is routinely reverse engineering the BMC boot code.

It seems like an awful lot of provable trouble to go through (note that there is no physical evidence in the public eye yet) when you could do the same thing, at the factory, with just software.

>Or even why two SPI roms?

Because AST2400 has input for two flashes, one main, one recovery. And the configuration that uses that is not common. That specific moment actually makes it harder to detect, while being very simple from technical side.

it's pretty easy to dump an SPI chip and some vendors/customers routinely do so.

In this model, the implant basically contains a binary patch that is injected at boot time over a segment of the BMC binary - counter overflows, chip cuts out the SPI and transmits its payload instead. After the payload is injected the implant goes dormant again/resumes passing through the SPI, so dumping the ROM after boot, or even physically clipping onto the SPI chip will not reveal the wu-tang secret.

Wu-tang.

Reply on news.ycombinator.com