Secure Boot - UEFI-Bootprozess-Absicherung gegen Bootkits

Secure Boot is a security standard implemented in UEFI (Unified Extensible Firmware Interface) firmware that ensures a computer only loads software that has been digitally signed by the manufacturer and deemed trustworthy. Without Secure Boot, malware can run before the operating system starts—invisible to antivirus software.

The Bootkit Problem

Normal Boot Process

1. UEFI/BIOS starts
2. Bootloader (GRUB, Windows Boot Manager) is loaded
3. OS kernel is loaded
4. Operating system starts
5. Antivirus and security tools start

> Problem: Antivirus starts after the bootloader! Malware installed in the bootloader starts before the AV—and is invisible to it.

Known Bootkit Attacks

BlackLotus (2023): UEFI bootkit for Windows

• Runs in Ring 0 before the Windows kernel
• Can bypass Secure Boot! (unpatched PCs)
• Invisible to AV
• Disables: Defender, BitLocker, Kernel Patch Protection

Additional examples:

• FinSpy UEFI implant (APT, state-sponsored attackers)
• MosaicRegressor (APT41, embedded in UEFI flash!)
• TrickBot "TrickBoot": UEFI manipulation via admin access

Consequences of a UEFI bootkit:

• Persistence through hard drive replacement and Windows reinstallation!
• Complete control over the system before any security mechanism
• Detection is extremely difficult (no standard file system tool can find it)

How Secure Boot Works

UEFI Key Structure

Key	Meaning	Owner
PK (Platform Key)	Trust anchor	Hardware manufacturer (ASUS, Dell, Lenovo, etc.)
KEK (Key Exchange Key)	Intermediate certificate	Microsoft, Linux Foundation, etc.
db (Signature Database)	Trusted signatures	Bootloader
dbx (Forbidden Database)	Forbidden/revoked signatures	-

Chain of Trust: PK → KEK → db → Bootloader signature → Kernel signature

Boot Process with Secure Boot

1. UEFI checks: Does the bootloader have a valid signature?
   • Signature in db (Signature Database)? → continue
   • Signature in dbx (revoked)? → STOP
   • No certificate? → STOP
2. Bootloader loaded (e.g., Windows Boot Manager)
3. Bootloader checks: Does the OS kernel have a valid signature?
4. Kernel loaded → System boots

Tampered bootloader = no valid signature = STOP.

Supported Operating Systems

OS	Support
Windows 10/11	Native (Microsoft certificate)
Linux	Via shim (pre-bootloader with Microsoft certificate); shim loads GRUB, GRUB loads Linux kernel
macOS (Intel)	Not Secure Boot in the UEFI sense
macOS (Apple Silicon)	Proprietary boot security concept (Secure Enclave)
Android	Proprietary Verified Boot implementation

Configuration and Custom Secure Boot

UEFI settings:
  → Restart PC → UEFI/BIOS key (F2, F12, DEL, ESC)
  → "Security" → "Secure Boot"
  → Status: Enabled / Disabled / User Mode / Setup Mode

  Setup Mode: Custom keys can be installed
  User Mode: Default keys active; no changes without PK signature

# Check Secure Boot status - Windows:
msinfo32  # → "Secure Boot State": Yes/No/Unsupported

# PowerShell:
Confirm-SecureBootUEFI
# True = Secure Boot enabled and validated

# Check Secure Boot status - Linux:
mokutil --sb-state
# "SecureBoot enabled" or "SecureBoot disabled"

# Bootcurrent and Secure Boot:
efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot
# 01 = enabled, 00 = disabled

# Custom Secure Boot (Custom Keys, for Enterprise):
# Scenario: Custom Linux distribution or custom bootloader

# Create custom key:
openssl req -new -x509 -newkey rsa:4096 \
  -keyout MOK.key -out MOK.crt \
  -days 3650 -subj "/CN=My Secure Boot Key"

# Key in DER format:
openssl x509 -in MOK.crt -outform DER -out MOK.der

# Register key in MOK Manager (Linux):
mokutil --import MOK.der
# → Restart → MOK Manager → Confirm key

# Sign your own kernel:
sbsign --key MOK.key --cert MOK.crt \
  --output /boot/vmlinuz-signed /boot/vmlinuz

# Secure Boot in Enterprise GPO (Windows):
# Only UEFI mode allowed (no Legacy BIOS):
Computer Configuration → Administrative Templates → Windows Components → BitLocker
→ "Allow Secure Boot for integrity validation": Enabled
# ALSO: Credential Guard requires Secure Boot!

BlackLotus and Secure Boot Bypasses

BlackLotus: Secure Boot Bypass (2023)

CVE-2022-21894 (Boot Manager):

• Exploited by BlackLotus
• Boot Manager before patch: certain UEFI bootloaders are loaded even though they have vulnerabilities
• Exploit: Start a signed but vulnerable bootloader → disable Secure Boot from there

Protection:

• dbx update: Vulnerable bootloaders added to revocation list
• Windows Update KB5025885 (May 2023): CRITICAL!
• UEFI firmware update from the PC manufacturer
• Measured Boot + TPM: Detectable even after boot manipulation

BootHole (CVE-2020-10713, GRUB2)

Buffer overflow in GRUB2’s parsing of grub.cfg – allows Secure Boot to be bypassed. All Linux distributions using GRUB2 are affected. Fix: shim and GRUB2 update + dbx revocation.

General attack vectors against Secure Boot

1. Attack the UEFI firmware itself (if admin access is available)
2. Vulnerability in bootloader signature verification
3. Reuse outdated, signed bootloaders (rollback)
4. Physical attack: CMOS reset, UEFI flash via SPI

Defense-in-Depth

Secure Boot + TPM 2.0 + Measured Boot + Attestation:

• Measured Boot: TPM PCR registers contain a hash of the boot process
• Attestation: Cloud/MDM can determine whether the boot process was unaltered
• Conditional Access: Insecure boot state → no network access!

TPM Integration and Measured Boot

TPM 2.0 (Trusted Platform Module)

Hardware security module on the motherboard—stores hashes of the boot process in PCR registers (Platform Configuration Registers).

Measured Boot—UEFI measures (hashed) every step:

PCR Register	Content
PCR0	BIOS/UEFI code
PCR4	Bootloader (MBR, EFI app)
PCR5	Bootloader configuration
PCR7	Secure Boot status
PCR11	Windows Boot Manager

Each step generates a hash in the PCR. Changes are detectable. BitLocker uses PCR values: Boot tampering → BitLocker key locked!

Remote Attestation

TPM can cryptographically prove that the boot process remained unchanged.

Conditional Access (Microsoft Intune, Azure AD): "Device with non-compliant boot process → no corporate access!"

Windows Device Health Attestation:

1. Device reports TPM PCR values to Azure
2. Azure verifies: Secure Boot active? No known malware in the boot process?
3. Conditional Access Policy: "Only compliant devices → access to O365"