Leak of MSI UEFI Signing Keys Stokes Fears of 'Doomsday' Supply Chain Attack (arstechnica.com) 62
A ransomware intrusion on hardware manufacturer Micro-Star International, better known as MSI, is stoking concerns of devastating supply chain attacks that could inject malicious updates that have been signed with company signing keys that are trusted by a huge base of end-user devices, a researcher said. From a report: "It's kind of like a doomsday scenario where it's very hard to update the devices simultaneously, and they stay for a while not up to date and will use the old key for authentication," Alex Matrosov, CEO, head of research, and founder of security firm Binarly, said in an interview. "It's very hard to solve, and I don't think MSI has any backup solution to actually block the leaked keys."
The intrusion came to light in April when, as first reported by Bleeping Computer, the extortion portal of the Money Message ransomware group listed MSI as a new victim and published screenshots purporting to show folders containing private encryption keys, source code, and other data. A day later, MSI issued a terse advisory saying that it had "suffered a cyberattack on part of its information systems." The advisory urged customers to get updates from the MSI website only. It made no mention of leaked keys. Since then, Matrosov has analyzed data that was released on the Money Message site on the dark web. To his alarm, included in the trove were two private encryption keys. The first is the signing key that digitally signs MSI firmware updates to cryptographically prove that they are legitimate ones from MSI rather than a malicious impostor from a threat actor. This raises the possibility that the leaked key could push out updates that would infect a computer's most nether regions without triggering a warning. To make matters worse, Matrosov said, MSI doesn't have an automated patching process the way Dell, HP, and many larger hardware makers do. Consequently, MSI doesn't provide the same kind of key revocation capabilities.
The intrusion came to light in April when, as first reported by Bleeping Computer, the extortion portal of the Money Message ransomware group listed MSI as a new victim and published screenshots purporting to show folders containing private encryption keys, source code, and other data. A day later, MSI issued a terse advisory saying that it had "suffered a cyberattack on part of its information systems." The advisory urged customers to get updates from the MSI website only. It made no mention of leaked keys. Since then, Matrosov has analyzed data that was released on the Money Message site on the dark web. To his alarm, included in the trove were two private encryption keys. The first is the signing key that digitally signs MSI firmware updates to cryptographically prove that they are legitimate ones from MSI rather than a malicious impostor from a threat actor. This raises the possibility that the leaked key could push out updates that would infect a computer's most nether regions without triggering a warning. To make matters worse, Matrosov said, MSI doesn't have an automated patching process the way Dell, HP, and many larger hardware makers do. Consequently, MSI doesn't provide the same kind of key revocation capabilities.
from Trusted Build Agents (TBA) (Score:2)
Painting yourself into a corner (Score:4, Insightful)
Well, it's wintendo and friends that came up with the scheme. Which always was about control ("trusted computing") over and not "security" for the end user. Despite the stories that sold it to us^W^W^W^Wwere supposed to soothe (some privacy activists and the few tech-savvy) "consumer" protests while the entire industry switched over.
But if you willingly participate with this control thievery charade then you do have to shoulder the burden to keep the keys to the wintendo "ecosystem" kingdom safe. And if you don't, you put everyone at risk.
Everyone? No, not really. Those who are savvy enough to replace the keys AND re-sign all the OS bootloading in their use with their own keys might be safe. But everyone else is pretty much fucked and at risk.
That it would happen eventually was pretty much a given. And yet, the set-up was wilfully implemented across the entire industry. Good show, good show, dear actors.
Re: (Score:2)
The issue is the (ab|mis)use of the word "security". Security comes in a lot of forms. Network security, OS integrity, ability to be restored to a known state (i.e. resistance to being bricked.). What is going on is that companies like MS, Sony, Apple, and Samsung have focused extensively on "security" in terms of jailbreak resistance, spending a ton to keep the user from accessing their device fully. To them, if you follow the money, anti-piracy is more important than keeping data protected from ransom
Re: (Score:3)
Re: (Score:2)
You have to understand that there are different certificates for different uses. The signed binaries that malware uses are only signed with basic software or driver signing certs. Anyone can buy those with minimal checks. Microsoft really should clamp down on lax certificate authorities, but at least it creates cost for the malware authors and makes revoking the cert for their software relatively easy. The issue is the lack of proper checks, not that the keys were stolen.
The issue being discussed here is mu
Re: (Score:2)
Re: (Score:2)
To be fair, a Microsoft signature makes a signed statement of "This POS is probably not very secure and may well be not secure at all".
Re: (Score:2)
Indeed. Compare it with Linux kernel source signing though: You have a PGP signature, signature is checked manually or via your own script, keys have a lifetime and in case of compromise can be user-replaced.
The way this thing here is done is to make things as hard as possible for users and clearly mainly serve to prevent users from having more control over their systems.We are lucky the Linux markt is apparently large enough so they could not get away with leaving out the possibility to put in your own key
Pretty much bullshit (Score:2, Informative)
If you are minimally careful, you download updates from the manufacturers site and not just from anywhere. Hence no "doomsday" here. An awful lot of hyperbole is though.
Re: (Score:3)
Re: (Score:2)
And how does the driver get in there? Right....
Driver signing and executable signing is nice, but it is not that critical. If it is compromised, the attacker still needs to compromise the delivery path. So sure, this must be fixed, but calling it a "doomsday" scenario is just clueless hyperbole.
Re: (Score:2)
Re: (Score:2)
And how would a website or wireless bug install a _driver_?
Re: (Score:2)
Re: (Score:2)
You mean like hacking the vendor's network? Like they did to MSI when they stole the keys in the first place? UNPOSSIBLE!
Re: (Score:2)
Stop panicking and start to think. As long as MSI systems are compromised, an attacker can create any type of valid, signed compromised code anyways. Leaked keys do not make the situation one bit worse. And you can be sure they fixed their systems now.
Re: (Score:2)
As long as MSI systems are compromised, an attacker can create any type of valid, signed compromised code anyways.
Sure, that's true for MSI, but what's Microsoft's excuse?
Re: (Score:2)
As long as MSI systems are compromised, an attacker can create any type of valid, signed compromised code anyways.
Sure, that's true for MSI, but what's Microsoft's excuse?
a) We do not need a stinking excuse! People _love_ our stuff! Look at all those that defend us and know that we have the _best_ OS and software!
b) Incompetence, arrogance and greed. The usual when people do a ton of damage to society.
Re: (Score:2)
You're contradicting yourself. You claimed the lost keys were no problem because the delivery path would also need to be compromised. I pointed out that the delivery path was compromised and suddenly I'm panicking?
Re: (Score:2)
Careful now, you don't want to be accused of panicking!
Re: (Score:2)
The delivery path does not need to be compromised when the coding and built-path is compromised. Your argument is simply irrelevant. Incidentally, I never said this was "not a problem". I said the term "doomsday supply attack" was vastly overstating the risks. This is a problem, it needs to be fixed, it is difficult to fix, but the sky is not falling and some simple security practices nicely mitigate the issue in the meantime. Also, MSI needs to make sure their systems do not get compromised again. But they
Re: (Score:2)
Sure, some stupid people may still download MSI drivers or BIOS images from just anywhere and they can get hit. But let us be real here, people _this_ dumb will get hit anyways and current tech cannot protect them.
Except they may do so relying on the digital signatures to 'prove' authenticity. Had the keys been properly secured they would do so. Unfortunately, the signature provides only false assurance now and there is no revocation mechanism.
Re:Pretty much bullshit (Score:4, Informative)
Except someone could maliciously use the signed driver to create malware that can masquerade as an MSI driver on anyone's computer. And then you have access to everything (I think)
You could get access to anything as some types of chipset driver, but it would be detectable, because you would have to ask for it. An IOMMU now prevents even hardware from reading into memory that doesn't belong to it e.g. via DMA (which was the big security problem with Firewire, before we all got IOMMUs.)
Re: (Score:3)
Indeed. The only thing that could happen is somebody downloading driver or executable from a shady place, starting it and thinking "Oh it has an MSI signature! It must be safe to use!" And that only works if it is not in the AV malware signatures.
People seem to be unaware that for the longest time, drivers were not signed at all and so were executables and that you still have to do something pretty stupid to get infected even then.
Re:Pretty much bullshit (Score:5, Interesting)
Security is only good if it's not so limiting lots of people turn it off. The current level of driver security gets by only by virtue of few people doing hobby driver development or needing drivers for old hardware that aren't signed. Though the game cheats community is a little bigger... they're in an arms race that's reached kernel mode cheat drivers vs kernel mode anticheat drivers. Ironically, a byproduct of this is tons of great information about driver development, something that has very, very little in the way of free learning resources.
Re: (Score:2)
Indeed. Security that stands in your way and forces you to do unsafe things to make that stop (like tuning off _all_ driver security, how stupid is that?) is worse than useless. It endangers users. Something any good security expert knows, but apparently Microsoft does not have any of those.
Re: (Score:2)
Yes, as long as the vendor's security is good enough to assure that their systems don't get compromised...UH OH!
Re: (Score:2)
Code signatures do not protect you against manufacturer systems being compromised and are not intended to. Code signatures only secure the deliver path. Hence you have to rely on MSI having fixed their system security issues, including development systems, file storage, build system and web-server and some others anyways. And at this time you can be pretty sure they have done that.
Re: (Score:2)
But now the keys are out there and as TFA pointed out, MSI doesn't have much in the way of a revocation system, so the protection is gone.
It seems we would have been better off with physical jumper security that the signing was supposed to make unnecessary.
Re: (Score:2)
No. Any compromised drivers or BIOS images still need to somehow get into your system. If you are somewhat careful they will not be able to do that.
Incidentally, "physical jumper security" was always rare. Most mainboards never had that jumper. Which is a pity, because it is a really great protection mechanism with no software-based attack path.
Re: (Score:2)
That keeps MY BIOS safe, and I'll guess yours too, but what of the others? Some people are convinced that they must install any vendor update. That includes some corporate environments.
UEFI security was always a terrible idea (Score:5, Insightful)
Where is the ownership? I am not seeing it.
I am the owner, I should have full and absolute control over whatever I buy.
Re: (Score:2)
Re: (Score:2)
Why did you buy something that doesn't let you turn off secure boot?
I did not.
The control you should have shown was choosing hardware that doesn't paint you into a corner.
What I mean is I should also have control over what are the "Factory keys" from the top of key hierarchy. I should be able to add and remove keys and certificates as I please.
If I brick my device because of it, I can and will only blame myself. This is the right way.
Re: (Score:2)
That would be cheaper for every manufacturer - abdicate responsibility for all security, push the requirement downstream, and appreciate the SEP field you've erected.
Re: (Score:2)
Well, things like BIOS updates are signed nowadays for obvious reasons - you don't want malware to install a its own version of the BIOS. Likewise, processor microcode updates are also signed for the same reason.
But if you really want freedom, there you go. MSI keys were leaked, so get a MSI motherboard
Re: (Score:2)
> you'll have freedom to run whatever the heck you want.
until the caps pop
Re: (Score:2)
Well, things like BIOS updates are signed nowadays for obvious reasons - you don't want malware to install a its own version of the BIOS. Likewise, processor microcode updates are also signed for the same reason.
My point is I should the one to control the signing keys.
If I want to throw out the factory keys and install my own - that should be just fine.
Of course, not from the operating system level - but perhaps from boot level or bios setup level.
Re: (Score:2)
Both are not really a thing and more theoretical possibilities. Malware that has gotten this level of access can typically do what it wants anyways, why do a diffifult BIOS patch or an even more difficult microcode patch?
Re: (Score:2)
You are free to load your own firmware on MSI boards. They don't stop you doing it.
These keys are used for Secure Boot. If you don't use Secure Boot, or if you generate your own Secure Boot keys and sign your Linux bootloader with them, you have absolute control.
Well, at least as much control as you can have with binary blob firmware for your CPU and GPU.
The concern here is that normally if malware replaced or modified the UEFI firmware, Secure Boot would notice and warn the user that their system was compr
ââIt (Score:1)
I remember when you had to put a jumper... (Score:3, Informative)
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
They could have at the least a hardware switch on the casing which you have to press physically to enable a bios / uefi update.
No doubt it will be for consumer systems only, as doing that for an org that has 100s of 10000s of systems will make it a pain for them to update everything.
You can assume all those orgs buying the "business class" gear will have inhouse IT to handle security issues, whereas consumers will benefit from having a hardware switch (jumpers are too complex for the average consumer) to in
Re: (Score:2)
I remember when computers had ROMs. I don't recall ever bricking one of those machines.
The correct way to boot a PC is to have a ROM for the initial startup, verification, and flashing, and EEPROMs for the stuff that can be updated. But, no, that costs more money... I mean, puts you at risk.
Does this mean you can write/mod MSI firmware? (Score:3)
If this means users can do things with their computers that they were previously unable to do, then I'd call this a mixed blessing/curse.
Re:Does this mean you can write/mod MSI firmware? (Score:5, Interesting)
If this means users can do things with their computers that they were previously unable to do, then I'd call this a mixed blessing/curse.
Came to post something like this, the FP beat me to it, and no further comment on the subject? Egad!
Perhaps we are about to embark on a (perhaps short) era where we can install open firmware on years of production of already-out-there devices. And also easily extract the firmware backdoors for analysis.
Lets see if we can get any of that done before the malware storm crashes nearly everything.
"A computer's most nether regions"? (Score:2)
"This raises the possibility that the leaked key could push out updates that would infect a computer's most nether regions without triggering a warning."
revoked certs (Score:1)
Isn't this the whole reason we have a list of revoked certs?
If they get revoked all old "good" things signed with those certs need to be resigned and posted, but suck it up buttercup. It needs to be done.
Otherwise there's no trust in anything.
Re: (Score:2)
In practice, certificate revocation does not really work well. MSI will have to very carefully generate updates for all affected parts with new public keys and then, in a 2nd step some time later, disable the old public keys. If they mess up, they may create a support nightmare.
Re: (Score:2)
Re: (Score:2)
Hehehe, nice! I just gave my CS students a nice lecture on how broken the certificate system and, in particular, certificate revocation is (always gets a lot of good laughs and some incredulity), but the term "revocation drops from the sky" will make a nice addition for next year.
Re: (Score:2)
Re: (Score:2)
Wisdom in the form of shared jokes is always good ;-)
Outlaw Cryptocurrency, Starve Ransomware (Score:2)
It's just as simple as that.
C'mon Legislators, c'mon World Banks, you can do it!
If you can tell me what Charging Plug I have on my Phone, you can stop Cryptocurrency!
Without it, Ransomware no longer can be profitable enough to be worth it.
No problem. (Score:2)
My last m/b was an MSI. I will NOT BUY them ever again.
The random, sometimes once every two weeks, at the end, several times A DAY crashes down to physical reboot were more than enough fro me.