Everyone and their dog are talking about secure boot and how having it enabled on their machine immediately haloed it in sweet fuzzy security-emanating glory, so obviously I want this on my laptop too!
Debian's documentation involves
MOK,
but because managing PKI isn't fun™, I went with apt install shim-signed
grub-efi-amd64-signed instead, making use of Microsoft and Debian's keys: if
an attacker is able to obtain them, I have bigger problems anyway. Once
installed, reboot, enable trusted boot in the BIOS/UEFI, and that's it.
To check that an unsigned bootloader is detected, you can use bootctl install
and reboot, since
systemd-boot
isn't signed, and is unlikely to ever
be. You should get the
following scary warning:
You can now bootctl remove to get rid of it, and use fwupdmgr to check that
everything is working:
# fwupdmgr security
HSI-1
✔ ME manufacturing mode: Locked
✔ ME override: Locked
✔ SPI BIOS region: Locked
✔ SPI lock: Enabled
✔ SPI write: Disabled
✔ UEFI platform key: Valid
✘ TPM v2.0: Not found
HSI-2
✔ IOMMU: Enabled
✔ Intel BootGuard: Enabled
✘ Intel BootGuard ACM protected: Invalid
✘ Intel BootGuard OTP fuse: Invalid
✘ Intel BootGuard verified boot: Invalid
[…]
Runtime Suffix -!
✔ Linux kernel: Untainted
✔ Linux kernel lockdown: Enabled
✘ Linux swap: Unencrypted
# mokutil --sb-state
SecureBoot enabled
#
Yay, secure boot! My motherboard is too old to have a
TPM2,
the CPU too old to have fancy
BootGuard features, and the
swap is in an encrypted LVM, but it's a known
bug in fwupdmgr.
Secure boot is all dandy and nice, but software is inherently buggy, so don't forget to upgrade your BIOS/UEFI to the latest available version, and to do a pass with chipsec just in case, because the world is a scary place:
# chipsec_main.py
insmod: ERROR: could not insert module /chipsec/chipsec/helper/linux/chipsec.ko: Operation not permitted
ERROR: Message: "Could not start Linux Helper, are you running as Admin/root?
Command '['insmod', '/chipsec/chipsec/helper/linux/chipsec.ko', '', '']' returned non-zero exit status 1."
# dmesg | tail -n 1
[201.117318] Lockdown: insmod: unsigned module loading is restricted; see man kernel_lockdown.7
#
Secure boot is working! So after disabling it in the BIOS/UEFI and rebooting,
we can load the chipsec kernel module, and make use of it. Don't forget to
re-enable secure boot afterwards. Running chipsec_main.py will output a ton
of detailed information, and tell you how much you should be worried and how
loud you should yell at your vendor/OEM to get things fixed.
Also, if your machine, like mine, is a bit old, keep an eye on recent LVFS
plans
to improve our situation.
Chipsec can also be used to check that you're not infected with some known implants:
# chipsec_main.py -i -m tools.uefi.scan_blocked
[x][ =======================================================================
[x][ Module: Check for blocked EFI binaries in UEFI firmware
[x][ =======================================================================
[*] Dumping FW image from ROM to fw.bin: 0x00500000 bytes at [0x00BFFFFF:0x00700000]
[*] This may take a few minutes (instead, use 'chipsec_util spi dump')...
[*] searching for EFI binaries that match criteria from 'blockedlist.json':
HT_UEFI_Rootkit - HackingTeam UEFI Rootkit (https://www.mcafee.com/enterprise/en-us/threat-center/advanced-threat-research/uefi-rootkit.html)
MR_UEFI_Rootkit - MosaicRegressor UEFI Rootkit (https://securelist.com/mosaicregressor/98849/)
ThinkPwn - ThinkPwn: SystemSmmRuntimeRt SMM vulnerability (http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html)
LoJax - LoJax: First UEFI rootkit found in the wild (https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/)
Decoding
[…]
[+] PASSED: Didn't find any blocked EFI binary
#
Since blocklists suck, it's also possible to ask virustotal's opinion:
# ./chipsec_main.py -i -m tools.uefi.reputation -a 1337133713371337133713371337
[x][ =======================================================================
[x][ Module: Check for suspicious EFI binaries in UEFI firmware
[x][ =======================================================================
[*] dumping FW image from ROM to fw.bin: 0x00500000 bytes at [0x00BFFFFF:0x00700000]
[*] this may take a few minutes (instead, use 'chipsec_util spi dump')...
Decoding
[…]
[!] WARNING: Unfamiliar EFI binary found in the UEFI firmware image
+00000080h b'S_PE32' section of binary {5920f406-5868-44f5-a9b9-6d4031481cc9} b'LenovoOemSecPei.efi': Type 10h
MD5 : 1ee84dc33ef79e592ac7102c074288d3
SHA1 : 4d707fbb8651c4fbc80c79d47643c17a7dfaa44e
SHA256: 918c04107fcc0b42d16409cc31a3bda70a8c40144eb74c226d2c7d8f14a5b535
[+] PASSED: Didn't find any suspicious EFI binary
#
Unknown EFI binary, interesting! Chipsec is able to dump the BIOS and the UEFI
with chipsec_util spi dump, and we can then use EUFITool to extract whatever part, including the
interesting S_PE32 section of LenovoOemSecPei.efi, to upload it on
virustotal.
# ./chipsec_main.py -i -m tools.uefi.reputation -a 1337133713371337133713371337
[x][ =======================================================================
[x][ Module: Check for suspicious EFI binaries in UEFI firmware
[x][ =======================================================================
[*] dumping FW image from ROM to fw.bin: 0x00500000 bytes at [0x00BFFFFF:0x00700000]
[*] this may take a few minutes (instead, use 'chipsec_util spi dump')...
Decoding
[+] PASSED: Didn't find any suspicious EFI binary
#
Feel free to reverse the binary and tell me if I should set my computer on fire and throw it out the window because it's a sophisticated APT implant.
Anyway, back to secure-boot I'm not credulous enough to think that this would deter any serious attacker, but it doesn't change anything for me usability-wise, and might make the life of kiddies a bit harder and implants maybe a bit brittler, so why not. And if nothing else, playing with chipsec was a healthy reminder that all our computers are running atop a steaming pile of shady patchwork of legacy blobs contraptions.