7 ms·

MoonBounce: The dark side of UEFI firmware

139 points by curmudgeon22 5y ago

ddtaylor 5y ago
I notice the writeup only mentions Windows? Do they attack any Linux hosts?
greenbit 5y ago
If we just had flash that was write protected unless a jumper was moved, this kind of thing just would not happen. "Oh, but the average user is incapable of that" and "Corporate IT are unwilling to do that" are the two biggest excuses I hear to not make it so. Here's a crazy idea: you connect said jumper to a front panel key switch. The 'average' consumer could probably sort that out. And corporate IT could just leave it enabled, or require you to turn the key for them, or have IT interns on site that run around with the keys or whatever. A Key. A literal physical key. But I guess that's too low tech for the crypto obsessed purveyors of TPMs and the like.
- 2OEH8eoCRo0 5y ago
  I don't understand this either. A physical presence requirement eliminates all remote threats. The vast majority of these attacks occur from the safety of some far away adversarial country. They'd have to have agents on the ground carrying out these attacks and getting caught.
- snthd 5y ago
  If you turn the key, how do you really know it's your firmware that's being written?
  - greenbit 5y ago
    Point is, if you Don't turn the key, you sleep well at night knowing it's Not Being Written. Contrary to the apparent belief of the developers of New Products, a good many of us are sick to death of everything "as a service", and all the headaches that ensue.
    - AshamedCaptain 5y ago
      I am sure one of these "New Products" developers will come here and share the story of the Evil Hotel Maid that comes to your room and toggles the physical switch on your computing products.
      - rzwitserloot 5y ago
        Anybody that peddles you an absolute safety in IT security is an idiot who should be swiftly ignored. If they work for you, fired and all their work thoroughly reviewed. The flip side of that argument is just as true: Anybody that denigrates a security measure because they can come up with a single convoluted compromise is an idiot. I'm hoping that's not you, it sounds like you're saying that some hypothetical strawman developer would say such a thing (Sounds like a particularly plausible strawman to me... a sad state of affairs!) – but that's the defense if you meet such dangerous idiots. With this proposal, there's a key involved, which is some extremely limited defense against evil maids. If it's truly a key as in 'keys in doors', you can pick it, trivially (see Lockpicking Lawyer's video stream for how trivial it is to pick or otherwise circumvent locks). A well thought through system can fix many of these warts - in this case all you need is an unresettable flag that shows: Compromised! Designing a lock that can detect but not defend against picking is a lot easier than making an unpickable lock. But I'm sure LPL or somebody else with skills, experience, lots of time, and a budget to buy a bunch and open em up to look at how they work can come up with a scheme to pick em open without triggering the flag. You could also make it a digital key (or a combination even). Point is, pre-supposing a well-tested design with input from experts is mostly just begging the question: If I had that, we might as well posit 'Let us assume no bugs in any firmware implementations of stuff'. And for an encore, let's posit "world peace", about as useful. It's all swiss cheese: _EVERYTHING_ has holes. Nothing is perfect. But, layer enough slices of swiss cheese on a slice of bread and pretty soon no bread is visible. A physical key rather obviously covers precisely those holes that schemes involving entirely digital and remote-accessible setups have. Thus it is a great idea, and the fact that an evil maid can attack it indicates someone either doesn't understand the fundamentals of security (they don't get that it's all imperfect, and combining to cover the gaps is almost always the winning move), or is intentionally coming up with pithy oversimplified toss to cheerlead their product or pet preference.
- mjg59 5y ago
  Flash needs to be writable at runtime - things like ram training parameters are stored there.
  - zbentley 5y ago
    Parameters could be stored in separate memory from the operating system that interprets those parameters. This is somewhat similar to what Apple does with the secure enclave. That way, wearout parameters and non-risky user tunables would still be customizable without risk of compromise. Heck, even if that had to be implemented with an entirely separate hardware chip for parameter storage on the motherboard, the added cost would be negligible.
- axiolite 5y ago
  > If we just had flash that was write protected unless a jumper was moved, this kind of thing just would not happen. This would make it incredibly hard to manage a bunch of servers in various remote data centers. > connect said jumper to a front panel key switch Ah yes, I do miss the good old days of front-panel key switches, where rubbing your feet and touching the front would reboot your system. I've never seen a smartphone or ultrabook with one, though.
woliveirajr 5y ago
> Note that at the time of writing we lack sufficient evidence to retrace how the UEFI firmware was infected in the first place. The infection itself, however, is assumed to have occurred remotely. And given that it's done on memory (flash, that'll persist over reboots, windows reinstall and even hdd and sdd replacement), it wasn't done by trivial scriptkids. Expect more tpm-like things "to protect you".
- caaqil 5y ago
  > it wasn't done by trivial scriptkids. I mean that's pretty obvious given that we're talking about APT41.
