Hardware-and-Firmware-Security-Guidance - Guidance for the Spectre, Meltdown, Speculative St

项目说明

Hardware and Firmware Security Guidance

Table of Contents

1\. About this Repository

2\. Recommended Actions

3\. Device Configuration Guidance

- 3\.1\. Procurement and Acceptance Testing
- 3\.2\. Firmware Configuration and Hardening
- 3\.3\. UEFI Secure Boot
- 3\.4\. Zero Trust
- 3\.5\. Baseboard Management Controller

4\. Boot

- 4\.1\. PKFail
- 4\.2\. Shim Shady
- 4\.3\. BlackLotus
- 4\.4\. BootHole
- 4\.5\. BootKitty

5\. Firmware

- 5\.1\. LogoFail
- 5\.2\. Lojax

6\. Physical Attack

- 6\.1\. Bitlocker dTPM Probing

7\. Side Channel

- 7\.1\. General Messaging
- 7\.2\. Historical Guidance

8\. Device Integrity

- 8\.1\. TPM Use Cases
- 8\.2\. Reference Integrity Manifest
- 8\.3\. Software Bill of Materials

9\. Hardware Upgrade Guidance

10\. License

11\. Contributing

12\. Disclaimer

1. About this Repository

This repository provides content for aiding DoD administrators in systems ha and enabled mitigations for hardware, firmware, and supply chain . The repository functions as a companion to NSA Cybersecurity Ad such as Cybersecurity Ad and Guidance. This repository is updated as new information, research, strategies, and guidance are de.

2. Recommended Actions

Updated 12/6/2024 -- Organizations should integrate acceptance testing into their procurement processes. Acceptance testing guards against potential like PKFail and weaknesses in the supply chain.

3. Device Configuration Guidance

3.1. Procurement and Acceptance Testing

Organizations should implement automated acceptance testing into their computing asset procurement processes. Acceptance testing assures that devices are recei tampering during the logistics transportation process, arrive with the expected hardware and firmware components, and are configured for secure integration into the enterprise's infrastructure. NSA recommends procuring devices that feature Trusted Platform Module (TPM), Unified Extensible Firmware Interface (UEFI) Secure Boot, and are preloaded with a Platform Certificate based off of Trusted Computing Group (TCG) standards. More detailed guidance can be accessed via this NSA guidance document.

NSA also recommends organizations monitor Reference Integrity Manifest (RIM), Software Bill of Materials (SBOM), and Security Protocols and Data Models (SPDM). These technologies -- once adopted and deployed by industry -- provide modern mechanisms to audit the hardware, firmware, and software integrity of enterprise computing devices.

3.2. Firmware Configuration and Hardening

Most organizations understand the importance of controlling access to administrati in the operating system en. However, many organizations o the administrati contained within a device's firmware. Most devices ship without a password applied to the Unified Extensible Firmware Interface (UEFI) configuration interface. NSA recommends organizations set a configuration password, restrict boot devices to only those appropriate for their infrastructure, and disable system components unsuitable for the office en. Further guidance designed to harden the firmware security posture can be found at the following links:

UEFI Defensi Technical Report

UEFI Lockdown Quick Guidance

Boot Security Modes

3.3. UEFI Secure Boot

Most enterprise-grade servers, laptops, desktops, and other personal computing devices ship with a preconfigured implementation of Unified Extensible Firmware Interface (UEFI) Secure Boot. The system provides a Platform Key (PK), Microsoft provides a Key Exchange Key (KEK), and 2 additional Microsoft certificates -- the Microsoft Windows Production CA and Microsoft UEFI Third Party Marketplace CA -- are usually loaded into the allow list database (DB). The deny list database (DBX) may include hashes of revoked binaries. This standard implementation is usually sufficient for most use cases when properly configured (UEFI native mode with Secure Boot set to enabled in standard/deployed mode).

