2

Secure boot on a Thinkpad x230 on Debian and a cursory look at UEFI

 2 years ago
source link: https://dustri.org/b/secure-boot-on-a-thinkpad-x230-on-debian-and-a-cursory-look-at-uefi.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Artificial truth

archives | latest | homepage | atom/rss/twitter

Quick poll: What is the worst piece of software you've worked on and why is it Lotus note?

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:

Secure boot failure message

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.


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK