Live data from Hacker News

Making sense of the alleged Supermicro motherboard attack

lightbluetouchpaper.org

71–80 of 328 posts

Re: Making sense of the alleged Supermicro motherboard attack

#71
post #65

I think the attacks are real. A year ago, Google announced their Titan firmware security chip[1], which would limit these kinds of attacks. I don't believe they designed and built this chip, and surrounding infrastructure, because of purely theoretical attacks. Besides that, over the last couple years there has also been a lot of work trying to neuter the Intel ME, because of how dangerous it is. Another example is t…

First guess: not being allowed to admit it due to national security reasons and it being an ongoing investigation. On the same day several Russians were exposed trying to attack OPCW. They were exposed by Dutch military intelligence. At the press briefing the UK ambassador was there. Same day US indicts several Russian spies. This to show that these are major, international events and that proper disclosure towards investors is probably on the back burner as long as operations are continuing. It must be maddening for those involved not to be allowed to discuss it, or even having to actively lie about it while government officials leak freely in the game of thrones.

Re: Making sense of the alleged Supermicro motherboard attack

#72
post #13

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

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.

Re: Making sense of the alleged Supermicro motherboard attack

#73
Ok, that finally makes a bit of sense about "if" this is true, how it might be carried out. And I agree with the author that the simplest action for a chip on the SPI bus would be to hold the MISO line low during power on to suggest to the BMC chip that its QSPI flash isn't programmed (note that QSPI starts up as 'regular' SPI and then switches over[1]). I would guess that the next thing the BMC would do is assume its on the factory floor and hasn't had firmware loaded yet and so it would attempt to boot via TFTP from some server to start the firmware loading process.

FWIW at NetApp the firmware engineers called the BMC the 'BiteMeChip' because they always caused issues when bringing up a new filer motherboard. They were finicky, were often hard to update, and when misbehaving could completely screw up the system.

So I can see this as a vulnerability but really I'd want to stick some probes on that 'mystery' chip and make sure it wasn't just some LC filter or something which is shunting off noise on the data lines.

[1] https://github.com/ChuckM/stm32f469i/tree/master/demos/qspi

Re: Making sense of the alleged Supermicro motherboard attack

#74
post #13

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

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.

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.

Re: Making sense of the alleged Supermicro motherboard attack

#75
post #56
post #5

Earlier quoted context omitted.

If it replaced a DNP part, it could have been found at a flying probe test. Half the expected impedance on a few of those pins? Also AOI might have picked up a difference.

AOI would miss the chip if it were buried between layers or look exactly like a part it was replaced for.

I wonder how the auditing team detected it. X-rays?

Re: Making sense of the alleged Supermicro motherboard attack

#76
post #5

Earlier quoted context omitted.

If it replaced a DNP part, it could have been found at a flying probe test. Half the expected impedance on a few of those pins? Also AOI might have picked up a difference.

Flying probe testing is unlikely to be used for this type of product.

Sounds like a randomized sample of boards needs tested against a reference then.

Re: Making sense of the alleged Supermicro motherboard attack

#77
The fact that cursory examination finds the attack is not only entirely feasible, and completely undefended against, but that the hardware shown in the Bloomberg animation is precisely the hardware which would be required to pull off the attack is quite astonishing.

Whose “law” is it that the closer you are to an event the more you can see that the reporting on the event is desperately flawed? This has almost always been my own personal experience.

To have the article hit the nail on the head with a entirely plausible attack means one of two things;

1) This is exactly what happened

2) A nation state wanted us to think this is exactly what happened.

Either way the NSA is involved. The people on the ground who knew it happened would have to be NSL’d from telling their superiors that it happened, so they leaked it.

Perhaps the denials from above are entirely sincere because the people who discovered it can’t pass it up the chain.

The only thing I’m having trouble with is that would have required either a low-level plant to have discovered it and someone else at a low-level found out and was sworn to secrecy, or a middle-manager plant intercepted the message as it went up the line.

The alternative, that this is a false flag, is pretty fascinating in its own right. TAO would have had to conceptualize the attack vector, and then someone planted the story.

Perhaps this is equally likely. In fact, this is actually an attack I assume TAO is using in the field, which would burn this attack vector presumably because they have an even better one.

Even more interesting, the idea TAO was actively using this attack vector, saw evidence in the field their attack was discovered (devices going dark) and so preemptively planted a story to blame the opposition before they accused the US of the same thing.

Re: Making sense of the alleged Supermicro motherboard attack

#78
post #66

I’m just going to throw this out there: BMCs and ILOMs are for tiny shops where “the IT guy” might have to do something from the beach at Cannes on their vacation. If you are a large operator like Apple you absolutely do not need BMCs.

Not just tiny – any place where you don't want work to be rate-limited by the time it takes to get a body in front of a server. The only scale where it's not a big win is when you're so large that you have rock-solid auto-recovery in your software stack and hardware failures are handled by disabling a server and leaving it in the rack until it's periodically reaped at a regular interval.

Most businesses are in that gap – definitely not tiny, but definitely not able to just ignore remote management – especially if they have lots of physical locations and it's not practical to have 24x7 IT staffing at every branch office.

Re: Making sense of the alleged Supermicro motherboard attack

#80
post #78
post #66

I’m just going to throw this out there: BMCs and ILOMs are for tiny shops where “the IT guy” might have to do something from the beach at Cannes on their vacation. If you are a large operator like Apple you absolutely do not need BMCs.

Not just tiny – any place where you don't want work to be rate-limited by the time it takes to get a body in front of a server. The only scale where it's not a big win is when you're so large that you have rock-solid auto-recovery in your software stack and hardware failures are handled by disabling a server and leaving it in the rack until it's periodically reaped at a regular interval. Most businesses are in that g…

Remote office management can be handled by a KVM with remote access. These can be security hazards in their own right, but it’s a lot safer than having some vendor junk literally hard-wired to your PCI bus.
Post reply on HN