External input

Fuzz the external input.

1) File fuzzing can be used for different file parsers, including the boot logo file, such as Bitmap (BMP) and Joint Photographic Experts Group (JPEG); firmware update capsule file or recovery file, such as UEFI capsule; third-party firmware executable files, such as portable and executable (PE) and executable and linking format (ELF); configuration files, such as Extensible Markup Language (XML) and JavaScript Object Notation (JSON); and so on.

2) File system fuzzing can be used for the file system and disk partition , including File Allocation Table (FAT), New Technology File System (NTFS), extended file system (EXT2/3/4), Hierarchical File System (HFS), Universal Disc Format (UDF), Compact Disc File System (CDFS), El Torito, Flash File System (FFS), or Firmware File System (FFS).

3) Protocol fuzzing can be used for the firmware network stack, including Ethernet, WiFi, Bluetooth, Cellular Network (3G, 4G, 5G), Address Resolution Protocol (ARP), Internet Protocol (IP) version 4 and version 6, Internet Protocol Security (IPsec), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Transport Layer Security (TLS), Dynamic Host Configuration Protocol (DHCP), Preboot Execution Environment (PXE), Domain Name Server (DNS), Hyper Text Transfer Protocol (HTTP), Representational State Transfer (REST), Intelligent Platform Management Interface (IPMI), RedFish, Universal plug and play (UPNP) etc and the device communication protocol, including the Secure Protocol and Data Model (SPDM).

4) Management mode or trusted world fuzzing can be used for the management mode or trusted world communication buffer and management mode interrupt (MMI) handler , such as X86 system management mode (SMM) or ARM TrustZone, especially the software management mode interrupt for communication.

5) Data-specific fuzzing can be used, such as UEFI variable data for the UEFI/PI BIOS, PI Boot Script data for S3 resume, Boot Policy Manifest (BPM) for the Platform Root-of-Trust module, the ACPI table for the dynamic root-of-trust (DRTM) module, and so on.

Side channel attacks.

1) If the management mode or trusted world includes secrets, check if the management mode handler applies the side channel best practices, such as Spectre.

2) If the kernel mode includes secrets, check if the kernel handler applies the side channel best practices, such as Spectre and Meltdown.

Race condition

Time-of-check/time-of-use (TOC/TOU) attacks.

1) A TOC/TOU attack to the management mode or trusted world communication buffer.

2) A TOC/TOU attack against the data buffer used by the firmware update tool.

3) A TOC/TOU attack against the firmware image on the flash after it is validated by the Platform Root-of-Trust.

Multiple processors’ race conditions.

1) Make one processor enter management mode or trusted world to unlock the register and make the other processor take advantage of the unlocked system state, such as flash unlock.

Hardware input

Fuzz the hardware input.

1) Fuzz a silicon register for the module to access the register, such as memory mapped I/O (MMIO), I/O, PCI configuration space, X86 model-specific register (MSR), and so on.

2) Fuzz device information, such as a USB descriptor, Bluetooth LE advertisement data, memory DIMM Serial Presence Detect (SPD) data, and so on.

3) Fuzz a bus communication, such as Serial Peripheral Interface (SPI) bus, Inter-Integrated Circuit (I2C) bus, System Management Bus (SMBus), USB bus, and so on.

Base address register (BAR) overlap.

1) Overlap a high-privilege MMIO region, such as Intel Virtualization for Directed I/O configuration or Serial Peripheral Interface (SPI) flash configuration, with a low-privilege MMIO region, such as the traditional PCI express configuration space.

2) Overlap a critical memory region, such as system management RAM (SMRAM), with a low-privilege MMIO region, such as the traditional PCI express configuration space.

DMA attacks.

1) Try to generate DMA transactions to the system memory in order to inject code.

2) Try to generate DMA transactions to the system memory to steal secret data.

Cache attacks.

1) Perform the cache attack against the management mode code.

Power surprise removal.

1) Try to cause a partial update via a surprise power removal while the system is updating a new firmware image.

2) Try to cause a partial update via a surprise power removal when the system is updating the configuration, such as a UEFI variable.

3) Try to steal secrets in the OS memory via a power surprise removal to see if the memory content is cleared in the next boot.

4) Try to steal the secret in the OS from the TCG storage protected region via a power surprise removal to see if the TPer reset is issued on the next boot.

Chassis intrusion.

1) Clear CMOS to roll back to the default configuration.

2) Set the hardware jumper to trigger a special boot mode, such as recovery or manufacturing mode.

3) Add or replace the hardware device with a malicious one in the platform, such as a PCI card, memory DIMM, and so on.

4) Update a malicious device firmware on the board, such as PCI device firmware, memory DIMM firmware, and so on.