NSA has published ad guidance co how to customize UEFI Secure Boot. Customization may include backing up the existing Secure Boot certificates and hashes, creating new certificates and hashes, and loading custom into the PK, KEK, DB, and DBX. Customization also implies that an organization will sign their own bootable binaries. Customization requires significant administrati with the potential benefit of protecting against zero day attacks focused on boot security. The full technical report for customization can be accessed via this link with additional resources contained in the Secure Boot section of this repository.

3.4. Zero Trust

Zero Trust -- a modernized cybersecurity framework -- integrates from multiple points, makes risk-aware access decisions, and automates detection and response. Implementing this framework places network defenders in a better position to secure sensitive data, systems, applications, and services. Device security is a critical pillar of the Zero Trust model. The device pillar builds upon the procurement and acceptance testing, firmware configuration and hardening, and UEFI Secure Boot initiati above by adding automated device in, automated scanning of hardware and firmware and software integrity, automated and patch management, and centralized device appraisal. There are also considerations for decommissioning devices to remo and protected data from devices.

Documentation regarding the Zero Trust device pillar can be found at this NSA document. Additional Zero Trust resources and guidance regarding the other framework pillars can be found via this NSA press release.

3.5. Baseboard Management Controller

Baseboard Management Controller (BMC) is an administrati integrated into a device's hardware and firmware. BMC enables remote management of devices within an enterprise including if the device is powered off or in a low power state. Most BMC implementations contain the same capabilities as firmware configuration interfaces while adding additional features for managing the storage drives, software images, hardware resource allocation, and network connectivity of the device. A compromise of BMC affords malicious actors persistence in a highly pri en. Organizations must secure BMC credentials, limit physical and remote access to BMC, and routinely update BMC firmware -- things easy to o.

NSA has published guidance regarding BMC and hardening methods. BMCs are most commonly found on ser computing hardware. However, they may also be present on workstations and network infrastructure. Organizations should take steps to identify and secure all BMC resources within their networks.

4. Boot

4.1. PKFail

Devices affected by PKFail ship with a test certificate loaded as UEFI Secure Boot's Primary Key (PK). Test certificates are not intended for production use and feature weakly protected keys. An attacker with access to a compromised test key can sign malicious commands capable of poisoning or commandeering the Secure Boot process. A client affected by PKFail will accept the malicious commands. Affected systems may show no indicators of Secure Boot dysfunction with the exception of returning a test certificate when an administrator queries the value of the PK.

Binarly has published extensi into PKFail along with a list of known affected devices. NSA recommends acceptance testing as a mitigation to PKFail. Treat all new devices -- including those not yet listed as affected -- as potentially affected. Check the configuration of UEFI Secure Boot as part of an acceptance testing plan. PKFail is an ongoing concern.

4.2. Shim Shady

Shim is a boot loader used by Linux distributions to extend the Microsoft Secure Boot ecosystem. Shim executes prior to the main bootloader -- usually GRUB. A flaw in Shim allows attackers to perform main-in-the-middle attacks during network boot. Attackers can exploit out-of-bounds to gain arbitrary code execution at boot time. Patches issued in early 2024 fix Shim Shady and other Shim . Systems that rely upon Linux should check that the latest Shim is installed. Windows system owners do not need to perform any action.

A full description of Shim Shady and related can be found posted by Eclypsium. Shim Shady has been mitigated as of Q2 2024.

4.3. BlackLotus

BlackLotus is the name for malware that exploits a named BatonDrop. boot managers for Windows 8, 10, and 11 drop/clear UEFI Secure Boot policy and fail to enforce the normal of boot binaries when given a series of instructions at boot. Malicious actors may substitute their own Secure Boot and make it falsely appear that a system booted securely. Microsoft has issued patches, revoked trust in affected boot managers, and implemented Code Integrity Boot Policy (CIBP) to mitigate the threat.

NSA recommends patching to the latest of Windows to mitigate the threat. Guidance produced prior to complete patching of BatonDrop and BlackLotus can be retrieved from our published BlackLotus mitigation guide. Additional resources are a from operating system , system , and cybersecurity researchers. BlackLotus has been mitigated as of early 2024.

4.4. BootHole

