Investigating Implausible Bloomberg Supermicro Stories
servethehome.com
servethehome.com
Meanwhile at the NSA, in 2008: "Not only can we do that, we'll throw in a high frequency radio as well for beating air gaps, and it will only cost you 10k! Oh, and we'll fit it INSIDE an ethernet port."
https://en.wikipedia.org/wiki/NSA_ANT_catalog#/media/File:NS...
I'm sure the 2018 series is even smaller and even cheaper...
An implant small enough to go unnoticed on a motherboard somehow compromising the BMC to exfiltrate data or control doesn't strike me as the least bit far-fetched.
I can't guess at what 2018 NSA might have, nor can I guess at what 2018 PLA might have, but I think it's hard to jump immediately to believing this.
And Amazon also runs the GovCloud. And are the leading vendor in the race for Pentagon's cloud contract.
This isn't about replacing components. It's about dumping a chip somewhere and magically adding traces to the mainboard to connect it to critical components. Except this is impossible unless the motherboard was specifically designed for the purpose of being bugged.
I find this article to be much more convincing https://www.theregister.co.uk/2018/10/04/supermicro_bloomber...
It points out that 6 pins is enough to intercept and inject code into the SPI bus between the Baseboard Management Controller and it's bootflash.
Once you have code running on the BMC, you can use it's capabilities to call home (via either the BMC's nic or the main nic, depending on how well the network firewalls are locked down) and then modify or simply read the main system's memory.
I don't want to claim that Bloomberg is right about the attack happening, just that the attack is surprisingly plausible.
They’re also taking bloomberg verbatim, when they likely have technical details incorrect. That doesn’t mean the gist is wrong (which may or may not be, I have no idea, I just think a lot of this article’s arguments are on weak foundation).
* The Chinese supply chain interdiction / implant installation is real
* Those companies ARE aware of such events
* Those companies DID report it to USGOV
* The investigation is classified and Bloomberg didn't know or doesn't care
* The government is doing its traditional "Deny, disavow, do not acknowledge" etc.
* The companies were probably threatened with legal action / gag order preventing them from acknowledging the event
When I started working for DOD, one of the things in training was that you were always to say "I can neither confirm nor deny X". Eventually they realized that this statement itself is revealing, and suggested you just STFU.
The whole thing sounds incredibly plausible, and nooooooooobody was supposed to know about it.
(It absolutely shouldn't in a democracy, but there are plenty of things that shouldn't happen in democracies that have been happening lately)
I mean, what would happen if this was seen as an act of war by the President's office? Surely there would be some above-and-beyond damage control measures.
That's not to mention the lack of evidence of an operation of this scale. Keeping that amount of people quiet for this long is something more newsworthy to me than spy chips.
There are people at Amazon and Apple that know and are participating in an investigation. The vast majority of people (including almost all executives) don't know.
Amazon's denial for example came from the CISO of AWS (who is a VP), not Michael Cava the CSO of Amazon itself (who is an officer of the company) and the most likely person to be handling the situation.
> @tim_cook is right. Bloomberg story is wrong about Amazon, too. They offered no proof, story kept changing, and showed no interest in our answers unless we could validate their theories. Reporters got played or took liberties. Bloomberg should retract.
https://twitter.com/ajassy/status/1054401346827243520
Given that the alleged incident concerned Amazon Web Services, I would hesitate to make the assumption that anyone knows more or would be more involved than AWS's CEO and CISO. Of course, you can accuse them of lying, but it seems unreasonable that they would both somehow not know.
I don't know much about Michael Cava but I'd guess from his LinkedIn job description that he's involved in Amazon.com security specifically and not AWS. He is not listed as an officer or director in the investor relations website: https://ir.aboutamazon.com/board-of-directors while Jassy is.
Cava's job as he described it on LinkedIn sounds like it involves retail operations security, and not AWS data center security:
> Serve as the Chief Security Officer for Worldwide Operations and Customer Service. Lead a team of security, loss prevention, inventory control and business continuity professionals providing physical security design standards, access control management, loss prevention and shrink reduction programs, inventory quality assurance, crisis management and investigative services in support of Amazon's global fulfillment, logistics, delivery and retail operations. (emphasis mine)
> That first part starting with “telling the device…” is nonsensical.
A fairer statement, in light of the article's own explanation, would have been "assumes that the BMC is networked in an insecure way unusual (perhaps even unheard of) at large sophisticated tech companies, or a network compromised in such a way to bypass blocked egress routes."
In other words: no. The statement is perfectly sensical, and probably even true of many networks. The author simply doubts whether this could be possible in what he regards as a properly configured (and not otherwise compromised) network.
> The next inaccuracy to this paragraph is the line describing BMCs as “giving them access to the most sensitive code even on machines that have crashed or are turned off.” That is not how this technology works.
But the author then goes on to explain how BMCs could indeed be used to power on machines that were previously powered off, potentially allowing access to sensitive data. (Presuming that the machine is also compromised in other ways, presumably by downloading malicious code).
Er... couldn't a hypothetical backdoor BMC chip... turn the server back on? And then off again when it's done?
A BMC really should be just a fully open minicomputer. Ideally there'd be a slot for something like a Raspberry PI to be used as an add-on BMC card.
Based on my experience in the industry, I'd say this isn't quite accurate.
Yes, the author is correct in his assertion that BMCs are typically provisioned on private networks that are only accessible to outside users via a VPN. He is also correct that you cannot "tell" the BMC to do anything without access to that private network.
However, the author assumes that the operator has disabled egress connectivity on the private network setup for OOB BMC access. In reality, that happens less often than you'd think. Many firewalls by default do not block egress requests and without egress filtering, the BMC can still make outbound requests to the public world. A compromised BMC could easily "phone home" and receive instructions from a command and control server.
I've seen many that use flat management networks, which is a bad security practice, but connecting it to the Internet would require a new level of stupidity.
Good shops will also disable all IPMI port traffic (623) on general vlans, as part of wider edge filtering (no egress of 1-1024, with exceptions for specific mgmt protocols like remote assistance, but only from specific origins).
In summary, BMC has long been considered a potential backdoor and been severely restricted for a decade. It is certainly one of the least interesting things you could choose to compromise if you were building a motherboard implant. More interesting things would include: RF antennas built into the PCB or ethernet PHY, but with plausible deniability, i.e. could be parasitic.
That's why I disagree with the author's assertion that this type of attack vector is completely implausible. It's entirely plausible if the network operator has not firewalled egress connectivity.
For HP iLO you have to pay for Advanced Premium Security Edition to get security features like firmware validation. You have to manage a fleet of licence entitlements otherwise your security stops working. Just managing that much licencing is a full time job.
iLO also has user scripts that can be downloaded to the controller -- what could go wrong ¯\_(ツ)_/¯. Lots of hardcoded credentials in the example scripts. It does at least have https, but managing the certificates is another big job.
Someone with the sophistication to drop a chip onto a motherboard during manufacturing (which I don't doubt) and get it to the right customer could most likely slip a more advanced implant to bridge networks into a workstation headed to the NOC.
I am genuinely curious, development or non development?
But you don't need to be a network engineer to observe these problems out in the wild. Have you ever bought a dedicated server from a small ISP, asked for IPMI connectivity and they replied with a public IP address? Or the BMC was able to mount ISOs hosted externally on public shares?
> That first part starting with “telling the device…” is nonsensical. If you are in the industry or read our Basic BMC and IPMI Management Security Practices piece, you would know that this is false.
This is not a very well-written article. How does this website's "best practices" document refute Bloomberg's story? The obvious problem is that not all organizations follow best practices, including many that you'd assume would, and those that do don't always follow them consistently. More subtly, if the BMC is subverted, you can't rely on to follow its normal programming or configuration: even if you have a segregated management network with no network access, the subverted BMC isn't required to use it and can use the "shared port" instead.
When you're dealing with subverted hardware or software, you have to throw out most of your assumptions about how those things work that were formed in normal cases. It's clear that the authors of this article did not do that.
The article raises a fair number of solid criticisms regarding BCP to eliminate the described vulnerability.
[0] https://www.theregister.co.uk/2018/08/22/supermicro_facing_n...
Right.
So then the SMCI short can be ruled out. What else could fuel this madness?
I get that it is extrordinary, and requiring extrordinary proof as a result. However, extraordinary is not at all the same as implausible. There are examples of similar attacks in the wild, no matter how many orgs argue they are not affected.
In any event, I have a couple questions.
1. Is it possible that some kind of small chip could subvert there boot process of the BMC?
2. Can the BMC subvert the host system in some useful way that would be hard to detect? I'm thinking about altered microcode loaded at CPU powerup.
3. Can the altered microcode be used to subvert the host complex remotely? This could be something like a Spectre or Rowhammer attack.
2. Highly Unlikely, but can’t be entirely disproven from what I’ve seen.
3. See #2
Assumptions. This article is full of them.
But it's interesting. Apple (mainly) and Amazon and a few others seems to have successfully turned the narrative to the question of whether or not Bloomberg got played.
At that point it seems like Bloomberg has to put forward something a lot more concrete than "X anonymous sources told us so" or lose all credibility. (Or they can retract, though at this point, after multiple double-downs, it would would take a wholesale editorial clearout and significant time to return to credibility.)