Other device attacks.

1) Flash wear-out attacks for the SPI flash via continual writes of new configuration data.

2) Row hammer attacks against the DRAM.

3) Glitch attacks against the DRAM.

Secret handling

User password authentication.

1) Search for the password in the keyboard buffer.

2) Search for the password in the management mode communication buffer.

3) Search for the password in system memory, such as stack, heap, or image global data area.

4) Search for the password in the system non-volatile storage, such as the UEFI variable store.

5) The password should be searched in both ASCII format and Unicode format.

Weak password implementations.

1) Check if the password is properly hashed in the NV storage, instead of storage as an XOR against a known value.

2) Check if the non-volatile storage can be updated without authorization.

3) Check if a salt is used and with sufficient salt length.

4) Check if the strong password policy is enforced.

5) Check if there is a password retry limit.

6) Check if there is an option to forget a password.

7) Try to clear CMOS and then trigger a recovery manufacturing mode flow in order to see if the password is still required.

8) Check if there is a default password provisioned or a supervisor password as a backdoor.

Hard drive passwords.

1) Try to bypass the HDD password and TCG storage password.

2) Try to freeze the HDD password or TCG storage SID, especially in a special boot path such as S3 resume, recovery, or manufacturing mode.

3) Try to steal the HDD password or TCG storage password saved in management mode and/or the non-volatile storage.

2) Try to steal the password information by comparing the error exit time.

Network credentials.

1) Try to steal the deployed WIFI password as a pre-shared key (PSK) or enterprise mode certificate in plain text.

2) Try to steal the deployed TLS or IPSec private certificate in plain text.

Device access.

1) Check if there are any hardcoded access codes for the device, such as EC or battery.

2) Check if there are any access codes provisioned in the system memory, such as stack, heap, global data region, and so on, or the NV storage such as UEFI variable.

3) Check if there is any RPMB key provisioned in the system memory or the NV storage.

4) Check if there is any RPMC key provisioned in the system memory or the NV storage.

Cryptographic keys.

1) Check if any symmetric key is left in the memory after processing, such as AES key, HMAC key, and so on.

2) Check if any asymmetric key is left in the memory after processing , such as RSA private key, the password to protect the private key, and so on.

3) Check if the keys are cleared in any path, from the provider to the consumer, such as stack, heap, global variable, communication buffer, and so on.

Side channel attack.

1) Try to steal the password saved in the management mode RAM.

Register lock

Vulnerability scan.

1) Run the CHIPSEC scan tool to check if all lockable registers are indeed locked, especially the flash lock and management mode lock.

2) Run the CHIPSEC scan tool in a special boot mode, such as S3 resume, S4 resume, recovery mode, or even manufacturing mode, to check if the end user can trigger the manufacturing mode restart.

Secure configuration

Break the secure boot policy.

1) Try to disable secure boot, for example, via UEFI variable.

2) Try to bypass the secure boot check in each special boot mode, such as S3 resume, S4 resume, recovery mode, or manufacturing mode.

3) Try to modify the enrolled public certificate without authorization .

4) Try to delete the enrolled forbidden public certificates without authorization.

Break the Trusted Computing Group policy.

1) Try to disable the measured boot feature. For example, disable TPM in the setup option or a UEFI variable.

2) Try to gain access to the TPM platform hierarchy auth after boot, especially in special boot modes such as S3, S4, recovery, manufacturing mode, and so on.

3) Try to suspend the system without sending the shutdown command to the TPM in order to see if the TPM device can recover in the S3 resume.

4) Trigger the TPM S3 resume failure to see if the PCR has not been capped.

5) Try to disable the TCG memory override (MOR) feature by clearing the MOR variable.

6) Try to update the TCG physical present flag configuration, especially in special boot modes such as S4 resume, recovery, and manufacturing, for example, if the flag configuration is saved in NV storage.

Check completeness.

1) For secure boot, check if the verification happens for all third-party components. Assess the image on the untrusted flash partition, the image on the disk, the image in the PCI card, the image from the network , the image from the recovery media, and so on.

2) For secure boot, check if the verification happens for all boot modes, especially S3 resume, S4 resume, recovery, manufacturing mode, and so on.

3) For static root-of-trust for measurement (SRTM), check if all critical code and critical configuration are measured into the TPM. Look for any code that is not measured, such as the Firmware Support Package (FSP); any data not measured, such as an ACPI table or SMBIOS table; and any security policy not measured, such as a public certificate or secure boot enable/disable.

4) For the dynamic root-of-trust for measurement (DRTM), check the completeness too. Any DRTM code/data/policy not measured? Does the same measurement happen during S3 resume?

