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…
Making sense of the alleged Supermicro motherboard attack
71–80 of 328 posts
Re: Making sense of the alleged Supermicro motherboard attack
#72I'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.
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
#73FWIW 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
#74I'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.
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
#75Earlier 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.
Re: Making sense of the alleged Supermicro motherboard attack
#76Earlier 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.
Re: Making sense of the alleged Supermicro motherboard attack
#77Whose “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
#78I’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.
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
#79Re: Making sense of the alleged Supermicro motherboard attack
#80I’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…