Supermicro boards were so bug ridden, why would hackers ever need implants?(arstechnica.com)
arstechnica.com
Supermicro boards were so bug ridden, why would hackers ever need implants?
https://arstechnica.com/information-technology/2018/10/supermicro-boards-were-so-bug-ridden-why-would-hackers-ever-need-implants/
80 comments
[deleted]
I would guess that large companies are refreshing with known good firmware before deploying servers? So while described approach is easier prob will not get attacker as much.
You would guess wrong because a) large companies are profit motivated and that is a cost that can be cut and b) even if you "refresh" firmware, what actually is happening in there? You don't really know, so the "refresh" may not be as effective at wiping out the attack as you had hoped.
Most BMC updates are handled in software on the BMC. You're giving the BMC a new image file to write and trusting the BMC to actually write it. Who's to say the BMC is dutifully writing that image to the flash memory? Who's to say it doesn't re-infect the image before writing?
Even if you do directly connect to the flash module and directly write to it through SPI, if the attack is being loaded by an additional module between the flash memory and the BMC, it could still inject additional data into the BMC's boot. If you're not physically listening to the SPI data being transmitted or knew what to look for in the final environment of the BMC, you wouldn't know it had happened.
Even if you do directly connect to the flash module and directly write to it through SPI, if the attack is being loaded by an additional module between the flash memory and the BMC, it could still inject additional data into the BMC's boot. If you're not physically listening to the SPI data being transmitted or knew what to look for in the final environment of the BMC, you wouldn't know it had happened.
Okay, crazy tinfoil hat time: what if this story is a plant from a particular part of the Chinese government (like PLA Unit 61398), designed to give the impression of the ability to disrupt global supply chains and to build respect through fear?
If all of these unnamed sources are unnamed because they were adversarial members impersonating government officials, then that would make a little more sense why current government bodies are not just staying mum, but actually denying knowledge of the story.
With the software attacks being much more feasible as the Ars article points out than a hardware attack, then it would also make it so that the vehement denials from affected companies would be true as well. The whole thing could be a large disinformation campaign to strike at the very core of what many would otherwise consider reasonable security.
If all of these unnamed sources are unnamed because they were adversarial members impersonating government officials, then that would make a little more sense why current government bodies are not just staying mum, but actually denying knowledge of the story.
With the software attacks being much more feasible as the Ars article points out than a hardware attack, then it would also make it so that the vehement denials from affected companies would be true as well. The whole thing could be a large disinformation campaign to strike at the very core of what many would otherwise consider reasonable security.
It seems like this would be a really bad idea. Scaring companies away from buying Chinese-manufactured products couldn't possibly be worth the respect through fear.
No.
A better tinfoil hat theory is that the whole story was fabricated by Russia, to (you know, as always) sow chaos.
A better tinfoil hat theory is that the whole story was fabricated by Russia, to (you know, as always) sow chaos.
But the effect of that would be to cause massive distrust of Chinese suppliers and cause a shift away from electronics being produced there. IC and cyber experts generally identify the Chinese as using intelligence operations for primarily economic purposes, as compared to Russian/Iranian/North Korean objectives being military or political. A Chinese military intelligence agency using cyber espionage to intentionally disrupt one of the most significant export industries of the Chinese economy does not seem likely, nor does it seem to provide such an out-sized strategic benefit as to be worth the economic cost.
Good point, I agree with that thinking. But the actual execution of such a hardware-based attack would surely be discovered at some point anyway, and risk the same negative outcome. So then that would leave the only possible conclusion that the story just isn't true at all. In the end, none of it makes clear sense...
The difference is two-fold: actively planting a fake story means that first, the espionage is fake and thus no real intelligence can be gathered, so the only benefit is the hypothetical respect you suggested; second, the story will definitely get out, thus the potential for the negative effect is innately 100%. However, as a real intelligence operation the cost/benefit analysis is inverted, because there is a real, tangible benefit to extracting possibly sensitive commercial and national security information. And while an eventual discovery is always a possibility, it seems care was taken to ensure it would only be a small possibility, and that in any case it would be in the future, hopefully after a large amount of useful data is extracted.
So in the planted story hypothesis, there is certainty of negative outcomes with only the potential for positive outcomes, and those only intangible, while in the this-is-real hypothesis, there is near certainty of some tangible benefit with good probability of significant tangible benefit, with only a potential, distant, deniable risk of negative outcome.
So in the planted story hypothesis, there is certainty of negative outcomes with only the potential for positive outcomes, and those only intangible, while in the this-is-real hypothesis, there is near certainty of some tangible benefit with good probability of significant tangible benefit, with only a potential, distant, deniable risk of negative outcome.
I would say that given the amount of motherboard variants, even gene rationally that have varying differences, especially in component supplies, it was pretty unlikely to see the issue. I mean, while some may take a MB out and inspect it thoroughly, most that I'm aware of, will plug it in and if it works, leave it there.
I can't cite this case specifically, but normally it would be incredibly difficult to impersonate a government official as a source.
In my experience verifying a source means weeding out that possibility before publishing... e.g, cross-checking data from a third party (background checks, employment history, social media accounts, public records), then photos of credentials, video chats, etc. Then you cross-reference information with other sources on the story, etc... conspiracy is possible, but unless Bloomberg is inflating the number of sources it has, it would have to be a massive undertaking (state-sponsored).
Anonymous doesn't typically mean someone just calls up and says something and then it's off to the presses. They know exactly who gave them the information, but they're protecting the identities.
Maybe claims of "fake news" would be a lot less common if more people knew what went into verifying information before a major news outlet publishes a story.
In my experience verifying a source means weeding out that possibility before publishing... e.g, cross-checking data from a third party (background checks, employment history, social media accounts, public records), then photos of credentials, video chats, etc. Then you cross-reference information with other sources on the story, etc... conspiracy is possible, but unless Bloomberg is inflating the number of sources it has, it would have to be a massive undertaking (state-sponsored).
Anonymous doesn't typically mean someone just calls up and says something and then it's off to the presses. They know exactly who gave them the information, but they're protecting the identities.
Maybe claims of "fake news" would be a lot less common if more people knew what went into verifying information before a major news outlet publishes a story.
What has truly surprised me in all of this is the skepticism expressed about this being plausible. Most nerd sites are rife with thoughts on how insecure things are and hypothetical ideas on how something could be compromised but all of a sudden this one isn't possible? We know the US Gov't has done it in transit but it's ridiculous to think a state owned manufacturer wouldn't do it on the factory line?
We know this very state does it to laptops brought into the country by corporate execs (https://www.securityinfowatch.com/blog/10861870/keeping-secr...) but again, there's no way they'd do it on a factory line?
I don't get it. Are we so confident that Amazon, Google, and Apple wouldn't fall for this that we refuse to believe it? I know everyone is saying "show us a compromised board!" but it's very likely that the our Gov't would ask that either (a) those boards be left in place or put in a honeypot so the enemy doesn't know that we know or (b) get handed over to them for forensics, etc and probably destroyed.
For the most part in my nerd circle of friends I've noticed that the only ones that believe the Bloomberg story are the ones that were or currently are in the intelligence community. Everyone else thinks it's Bloomberg being dumb because of that whole "they pay journalists based on how they change stock prices" article.
We know this very state does it to laptops brought into the country by corporate execs (https://www.securityinfowatch.com/blog/10861870/keeping-secr...) but again, there's no way they'd do it on a factory line?
I don't get it. Are we so confident that Amazon, Google, and Apple wouldn't fall for this that we refuse to believe it? I know everyone is saying "show us a compromised board!" but it's very likely that the our Gov't would ask that either (a) those boards be left in place or put in a honeypot so the enemy doesn't know that we know or (b) get handed over to them for forensics, etc and probably destroyed.
For the most part in my nerd circle of friends I've noticed that the only ones that believe the Bloomberg story are the ones that were or currently are in the intelligence community. Everyone else thinks it's Bloomberg being dumb because of that whole "they pay journalists based on how they change stock prices" article.
I don't hear skepticism on plausibility.
I just hear skepticism based on lack of actual evidence, as there has been, to date, exactly zero. For a hardware back that could only have been done at a large scale.
I just hear skepticism based on lack of actual evidence, as there has been, to date, exactly zero. For a hardware back that could only have been done at a large scale.
This is why I am skeptical. I will not presume to know how Supermicro and Elemental operate but I find it unlikely that this would go unnoticed by both of them. The guys I work with raise hell if CRCs on firmware images don't match, much less a BOM change. There are a lot of QA breakdowns that have to happen after manufacturing for this sort of attack to be successful. Could it happen? Sure, but there should be some sort of available evidence. What about the rest of Elemental's customers? Did the government manage to quietly take all of their servers as well?
Eh... it's not quite that simple. Checking the firmware before it goes into the device is not the issue. It's after the firmware is in the (integrated) device that it's an issue. How do you check that? You have to boot the device to calculate the CRC. Now assume that the device's bootloader is compromised and that the device actually has more internal storage than you thought. Now what? Ensuring correctness of firmware to verify the device won't do something you've never seen it do is quite difficult.
I just brought up the CRCs as an example of due diligence. This attack, as I understand it, hinges on a design and BOM change to the board. So my question is how did that change manage to make it past both Supermicro and Elemental?
Simply put, they never checked?
Depending on what the chip did, the CRC on a firmware image may not actually change. If the chip was just listening to the SPI lines to the BMC's load, it could just inject additional data into the stream. The flash chip on the board could be 100% legit, but the final image loaded on to the BMC might be malicious. Do you really CRC the entire BMC environment after boot, or just check the image when you go to update the BMC?
I think that most rational people hold a state of natural disbelief to conspiracies in general. For example, 10 years ago, the thought of a government slurping up all network communications into large collections of data storage for later analysis seemed so unlikely. The cost of storage, the expanse, the inability to make any effective querying against the data... just made it seem highly unlikely.
Then you come to find out it's actually happening. It just seems like such a huge thing that's hard to comprehend. I, personally believe it's entirely plausible.
Then you come to find out it's actually happening. It just seems like such a huge thing that's hard to comprehend. I, personally believe it's entirely plausible.
Yes! I am amazed at the general attitude of skepticism expressed in response to the Bloomberg article.
BTW, Amazon doesn't know anything about security. Every day I observe examples of people who work there, wittingly or unwittingly, doing things to erode any security that might happen to be in place. It's almost entirely run by below average people scrapped up and recruited from the dregs of third world countries.
BTW, Amazon doesn't know anything about security. Every day I observe examples of people who work there, wittingly or unwittingly, doing things to erode any security that might happen to be in place. It's almost entirely run by below average people scrapped up and recruited from the dregs of third world countries.
I think it's plausible there's a disinformation campaign behind this strange story and that Bloomberg were the eager dupes.
But unnamed sources are known to the reporters and as "senior national security officials" they should be easy to verify and difficult to fake.
My guess is it's a subgroup of one of the agencies running a relatively independent operation to boost distrust of China. A rather inexperienced or at least incompetent group, based on how awkwardly it's gone over.
(Not that I've come to any conclusions... I think there's more info to come on this.)
But unnamed sources are known to the reporters and as "senior national security officials" they should be easy to verify and difficult to fake.
My guess is it's a subgroup of one of the agencies running a relatively independent operation to boost distrust of China. A rather inexperienced or at least incompetent group, based on how awkwardly it's gone over.
(Not that I've come to any conclusions... I think there's more info to come on this.)
No need for that much tinfoil, this came in parts straight from the Pentagon [0] and Bloomberg's "specialist", Tavis Ormandy, turned out to have a vested interest in selling "cyber security" related products aimed at supposedly fixing exactly these kinds of supply chain problems [1].
Imho The Register also points out some interesting details about this whole thing [2]
It's not really that surprising, fits perfectly into Trump's narrative of "They took our manufacturing, it's time to take it back to the US!". Gotta start somewhere, telling everybody China is selling a lot of bad apples seems like a simple enough start.
[0] https://s3.amazonaws.com/static.militarytimes.com/assets/eo-...
[1] https://web.archive.org/web/20170721190725/http://www.sepio....
[2] https://www.theregister.co.uk/2018/10/04/supermicro_bloomber...
Imho The Register also points out some interesting details about this whole thing [2]
It's not really that surprising, fits perfectly into Trump's narrative of "They took our manufacturing, it's time to take it back to the US!". Gotta start somewhere, telling everybody China is selling a lot of bad apples seems like a simple enough start.
[0] https://s3.amazonaws.com/static.militarytimes.com/assets/eo-...
[1] https://web.archive.org/web/20170721190725/http://www.sepio....
[2] https://www.theregister.co.uk/2018/10/04/supermicro_bloomber...
Tavis Ormandy works for Google project zero. Are you saying he has a vested interest?
Do you mean someone else rather than Tavis Ormandy? As someone else has already pointed out, he's at Google Project Zero (which isn't in the business you describe) and I don't think he's ever worked for the company whose brochure you linked to, and so far as I can see he's been pretty rude about the Bloomberg story.
Why would he do this its going to damage china economically and diplomatically.
I feel like this article reflects some significant technical confusion. The BMC is supposed to be on a trusted network inaccessible from the outside. I've always viewed authentication on the BMC as being like the numeric lock on luggage--it's designed to keep honest people honest, not for real security. Being able to bypass the BMC security is really not a big deal. What the Bloomberg article says about the hardware exploit is much worse:
> > The rogue instructions, Bloomberg reported, caused the BMCs to download malicious code from attacker-controlled computers and have it executed by the server’s operating system.
It's using the fact that the BMC has unfettered access to the rest of the machine to compromise the code running on the server itself. That's valuable even if the BMC itself is on a private network inaccessible to the attacker.
> > The rogue instructions, Bloomberg reported, caused the BMCs to download malicious code from attacker-controlled computers and have it executed by the server’s operating system.
It's using the fact that the BMC has unfettered access to the rest of the machine to compromise the code running on the server itself. That's valuable even if the BMC itself is on a private network inaccessible to the attacker.
BMCs like DRAC or iLO are invaluable when you have hundreds or thousands of fresh servers with no OS. The BMC lets you mount an OS or hypervisor ISO in a way reminiscent of DaemonTools et al., and update bios and other firmware from a shared network folder. I'm pretty sure there's even an API to develop against.
There's definitely an API. It's a core part of OpenStack Ironic, which lets you automate bootstrapping them like you described (for example, to put the rest of your OpenStack cloud on top of).
The name is probably a reference to bare metal devices - "Iron-ic", but seems oddly apropos here.
BMC's are great--all my home builds have them because I'm too old to be fiddling around trying to figure out why a computer won't boot an installer from a USB key. But even on my home network the BMC's are on a separate switch on a subnet that doesn't have internet access except through a VPN gateway.
You can bootstrap fresh servers using PXE. The problem with BMC is that it never goes away even after you've booted your system. BMC owns your system and there's no way to completely disable it. Options for disabling it simply control the BMC's software interfaces, and they only work to the extent that the software is bug free. It's like the infamous cPanel, but for hardware--it's a juicy target that you're stuck with.
> a trusted network inaccessible from the outside
There is no such practical network which remains such a network for long. All networks must be assumed to be byzantine as they certainly will be compromised at some point, if they're not already.
There is no such practical network which remains such a network for long. All networks must be assumed to be byzantine as they certainly will be compromised at some point, if they're not already.
I think this is the first time I've seen byzantine used like this - I assume you are referring to the Byzantine Generals problem.
Byzantine is a synonym to "convoluted": https://www.thesaurus.com/browse/byzantine?s=t
Except that in many cases the BMC does not exposed to the internet, especially in situations where you get a dedicated server from somewhere and they want to give you low-level access to make changes to the server you are renting.
I know of at least 2 places where this is still the case (that or a remote IP KVM...).
The BMC should be on a trusted network, but most likely isn't.
I know of at least 2 places where this is still the case (that or a remote IP KVM...).
The BMC should be on a trusted network, but most likely isn't.
> The BMC is supposed to be on a trusted network inaccessible from the outside.
After it left the factory. But can't the firmware be installed by someone while the board is in the testing phase?
After it left the factory. But can't the firmware be installed by someone while the board is in the testing phase?
It's quite incompetent and negligent to put network connectors on servers that cause spectacular failures when exposed to a network.
A valid conclusion might indeed be to stop them being accessible from the outside, by installing such server boards in a network-topologically secure location such as a landfill.
A valid conclusion might indeed be to stop them being accessible from the outside, by installing such server boards in a network-topologically secure location such as a landfill.
It's quite incompetent and negligent to put network connectors on servers that cause spectacular failures when exposed to a network.
This isn't a fair assessment of the situation. Networks that aren't entirely trusted and controlled can cause spectacular failures. By knowing this, administrators can use BMCs safely. My Poweredge server even came with a warning sticker that had to be removed before the DRAC port could be used.
In general, tools can have "pointy parts" with which the user could harm themselves so long as the risks and proper uses are documented and explained adequately.
This isn't a fair assessment of the situation. Networks that aren't entirely trusted and controlled can cause spectacular failures. By knowing this, administrators can use BMCs safely. My Poweredge server even came with a warning sticker that had to be removed before the DRAC port could be used.
In general, tools can have "pointy parts" with which the user could harm themselves so long as the risks and proper uses are documented and explained adequately.
Unfortunately, some servers piggyback the BMC onto one of the regular network ports.
While I don't think Bloomberg's story looks very plausible, perhaps one motivation for cryptic hardware modification at a time when firmware weaknesses were being discovered might be precisely because the easier-to-exploit firmware weaknesses were being discovered, and so might not be exploitable much longer? It might not have seemed plausible that the vulnerabilities would be discovered but then not fixed to the extent that, it turns out, they were not.
I don't really see why everyone is calling this implausible. Modchips have been around for at least 15 years. The idea of the clipper chip is 25 years old. At every hacker conference there are people "hacking" devices by various buses or interfaces.
If there is anything working against the Bloomberg story it is that it is too plausible. Often reality clashes with imagination, but the Bloomberg story contains almost everything you could imagine happening.
If there is anything working against the Bloomberg story it is that it is too plausible. Often reality clashes with imagination, but the Bloomberg story contains almost everything you could imagine happening.
Exactly.
How much has the US spent on the F-35? How much has China spent on making artificial islands? Yet engineering a chip and bribing/threatening a few factory workers is beyond the pale?
How much has the US spent on the F-35? How much has China spent on making artificial islands? Yet engineering a chip and bribing/threatening a few factory workers is beyond the pale?
[deleted]
Bloomberg's claim is that a miniature device used for RF analog electronics was coopted and inserted into a board that would never have such a part designed in. This requires modifying the board artwork, the pick and place config, any automated inspection and test equipment, and adding a foreign part reel to the supply chain.
It is much easier to compromise firmware directly or modify ICs that are already part of the design. The risk of being caught is much lower and it would be stupid to attempt anything more elaborate.
It is much easier to compromise firmware directly or modify ICs that are already part of the design. The risk of being caught is much lower and it would be stupid to attempt anything more elaborate.
This requires [et c.]
Think that's impossible? Not at the nation-state level. Not in communist countries where everything is property of the government by default. Not in capitalist countries like the United States, where entire nuclear facilities are replicated in secret. [0]
[0] https://www.businessinsider.com/the-us-built-a-secret-replic...
Not in capitalist countries like the United States where you can just contract a manufacturer to produce the board you want. Even parts acquisition becomes a job to be done. As long as the producer dosn't know (or even does know but can be silenced at the right level) then really, once the actual design is in hand and assuming the parts aren't too hard to get there's little to stop someone from producing a board just like a board produced elsewhere.
It isn't implausible because of it being difficult and expensive, its implausible because there already exist much easier, cheaper, and (arguably) harder to detect ways of subverting SuperMicro motherboards.
As a bonus, subverting the BMC firmware is much harder to trace to the source since it could be injected by in so many ways by so many different people.
Why use a thermonuclear device when a hand grenade accomplishes the goal?
As a bonus, subverting the BMC firmware is much harder to trace to the source since it could be injected by in so many ways by so many different people.
Why use a thermonuclear device when a hand grenade accomplishes the goal?
Great question. Better yet why not have both and use whichever one suits you the best at the time?
I just don't think the relationship between those two things you are describing exists. If the Chinese government approaches a Chinese manufacturer with the goal of compromising US software companies adding some sort of chip that reconfigured the hardware would be the most straight forward thing for them to do.
If anything I think the idea that a Chinese manufacturer with complete access to the hardware having to execute some exploit towards the web interface to get access is far fetched. So is that you could pretend to update the firmware (surely no one is going to notice that the new version doesn't have the features you wanted?) and that dumping the firmware would be inconvenient (it would be the first thing you did if you suspected something).
If anything I think the idea that a Chinese manufacturer with complete access to the hardware having to execute some exploit towards the web interface to get access is far fetched. So is that you could pretend to update the firmware (surely no one is going to notice that the new version doesn't have the features you wanted?) and that dumping the firmware would be inconvenient (it would be the first thing you did if you suspected something).
The "chip that reconfigured the hardware" is already built in; it's the BMC.
All the Chinese government has to do is go to the factory and tell them "flash the BMC firmware with this image" where the image is subverted (but operationally indistinguishable) BMC firmware. It doesn't get much more straight forward than that.
All the Chinese government has to do is go to the factory and tell them "flash the BMC firmware with this image" where the image is subverted (but operationally indistinguishable) BMC firmware. It doesn't get much more straight forward than that.
There are attacks where flashing a malicious firmware on to the device prevents real firmware flashing (just updates version numbers, re-infects the flashing payload on write, etc). However, those attacks can be mitigated by physically connecting to the flash module and writing to the device directly through SPI. If you've got a chip between the BMC and the flash memory as the report suggests, it can re-infect the memory even when you're done. You could even read the contents of the flash memory directly and find no evidence of the attacker, as the attack code might never actually write to the memory and may only load when the BMC boots and attempts to read from the flash memory.
It is straight forward to compromise the BMC, it isn't straight forward to hide a backdoor in the BMC in front of some of the best security researchers in the world. Especially with such attack being well known and seemingly trivial to check for.
the very arguments the article gives to shun off this attack is what i think makes it very possible and the best option. Scale.
NSA demand backdoor on CPUs. other States figure out how the backdoor works and how access to it is allowed on the silicon. Instead of attacking ever changing firmware and whatnot, just develop something that will work on that authentication component of the always-present backdoor. The backdoor interface won't change so often as it is dictated by the NSA and likely designed by a committee.
Done. Now the economies of scale allow you to just place that one component, which will work all over the place, for a very low price/complexity (all you really have to do is to place it in the input signal for the CPU and all it have to do is to filter a very specific pattern. the rest is just visual and camouflage).
This also gives you the benefit of not having to work a payload for your attack depending on capabilities. You will always have the same capabilities. It makes perfect sense. And makes it extremely cheap!
NSA demand backdoor on CPUs. other States figure out how the backdoor works and how access to it is allowed on the silicon. Instead of attacking ever changing firmware and whatnot, just develop something that will work on that authentication component of the always-present backdoor. The backdoor interface won't change so often as it is dictated by the NSA and likely designed by a committee.
Done. Now the economies of scale allow you to just place that one component, which will work all over the place, for a very low price/complexity (all you really have to do is to place it in the input signal for the CPU and all it have to do is to filter a very specific pattern. the rest is just visual and camouflage).
This also gives you the benefit of not having to work a payload for your attack depending on capabilities. You will always have the same capabilities. It makes perfect sense. And makes it extremely cheap!
> Often reality clashes with imagination
Often reality follows [somebody's] imagination - i mean you have those think tanks where people sit and imagine things, and the sponsoring agencies like CIA/Pentagon/NSA or their foreign equivalents take many of that and implement. Many people everywhere had the thought of full remote control of the computers - Intel implemented it as Intel ME feature of CPU because Intel controls CPU. China controls motherboards, so they did on the motherboards.
Often reality follows [somebody's] imagination - i mean you have those think tanks where people sit and imagine things, and the sponsoring agencies like CIA/Pentagon/NSA or their foreign equivalents take many of that and implement. Many people everywhere had the thought of full remote control of the computers - Intel implemented it as Intel ME feature of CPU because Intel controls CPU. China controls motherboards, so they did on the motherboards.
“There are so many far easier ways to do the same job. It makes no sense—from a capability, cost, complexity, reliability, repudiability perspective—to do it as described in the article.”
Considering the US went to the trouble of wiring the North Atlantic for sound to catch Russian submarines during the cold war, and tapped undersea cables using divers and submarines, this is so implausible for a nation state? Large state actors specialize in activities for national defense that make "no sense—from a capability, cost, complexity, reliability, repudiability[sic] perspective".
Considering the US went to the trouble of wiring the North Atlantic for sound to catch Russian submarines during the cold war, and tapped undersea cables using divers and submarines, this is so implausible for a nation state? Large state actors specialize in activities for national defense that make "no sense—from a capability, cost, complexity, reliability, repudiability[sic] perspective".
There are even more recent examples with software: Stuxnet
> a binary file that stored administrator passwords in plaintext.
I understand what they mean, but that sentence still hurts to read.
I understand what they mean, but that sentence still hurts to read.
>Supermicro boards were so bug ridden, why would hackers ever need implants?
Ummm, because if you need your hack to be reliable, you can't rely on someone else's bugs to be there when you need them. You never know when they'll be fixed, or just replaced by new bugs.
A long time ago when setting up computers and networks was driver version hell, we had a short list of manufacturers' computers that we'd do setup included in the price instead of on-the-clock. This came about when a shipment of about 20 Dell computers, all supposedly of the exact same model# and revision, required about about 11 different setups, because the various chips on the board were different. They were clearly just using the chip-of-the-week>from whatever supplier was cheapest -- great for their price points, but every variant required a different driver for some subsystem. So the list was created and Dell was not on it (it was IBM, Compaq, HP, DEC, to show when this was).
That's solved now by hiding it with the much more automated OS and networking setups, but it is easy to see how the Chinese spies would be in the same situation -- some buggy boards are wonderfully exploitable, but how do you tell that the version going to your target wasn't changed by some revision that wasn't even noted in the Rev- listings? Better to insert your own bug if you want to actually get the job done.
Ummm, because if you need your hack to be reliable, you can't rely on someone else's bugs to be there when you need them. You never know when they'll be fixed, or just replaced by new bugs.
A long time ago when setting up computers and networks was driver version hell, we had a short list of manufacturers' computers that we'd do setup included in the price instead of on-the-clock. This came about when a shipment of about 20 Dell computers, all supposedly of the exact same model# and revision, required about about 11 different setups, because the various chips on the board were different. They were clearly just using the chip-of-the-week>from whatever supplier was cheapest -- great for their price points, but every variant required a different driver for some subsystem. So the list was created and Dell was not on it (it was IBM, Compaq, HP, DEC, to show when this was).
That's solved now by hiding it with the much more automated OS and networking setups, but it is easy to see how the Chinese spies would be in the same situation -- some buggy boards are wonderfully exploitable, but how do you tell that the version going to your target wasn't changed by some revision that wasn't even noted in the Rev- listings? Better to insert your own bug if you want to actually get the job done.
It depends on what you want to do. If you want to extract information from a specific network. maybe custom firmware is a good option.
If you want to just disable a very large number of machines to create economic damage or cripple infrastructure, a hardware implant would do just fine. And you wouldn't need to be very careful as to where it ends - if you make enough of them, they'll be everywhere.
If 1% of all MacBooks have a similar backdoor, there are about a dozen at my building.
If you want to just disable a very large number of machines to create economic damage or cripple infrastructure, a hardware implant would do just fine. And you wouldn't need to be very careful as to where it ends - if you make enough of them, they'll be everywhere.
If 1% of all MacBooks have a similar backdoor, there are about a dozen at my building.
If Supermicro boards are bug-ridden, then I'd expect other manufacturer's boards to be equally bad or worse. I don't have a reason to defend Supermicro or some such, but where else in retail do you get specialized server boards like Supermicro sells? When Opteron was relatively new in 2004, I bought a two-socket board from Supermicro as the alternatives from well-known Taiwan manufacturers (ASUS, MSI, etc.) weren't as sophisticated (hadn't the PSUs and PSU connectors, power ratings, and rack-mount/tower convertible enclosures).
One researcher criticizes this type of hardware attack, saying:
Once discovered, such an attack would be burned for every affected board as people would replace them.
But this article also points out a case where, even after SuperMicro had published a patch to a serious BMC firmware vulnerability, 32,000 servers in the wild had not been updated a year later.
So, if software updates aren't always speedily/reliably deployed in the wild by customers, can we really expect hardware to be speedily replaced?
Once discovered, such an attack would be burned for every affected board as people would replace them.
But this article also points out a case where, even after SuperMicro had published a patch to a serious BMC firmware vulnerability, 32,000 servers in the wild had not been updated a year later.
So, if software updates aren't always speedily/reliably deployed in the wild by customers, can we really expect hardware to be speedily replaced?
The purpose of this whole thing was to manipulate the market. Super Micro stock fell 50% and still has not recovered since October 4th. Before the report its trading volume was invisible. After the report the volume experienced almost 2 orders of magnitude increase.
Okay, crazier lead-foil hat time: what if this story is a crappy hoax intended to discredit/prevent from publication a real story with similar details?
I don't follow. If anything it makes the parallel story easier to publish as a sort of "me too" (no disrespect.)
Maybe it takes away from the firmware hacking version of the story because now folks are looking at components as being the source of hacks and not the firmware on the components, leading to a false sense of security when they invest mightily in analyzing components with X-rays? I could see that outcome as being plausible. If the ultimate outcome is simply to change corporate priority towards futile component verification and away from firmware verification then indeed the firmware verification vector remains safe for the attacker.
Maybe it takes away from the firmware hacking version of the story because now folks are looking at components as being the source of hacks and not the firmware on the components, leading to a false sense of security when they invest mightily in analyzing components with X-rays? I could see that outcome as being plausible. If the ultimate outcome is simply to change corporate priority towards futile component verification and away from firmware verification then indeed the firmware verification vector remains safe for the attacker.
More like "Oh look, another story about extra components inserted by a big state actor. Bloomberg just got burned for this, I'm not going to risk my/my organization's reputation on the slight chance that this one is real"
Or, "Extra chips on the motherboard? You're about a month behind the news cycle and didn't you hear it was all BS anyway"
But the false sense of security interpretation is plausible too.
I wonder who holds conferences on the cutting edge research of manipulating media
Or, "Extra chips on the motherboard? You're about a month behind the news cycle and didn't you hear it was all BS anyway"
But the false sense of security interpretation is plausible too.
I wonder who holds conferences on the cutting edge research of manipulating media
[deleted]
Very fair article. Raises doubt in a very productive way, not the he-said she-said of previous rebuttals.
I'd go further to say it isn't just about the accuracy of the bloomberg piece, but implies bad things about their journalistic integrity. I mean, get real, Ars doesn't have an investigative journalism team. The one-sidedness of the bloomberg article becomes very apparent.
I'd go further to say it isn't just about the accuracy of the bloomberg piece, but implies bad things about their journalistic integrity. I mean, get real, Ars doesn't have an investigative journalism team. The one-sidedness of the bloomberg article becomes very apparent.
Not saying I believe in one side or the other, but from a standpoint of avoiding detection I think firmware hacking goes out the window.
A deep-pocketed attacker isn't going to risk flashing the firmware with a non-oem one on a brand new board leaving the factory. That probably gets quality inspected somehow later on anyway whereas a visual inspection is just a rubber stamp (IE: OK if the box isn't crushed or wet).
Not to mention a customer in the field who experiences problems is likely to report their firmware version to Supermicro support, whose poking around could expose the entire project.
There was an article recently about how hardware is "magic" and the IT world mostly takes it for granted. Putting an extra chip on the board but making it completely transparent to software debugging techniques is the best way to go. The board is almost certainly going to be flashed at least once and probably audited several times in it's lifespan by IT, but the hardware is never going to get more than some compressed air blown on it. Nobody repairs these things at the component level on a scale that matches how frequently firmware gets flashed or checked out.
A deep-pocketed attacker isn't going to risk flashing the firmware with a non-oem one on a brand new board leaving the factory. That probably gets quality inspected somehow later on anyway whereas a visual inspection is just a rubber stamp (IE: OK if the box isn't crushed or wet).
Not to mention a customer in the field who experiences problems is likely to report their firmware version to Supermicro support, whose poking around could expose the entire project.
There was an article recently about how hardware is "magic" and the IT world mostly takes it for granted. Putting an extra chip on the board but making it completely transparent to software debugging techniques is the best way to go. The board is almost certainly going to be flashed at least once and probably audited several times in it's lifespan by IT, but the hardware is never going to get more than some compressed air blown on it. Nobody repairs these things at the component level on a scale that matches how frequently firmware gets flashed or checked out.
Maybe for smaller companies, but Apple is very paranoid and AIUI does indeed inspect the hardware to make sure it hasn't been tampered with. I know less about Amazon in this regard but I would expect Amazon to do at least some level of hardware inspection to detect tampering as well.
Forgive my ignorance, but what hardware does Amazon sell?
We're talking about server hardware used by Amazon and Apple, not what they sell.
They also do extensive code reviews, including of imported open source, yet their software is hardly bug free. Bugs can linger for years, often fixed only because someone stumbled upon odd behavior.
Spotting a tiny chip sitting on the SPI bus that looks identical to a bunch of other chips? That doesn't do anything unless it's tickled in just the right way? If you believe Amazon and Apple are even remotely capable of protecting against that....
The solution to these problems is to put critical code and critical secrets on discrete, simple SoCs where you actually have a chance of defending both hardware and software attacks. Apple and Amazon understand this because they already do it. The difficulty is building your software systems (firmware, kernel, etc) to make use of these secure elements, not to mention making them available for ad hoc application software. It's an extremely difficult integration problem, and even when you succeed you haven't.
For example, AFAIU Amazon's servers have secure elements to perform attestation of the box; it's utilized by their hypervisors to authenticate VMs for things like KMS. But it can't actually protect the data in the VM itself, such as the secrets obtained by dint of the attestation. It can't even prevent taking control of the hypervisor. All it does is help Amazon define a fixed security parameter--that you can't impersonate their hardware nodes on the network. That's extremely useful, but ultimately extremely limited.
Spotting a tiny chip sitting on the SPI bus that looks identical to a bunch of other chips? That doesn't do anything unless it's tickled in just the right way? If you believe Amazon and Apple are even remotely capable of protecting against that....
The solution to these problems is to put critical code and critical secrets on discrete, simple SoCs where you actually have a chance of defending both hardware and software attacks. Apple and Amazon understand this because they already do it. The difficulty is building your software systems (firmware, kernel, etc) to make use of these secure elements, not to mention making them available for ad hoc application software. It's an extremely difficult integration problem, and even when you succeed you haven't.
For example, AFAIU Amazon's servers have secure elements to perform attestation of the box; it's utilized by their hypervisors to authenticate VMs for things like KMS. But it can't actually protect the data in the VM itself, such as the secrets obtained by dint of the attestation. It can't even prevent taking control of the hypervisor. All it does is help Amazon define a fixed security parameter--that you can't impersonate their hardware nodes on the network. That's extremely useful, but ultimately extremely limited.
Code reviews for bugs is very different than security reviews to look for malicious tampering. Apple may have bugs that linger for years, but I'm not aware of any documented case of someone managing to slip a backdoor into Apple software via an open source package.
> Spotting a tiny chip sitting on the SPI bus that looks identical to a bunch of other chips? That doesn't do anything unless it's tickled in just the right way? If you believe Amazon and Apple are even remotely capable of protecting against that....
Why not? X-raying every board, inspecting every single component, making sure it matches up with the documented specs and perhaps with a proven-good board... if you're replacing a component with a different one, or adding a component that wasn't there before (which is the case in this alleged attack), even if the component looks harmless and even if it's tiny, it can still be revealed by a detailed comparison of the board against specs. A component that's the size of a grain of rice is still a component that can be detected.
> Spotting a tiny chip sitting on the SPI bus that looks identical to a bunch of other chips? That doesn't do anything unless it's tickled in just the right way? If you believe Amazon and Apple are even remotely capable of protecting against that....
Why not? X-raying every board, inspecting every single component, making sure it matches up with the documented specs and perhaps with a proven-good board... if you're replacing a component with a different one, or adding a component that wasn't there before (which is the case in this alleged attack), even if the component looks harmless and even if it's tiny, it can still be revealed by a detailed comparison of the board against specs. A component that's the size of a grain of rice is still a component that can be detected.
So are you saying that they x-ray every board now?
BMC bug story time: I was working on automating health checks, and I needed some information from a BMC. The information was provided in XML format... fixed width. It's like something produced the document, and then output it to console, then copied from console to web service output.
While it's ultimately going to help to shame vendors regarding their poor security practices, it's really irritating and unfortunate this is all being framed as a Supermicro issue. How about the other companies in the same market space, like Tyan, that I'm sure are no better? For that matter how about the "Tier 1" OEMs like Dell and HP - how well-written are their BMC firmwares?