Recovering from Black Lotus, question about versioning. #6769
Replies: 4 comments
-
Sounds onerous -- got any more details?!
The version is initially calculated here: https://github.com/fwupd/fwupd/blob/main/libfwupdplugin/fu-efi-signature-list.c#L157 -- but this is adjusted depending on how the EFI variable was built. See https://github.com/fwupd/fwupd/blob/main/plugins/uefi-dbx/README.md#metadata for details. |
Beta Was this translation helpful? Give feedback.
-
To recover I would suggest "reset BIOS default settings". Unless the attacker actually modified the existing BIOS (such as beat Intel boot guard or AMD Secure Boot) this should clear anything persistently stored to the SPI. |
Beta Was this translation helpful? Give feedback.
-
Not much. I have some dumps of the KEK and DBX keys, but I lack the domain knowledge to make much sense of them. Plus, I suppose the alternative exists, wherein all the malware does is change the version number as a red herring. Installing from source certainly SEEMS to believe that THIS: Reflashing the bios firmware itself also reverts the metadata to saying "371". This all started w/ Mantic, and the disambiguation of fwupdmgr from snap, so maybe there's a zero-day I'm unaware of, or maybe this thing is just designed to mess w/ the user as a smoke shield. I'm uncertain which, truthfully. I have taken steps which SHOULD, in THEORY, purge Black Lotus, yet my issues still persist. The biggest issue is that they would need the signing keys from Microsoft, or the ability to change the BIOS firmware itself and implant their own KEK. Given that this thing clearly HAS modified my bios firmware on at least one device, I do readily believe it possible. |
Beta Was this translation helpful? Give feedback.
-
Question for you. When I download the the .bin files from either the microsoft website, or manually extract it from the .cab file, the checksums are identical. Will installing this file, from either fwupd or dbxtool, manually add the Windows 2011 CA KEK file to my UEFI revocation bios? Additionally, do you have any recommendations for GUI (or otherwise) tools that I could use to modify either the BIN file, or the revocation list itself, on older bios's that don't support individual key removal? Unfortunately half the tools listed here on the Fed's website are no longer available. Thanks in advance for any advice. This thing has been hell and I'm just a single individual, so it's a mess to untangle without corporate resources on hand. |
Beta Was this translation helpful? Give feedback.
-
I'm recovering from a Black Lotus attack (modified to target Linux).
I have a question. Part of the attacker's persistence mechanism, was to modify fwupd to point to a malicious host.
In order to circumvent this, I ultimately downloaded the .dbx files from Microsoft and https://github.com/fwupd/dbx-firmware, and flashed them by hand using dbxtool, which seems to have ostensibly fixed the problem.
However, I have noticed something a bit odd. When I reboot the system, my dbx version reads "421", or "423" depending on the computer's vendor. This persists until I use fwupd to refresh the metadata, at which point the version reverts back to 371 (at least until I reinstall the operating system).
For my own peace of mind, and for the safety of my work, I'd like to understand this situation a bit more clearly.
My question is, what dictates the version number? My initial thought was, maybe it's tied to the number of key signatures, but if that were the case, the dbx version number should be ~500.
Likewise, why does the checksum in the metainfo file report a different result than the checksum of the .dbx file? ("13a1f37bedfb5417b6b737e2a3816c8fd587d74d836914b2b2edc9fd6ca30e58<" vs "3e56c3d9e5b12edbd9e4006413d87fba099de1eba33d2bea566e742166cb366a")
Is this intentional? Or am I still dealing with a malformed database file? Thanks in advance.
Beta Was this translation helpful? Give feedback.
All reactions