- bitwize 5y ago
  Things like this are why we need a verified boot chain.
  - foxfluff 5y ago
    Call me old fashioned but I'd prefer to just make it impossible to write the firmware without physical access. Verification just brings it's own issues and is not a panacea. Who owns the key(s)? If not you, how do you trust them? If you, how do you write them? How do you prevent attacker from writing them? Or is it one-time programmable and your hardware becomes brick / unresellable / un-updateable if you lose your keys or don't want to pass them on to next owner? How do you make sure your keys are more secure than the machine that somehow got its firmware infected? What if the code that checks your signature turns out to have a bug? Are you stuck with it, or can you update the code? What if an attacker can infect that code..? Making this all convenient and safe is very hard and in practice either takes freedoms from you (you must trust your vendor and their signed binaries), or gives a potential attacker the same freedoms that you get. Giving you full access without enabling an attacker to have the same access is quite impractical (read: unlikely to ever happen for consumer hardware that you can order over the internet), and you still have to trust the hardware is what it claims to be when you get your hands on it. In practice, I can't audit the hardware but I'd be pretty good if I could flash it myself once it's in my hands.
caaqil 5y ago
Nice to see this finally made it to the front page. APT41 always bringing it. For anyone interested in the samples: https://samples.vx-underground.org/APTs/2022/2022.01.20/Samples/ https://samples.vx-underground.org/APTs/2022/2022.01.20/Samp...
YXNjaGVyZWdlbgo 5y ago
I know a lot of people hate the idea of AMDs PSB but that's exactly what its made for and it could have prevented the attack.
- axiolite 5y ago
  The problem with AMD's PSB is the one-time eFuse on the CPU. If they just provided some way (perhaps electrically connecting a couple contacts on the chip) to reset the eFuse, it would be fine. Instead it causes CPUs to be locked to the motherboard/vendor the moment they are inserted.
- jevoten 5y ago
  And it could do so while still giving the owner tamper-evident control. Yet that never seems to happen - security is too good of an excuse for expanding vendor control at the expense of consumers.
  - my123 5y ago
    Note that Intel’s implementation is on the PCH/chipset, and as such allowing users to freely swap CPUs.
  - fsflover 5y ago
    Purism Librem 14 laptop gives the control to the user with TPM.
  - rosndo 5y ago
    > Yet that never seems to happen Except with secureboot and TPMs?
    - my123 5y ago
      A TPM allows to detect this tampering if used properly for that use case. (To clarify, Windows with BitLocker bound to TPM and Secure Boot on does _not_ do this, taking a shortcut) UEFI Secure Boot doesn’t have much to do with this, because this is about loading an altered UEFI firmware.

139 points by curmudgeon22 5y ago

I notice the writeup only mentions Windows? Do they attack any Linux hosts?

If we just had flash that was write protected unless a jumper was moved, this kind of thing just would not happen. "Oh, but the average user is incapable of that" and "Corporate IT are unwilling to do that" are the two biggest excuses I hear to not make it so. Here's a crazy idea: you connect said jumper to a front panel key switch. The 'average' consumer could probably sort that out. And corporate IT could just leave it enabled, or require you to turn the key for them, or have IT interns on site that run around with the keys or whatever. A Key. A literal physical key. But I guess that's too low tech for the crypto obsessed purveyors of TPMs and the like.