BootHole in a memory exploit triggered by malicious GRUB configuration files. GRUB is a boot loader most commonly utilized for systems that boot a Linux distribution. The malicious configuration file could be utilized to gi arbitrary execution pri at boot time. Affected of GRUB featured UEFI Secure Boot signatures meaning attackers could carry out exploits without encountering resistance from Secure Boot.

Eclypsium has published deeper details about Boothole as well as a list of affected bootloaders. NSA recommends patching to the latest of actively supported Linux distributions. Supported distributions contain patches to mitigate the flaw and update Secure Boot Ad Targeting (SBAT) to prevent execution of boot loaders. Guidance written by NSA near the time of disclosure of BootHole can be found at our published BootHole guide. Boothole has been mitigated as of late 2020.

4.5. BootKitty

BootKitty is a proof-of-concept bootkit designed to execute at boot time and disable signature checking mechanisms within the Linux kernel prior to its initialization. BootKitty is not signed meaning that it is blocked by UEFI Secure Boot. However, BootKitty could be combined with other boot to bypass Secure Boot protection. South Korea's Korea Information Technology Research Institute (KITRI) is credited for de BootKitty.

A deeper dive into how BootKitty works can be found via ESET's report a at this link. Administrators are reminded to check for firmware updates as part of a scheduled routine and that UEFI Secure Boot is configured and operating normally whether in the standard mode or custom mode. BootKitty is not thought to be an acti but may be productized in the future in much the same way BlackLotus appeared as a productized exploit of BatonDrop.

5. Firmware

5.1. LogoFail

Devices affected by LogoFail combine the ability for a user to set a custom boot image with image parsing code. Malicious actors can take ad of the user boot logo customization to gain arbitrary execution at boot time via a malformed image file. Attackers can also le the boot en to gain persistence and defeat several device security solutions. Affected manufacturers ha firmware updates to remove the . NSA recommends device owners routinely check for firmware updates.

Additional resources and technical details can be found on Binarly's LogoFail website. LogoFail has been mitigated as of late 2024.

5.2. LoJax

LoJax is a malicious modification of the legitimate anti-theft software known as LoJack. Both the malicious and the commercial software le a firmware module to establish persistence on computing devices. The legitimate commercial installs an agent to the operating system that reports the device's location and may enable additional features such as remote disablement. The malicious installs a malicious agent to the operating system and obeys commands from known attackers. The agent is difficult to remo it can be restored via the persistent firmware module. Mitigation requires patches to the device firmware which became widely a in early 2019. LoJax was a particularly dangerous threat given that it could bypass UEFI Secure Boot on many systems and restore itself despite inter from anti-malware solutions in the software en.

A full description of LoJax and details about the threat were published by ESET. LoJax has been mitigated since 2019.

6. Physical Attack

6.1. Bitlocker dTPM Probing

Sophisticated attackers with access to physical hardware may be able to defeat Full Disk Encryption (FDE) solutions that le discrete TPM (dTPM) -- defined as a discrete integrated circuit (chip) attached to a device's mainboard and wired into a communication bus. Communications between dTPM and the CPU may be to ea when an attacker places probes on the electrical traces connecting the two components. Software and TPM (vTPM) as well as firmware and integrated TPM (iTPM) are not to this attack.

Microsoft recommends deployment of BitLocker with TPM + PIN enabled as an effecti. A similar solution exists for the Linux ecosystem known as Linux Unified Key Setup (LUKS) TPM2 + PIN. NSA recommends FDEs like BitLocker and LUKS o dri passwords at boot time that can prevent a device from receiving critical updates when not unlocked. Robust physical security and access controls are another effecti strategy. Probing of dTPM communications is an acti.

7. Side-Channel

7.1. General Messaging

Most computing hardware produced since 2021 features hardware mitigations against the worst side channel . have also issued firmware, microcode, and software patches where appropriate to minimize the threat. However, security researchers continue to disco methods of exploiting pre unknown side channels. No specific instructions or guidance is a to combat side channels at this time beyond patch (software and firmware), protect (monitor integrity, limit user access), and purchase (replace systems that are outside support timeframes).

