21–30 of 125 posts
Ooh, I recognise that name. They were involved in certificate shenanigans with Startcom. I'm immediately suspicious.
(I've barely started reading the article, but I'm predisposed to distrust anything involved with Qihoo)
That's why things like the Pluton processor and TPMs are useful. (A rain of downvotes falls on me) Seriously, even good old BIOS is susceptible to rootkits, there has been tons of them. So no crying over UEFI please. We need a fully signed and auditable chain of trust for booting OSes. Of course all this crap needs to be open source but it needs to be locked down to prevent not trusted binaries as much as possible. A…
I'm not certain this is where Pluton or a TPM could've helped much (individually), it's more the task of Secure Boot, Secure Launch(/DRTM) and Trusted Boot. I'd love to see a similar effort at ensuring boot integrity for Linux, but way too many distros can't even handle Secure Boot with Nvidia/DKMS. Though even more practical features, one being (f)TPM-backed FDE, are very cumbersome and underutilised.
"Looking at the various firmware images we were able to obtain, we assess that the modifications may have been performed with an automated patcher. If so, it would follow that the attackers had prior access to the victim’s computer in order to extract, modify and overwrite the motherboard’s firmware. This could be achieved through a precursor malware implant already deployed on the computer or physical access"
While Secure Boot + BitLocker with TPM and PIN would have prevented an Evil Maid attack (at least would have triggered a PCR change and a Windows Recovery prompt), a preliminary infection (I understand by it a supply chain attack before it reaches the user for the first time, but maybe I'm extrapolating a bit what the report is saying) would have stayed undetected in most scenarios (depending on how Intel Boot Guard is configured).
Regarding the Linux part, ANSSI did a pretty great job with their CLIP OS implementation: https://docs.clip-os.org/clipos/boot_integrity.html, but it's really "for the masses" :(
> The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 – long before UEFI attacks started being publicly described. This discovery begs a final question: if this is what the attackers were using back then, what are they using today? I always marvel at the ingenuity and technical complexity of these kinds of attacks, but this is also something that…
> The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 – long before UEFI attacks started being publicly described. This discovery begs a final question: if this is what the attackers were using back then, what are they using today? I always marvel at the ingenuity and technical complexity of these kinds of attacks, but this is also something that…
I don't know which one it is.
> The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 – long before UEFI attacks started being publicly described. This discovery begs a final question: if this is what the attackers were using back then, what are they using today? I always marvel at the ingenuity and technical complexity of these kinds of attacks, but this is also something that…
Yeah, I assume that either everything is infected and backdoored and there's no way to detect it until it's too late, or almost nothing is infected because doing so would be the cross platform compatibility nightmare of all nightmares. I don't know which one it is.
That's why things like the Pluton processor and TPMs are useful. (A rain of downvotes falls on me) Seriously, even good old BIOS is susceptible to rootkits, there has been tons of them. So no crying over UEFI please. We need a fully signed and auditable chain of trust for booting OSes. Of course all this crap needs to be open source but it needs to be locked down to prevent not trusted binaries as much as possible. A…
Were there? I couldn't find anything, but then again Google is garbage nowadays if you want to find older stuff.
To my understanding, the limitations of the old BIOS world would've made it much harder to hack on it other than maybe enabling hidden menus.
The UEFI world is so much larger, more powerful and already offers plenty of abstractions and services. You can probably write a relatively portable rootkit that works across a plethora of different Mainboards and Chipsets. And then you come in and try to fix it with secure boot, and when secure boot isn't good enough anymore you add pluton and then what?
And what's your threat model anyways? "Professional Hackers" nowadays are in it for the money. Why would they want to custom tailor a rootkit for your BIOS? Why would they want to target you with a generic UEFI rootkit? Apparently, crypto ransomware is perfectly capable of infecting a user on windows with secure boot enabled. No need for a rootkit.
Who is going to be interested in rootkitting you besides a government backed hacking op? And in that case, I fully trust them to be able to get around any secure boot measures either with yet another exploit, or because they have access to the signing keys one way or the other.
I live in fear of being told my factory delivered Dell rackable servers have been EFI infected since inception on my network. It's silly to pretend a BSD OS is going to be immune of the consequences of an EFI which is compromised at birth. Sooner or later there will be a value chain in compromising my OS, through the EFI. I wish we had better out of band EFI validity checks, based on what the manufacturer thinks shou…
You can use the Dell Trusted Agent to to do just that: https://www.dell.com/support/kbdoc/en-us/000126098/what-is-d...
I mean realistically, we'd be naive to not expect that state-sponsored hackers have rooted machines somewhere in the supply chain (hardware, firmware and of course software). Is everyone being monitored all the time? No, but I'd stay away from electronics if I expected an intelligence agency was interested in me.
I live in fear of being told my factory delivered Dell rackable servers have been EFI infected since inception on my network. It's silly to pretend a BSD OS is going to be immune of the consequences of an EFI which is compromised at birth. Sooner or later there will be a value chain in compromising my OS, through the EFI. I wish we had better out of band EFI validity checks, based on what the manufacturer thinks shou…
While some may argue that this header would be the perfect place to install a implant, doing so is vastly harder than popping some manufacturers computer. Also, since the header will be specifically checked by some users, it becomes a very risky place to install an implant.