5) For memory protection, check if all memory that should be protected is indeed protected, especially for the special memory regions, such as above–4 GiB memory, below–1 MiB memory, and untested memory . Is all trusted world memory protected? Is all kernel memory protected?

6) For system resource protection, check if all resources that should be protected are indeed protected, including memory mapped I/O, I/O, model-specific registers (MSRs), PCI configuration space, Embedded Controller (EC) configuration, System Management Bus (SMBus), Inter-Integrated Circuit (I2C) bus, Serial Peripheral Interface (SPI) bus, and so on.

Break the recovery process.

1) Try to delete the golden recovery image.

2) Try to modify or replace the golden recovery image with a malicious one.

Trigger manufacturing mode.

1) Try to see if any protections can be disabled in manufacturing mode, including but not limited to secure boot, measured boot, user authentication, UEFI variable protection, and so on.

Break other advanced protections.

1) Try to disable DMA protection or downgrade the DMA protection level, for example, via a setup option or a UEFI variable.

2) Try to disable the kernel hardening policy, such as address space layout randomization and data execution protection.

Replay/rollback

Roll back the firmware code.

1) Try to roll back to an older firmware image with a smaller secure version number (SVN) during the firmware update process.

2) Roll back to an old firmware image with a smaller SVN during SPI flash update to see if it can be detected by the secure boot process.

3) Try to roll back the golden recovery image to a version with a smaller SVN.

Roll back the firmware configuration.

1) Try to roll back to some insecure older system configuration data during the configuration data update process.

2) Roll back to some insecure older system configuration via a direct SPI flash update to see if it can be detected.

3) Trigger a special boot mode, such as recovery or manufacturing mode, to see if the configuration is rolled back to an insecure one, such as an older secure boot key.

4) Capture old configuration data and replay this older configuration data at a later time.

Cryptography

Fuzz the input.

1) Fuzz the digital signature, including malformed signatures and the case of no signature. A certificate fuzzing tool can be used for cryptographic encodings, such as X.509 certificate , Abstract Syntax Notation One (ANS.1), Concise Binary Object Representation (CBOR), and so on.

2) Fuzz the data structure wrapping the signature, such as PE image before the certificate field, the firmware volume (FV) header before the signed section, and the UEFI capsule header before the Firmware Management Protocol (FMP) capsule auth info.

3) Fuzz the protocol, such as Transport Layer Security (TLS) and Secure Protocol and Data Model (SPDM).

Cryptographic algorithm.

1) Check if a non-cryptographic algorithm is used for the firmware image update and recovery, such as XOR, cyclic redundancy check (CRC), or checksum.

2) Check if the device firmware update uses cryptographic algorithms for verification, including but not limited to the Baseboard Management Controller (BMC) firmware, Embedded Controller (EC) firmware, management engine (ME) firmware, PCI device firmware, memory DIMM firmware, and so on.

2) Check if any deprecated algorithms are used, such as MD5, SHA1, DES, ECC, and P256K1.

3) Check if any non-standard cryptographic algorithm or protocol is used, such as a customized Encrypt-and-MAC (E&M), Encrypt-then-MAC (EtM), and MAC-then-Encrypt (MtE), instead of a standard Authenticated Encryption with Associated Data (AEAD).

4) Check if the key length is large enough.

5) Check if forward security is considered in the key exchange algorithm.

6) Check if the random seed is really uniformly random.

7) Check if the sequence number, counter, nonce value, and initialization vectors are used properly. For example, the sequence number or counter can start with 0. and an initialization vector must be random.

8) Check if the random number generation function is standard one.

Attack the key.

1) Try to steal the private key in memory or NV storage.

2) Try to steal the symmetric key in memory or NV storage.

3) Try to modify the deployed public certificate or its hash without authorization.

5) Try to delete the deployed revocation key without authorization.

6) Try to steal the key in the special boot mode, such as recovery or manufacturing mode.

Downgrade the protocol version and algorithm.

1) Try to negotiate with the entity to downgrade the protocol to a lower and unknown vulnerable version. An implementation might support a legacy version for compatibility considerations, such as TLS 1.0 and TLS1.1.

2) Try to negotiate with the entity to downgrade the algorithm to a deprecated one. An implementation might support deprecated algorithms for compatibility considerations, such as SHA1.

Cryptography usage.

1) Check if the test key is used in production.

2) Check if there is a way to revoke a certificate.

3) Check if the root key is used to encrypt the data instead of the session key .

4) Check if the public certificate chain is verified according to the trusted root certificate or its hash and the revoked certificate or its hash.

5) Check if the validity period of the certificate is verified.

6) Check if the requested hostname is verified according to the common name of the certificate.