6.2. Historical Guidance

Side-channel , like Spectre and Meltdown, were a focus of this repository in the past. Processor and system ha hardware re and updated firmware to address widely publicized in 2018 and 2019. NSA considers the original guidance no longer applicable to systems produced in 2021 and newer. Historical NSA guidance regarding side-channel can be found here.

8. Device Integrity

8.1. TPM Use Cases

Trusted Platform Modules (TPMs) are components a on modern computing systems and intended to facilitate several cryptographic, protected storage, and integrity capabilities. NSA recommends acquiring TPMs of 2.0 or later on devices that support them to be able to le their security capabilities for current and future use cases.

DoD Instruction 8500.1 requires inclusion of a TPM for DoD devices subject to DISA STIGs when user credentials and data-at-rest require protection. NSA ad for several TPM use cases in addition to those required by STIGs, such as for asset management, hardware supply chain security, and boot integrity measurement. Future use cases for the TPM include software supply chain auditing, runtime integrity measurement, and authentication and pro to support Zero Trust efforts. TPMs should transition to quantum-resistant cryptography to provide the proper capabilities and assurance for these use cases into the future. As TPM-supporting technologies mature and dependencies are satisfied, these recommended and future use cases may become DoD requirements.

The complete NSA cybersecurity information sheet regarding TPM use cases can be found at this NSA link.

8.2. Reference Integrity Manifest

Reference Integrity Manifest (RIM) is a specification de by the Trusted Computing Group (TCG). The goal of RIM is to empower administrators to compare the measurements collected by TPMs on devices to those provided by, signed, and assured as trustworthy by . RIM focuses on firmware and software measured by TPMs making it ideal for assessing the integrity of the boot process for devices.

RIM is a prototype technology currently in de. Check out the TCG's RIM documentation for more details. A proof-of-concept implementation of TPM attestation with RIM support can be found in the Host Integrity at Runtime and Startup (HIRS) project.

8.3. Software Bill of Materials

Software Bill of Materials (SBOM) is a software mechanism for managing the integrity of software running within the operating system. The most common implementation of SBOM today periodically collects measurement hashes from software loaded onto a device and alerts on known outdated or software. Some products have the ability to check the inclusions/dependencies of measured software. The ideal future implementation of SBOM utilizes signed measurement hashes direct from the of software to allow administrators to match up what is running on a device with what the software intended to provide.

SBOM is a relatively new and e technology. Check the Cibersecurity and Infrastructure Security Agency's (CISA) SBOM resource page for more details about SBOM, specifications, use cases, products, deployment, and maintenance.

9. Hardware Upgrade Guidance

NSA does not endorse or promote specific products. See the National Information Assurance Partnership (NIAP) for specific products that have been for compliance to protection profiles endorsed by NSA. The following generic recommendations may also be treated as guidance:
1. Refresh workstations every 3 to 4 years and servers every 5 to 7 years. Look to stay within a 's firmware support timeframe.
2. Prefer processors that carry Intel's vPro branding, AMD's PRO branding, or ARM's Platform Security Architecture (PSA) capability for security capabilities beyond that of consumer-focused processors.
3. Look for devices that include Trusted Platform Module (TPM) 2.0 or later. The TPM may be dedicated/discrete (dTPM) or firmware/integrated (fTPM). ARM devices lacking a TPM may utilize Trust Zone as an alternative.
4. Prefer business and professional-oriented devices o intended for the consumer or gamer/enthusiast markets.

10. License

See LICENSE.

11. Contributing

See CONTRIBUTING.

12. Disclaimer

See DISCLAIMER.

项目信息

开发语言：C

Star 数：877

技术要点

该项目属于漏洞知识库方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Guidance for the Spectre, Meltdown, Speculative Store Bypass, Rogue System Register Read, Lazy FP State Restore, Bounds Check Bypass Store, TLBleed, and L1TF/Foreshadow vulnerabilities as well as general hardware and firmware security guidance. #nsacyber展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。