2OEH8eoCRo0 5y ago
I don't understand this either. A physical presence requirement eliminates all remote threats. The vast majority of these attacks occur from the safety of some far away adversarial country. They'd have to have agents on the ground carrying out these attacks and getting caught.
snthd 5y ago
If you turn the key, how do you really know it's your firmware that's being written?
- greenbit 5y ago
  Point is, if you Don't turn the key, you sleep well at night knowing it's Not Being Written. Contrary to the apparent belief of the developers of New Products, a good many of us are sick to death of everything "as a service", and all the headaches that ensue.
  - AshamedCaptain 5y ago
    I am sure one of these "New Products" developers will come here and share the story of the Evil Hotel Maid that comes to your room and toggles the physical switch on your computing products.
    - rzwitserloot 5y ago
      Anybody that peddles you an absolute safety in IT security is an idiot who should be swiftly ignored. If they work for you, fired and all their work thoroughly reviewed. The flip side of that argument is just as true: Anybody that denigrates a security measure because they can come up with a single convoluted compromise is an idiot. I'm hoping that's not you, it sounds like you're saying that some hypothetical strawman developer would say such a thing (Sounds like a particularly plausible strawman to me... a sad state of affairs!) – but that's the defense if you meet such dangerous idiots. With this proposal, there's a key involved, which is some extremely limited defense against evil maids. If it's truly a key as in 'keys in doors', you can pick it, trivially (see Lockpicking Lawyer's video stream for how trivial it is to pick or otherwise circumvent locks). A well thought through system can fix many of these warts - in this case all you need is an unresettable flag that shows: Compromised! Designing a lock that can detect but not defend against picking is a lot easier than making an unpickable lock. But I'm sure LPL or somebody else with skills, experience, lots of time, and a budget to buy a bunch and open em up to look at how they work can come up with a scheme to pick em open without triggering the flag. You could also make it a digital key (or a combination even). Point is, pre-supposing a well-tested design with input from experts is mostly just begging the question: If I had that, we might as well posit 'Let us assume no bugs in any firmware implementations of stuff'. And for an encore, let's posit "world peace", about as useful. It's all swiss cheese: _EVERYTHING_ has holes. Nothing is perfect. But, layer enough slices of swiss cheese on a slice of bread and pretty soon no bread is visible. A physical key rather obviously covers precisely those holes that schemes involving entirely digital and remote-accessible setups have. Thus it is a great idea, and the fact that an evil maid can attack it indicates someone either doesn't understand the fundamentals of security (they don't get that it's all imperfect, and combining to cover the gaps is almost always the winning move), or is intentionally coming up with pithy oversimplified toss to cheerlead their product or pet preference.
mjg59 5y ago
Flash needs to be writable at runtime - things like ram training parameters are stored there.
- zbentley 5y ago
  Parameters could be stored in separate memory from the operating system that interprets those parameters. This is somewhat similar to what Apple does with the secure enclave. That way, wearout parameters and non-risky user tunables would still be customizable without risk of compromise. Heck, even if that had to be implemented with an entirely separate hardware chip for parameter storage on the motherboard, the added cost would be negligible.
axiolite 5y ago
> If we just had flash that was write protected unless a jumper was moved, this kind of thing just would not happen. This would make it incredibly hard to manage a bunch of servers in various remote data centers. > connect said jumper to a front panel key switch Ah yes, I do miss the good old days of front-panel key switches, where rubbing your feet and touching the front would reboot your system. I've never seen a smartphone or ultrabook with one, though.

woliveirajr 5y ago

> Note that at the time of writing we lack sufficient evidence to retrace how the UEFI firmware was infected in the first place. The infection itself, however, is assumed to have occurred remotely. And given that it's done on memory (flash, that'll persist over reboots, windows reinstall and even hdd and sdd replacement), it wasn't done by trivial scriptkids. Expect more tpm-like things "to protect you".

caaqil 5y ago
> it wasn't done by trivial scriptkids. I mean that's pretty obvious given that we're talking about APT41.
bitwize 5y ago
Things like this are why we need a verified boot chain.
- foxfluff 5y ago
  Call me old fashioned but I'd prefer to just make it impossible to write the firmware without physical access. Verification just brings it's own issues and is not a panacea. Who owns the key(s)? If not you, how do you trust them? If you, how do you write them? How do you prevent attacker from writing them? Or is it one-time programmable and your hardware becomes brick / unresellable / un-updateable if you lose your keys or don't want to pass them on to next owner? How do you make sure your keys are more secure than the machine that somehow got its firmware infected? What if the code that checks your signature turns out to have a bug? Are you stuck with it, or can you update the code? What if an attacker can infect that code..? Making this all convenient and safe is very hard and in practice either takes freedoms from you (you must trust your vendor and their signed binaries), or gives a potential attacker the same freedoms that you get. Giving you full access without enabling an attacker to have the same access is quite impractical (read: unlikely to ever happen for consumer hardware that you can order over the internet), and you still have to trust the hardware is what it claims to be when you get your hands on it. In practice, I can't audit the hardware but I'd be pretty good if I could flash it myself once it's in my hands.

caaqil 5y ago

Nice to see this finally made it to the front page. APT41 always bringing it. For anyone interested in the samples: https://samples.vx-underground.org/APTs/2022/2022.01.20/Samples/ https://samples.vx-underground.org/APTs/2022/2022.01.20/Samp...

YXNjaGVyZWdlbgo 5y ago

I know a lot of people hate the idea of AMDs PSB but that's exactly what its made for and it could have prevented the attack.

axiolite 5y ago
The problem with AMD's PSB is the one-time eFuse on the CPU. If they just provided some way (perhaps electrically connecting a couple contacts on the chip) to reset the eFuse, it would be fine. Instead it causes CPUs to be locked to the motherboard/vendor the moment they are inserted.
jevoten 5y ago
And it could do so while still giving the owner tamper-evident control. Yet that never seems to happen - security is too good of an excuse for expanding vendor control at the expense of consumers.
- my123 5y ago
  Note that Intel’s implementation is on the PCH/chipset, and as such allowing users to freely swap CPUs.
- fsflover 5y ago
  Purism Librem 14 laptop gives the control to the user with TPM.
- rosndo 5y ago
  > Yet that never seems to happen Except with secureboot and TPMs?
  - my123 5y ago
    A TPM allows to detect this tampering if used properly for that use case. (To clarify, Windows with BitLocker bound to TPM and Secure Boot on does _not_ do this, taking a shortcut) UEFI Secure Boot doesn’t have much to do with this, because this is about loading an altered UEFI firmware.