• Home
  • /Learn
  • /Reviewing MITRE's Top 12 Most Important Hardware Weaknesses
background image

Blog

Reviewing MITRE's Top 12 Most Important Hardware Weaknesses

certification

The emergence of the Internet of Things (IoT) has elevated embedded software development.  Subsequently, IoT and embedded system security is critical for enterprise, consumers, and even in national critical infrastructure.

When developers design and manufacture IoT devices for market, custom hardware often plays a vital role, especially considering the growing affordability and accessibility of custom chip and integrated circuit (IC) design. Crafting specialized hardware tailored to the unique needs of a particular IoT product offers several advantages. While initial investment in chip design is high, it's often cost-effective in the long run by eliminating the need for unnecessary components and optimizing manufacturing processes.  

However, introducing custom hardware also creates the potential for new vulnerabilities in the hardware and firmware. In this article we will review each of the top 12 hardware weaknesses referenced by MITRE and discuss each in brief detail.

Reviewing the most important hardware weaknesses is a crucial undertaking before the design phase of a product to ensure it is secure out of the box, and avoid triggering a vulnerability disclosure process which could impact a brand's reputation, user-base, future sales, and even impose a cost on human life.

Let's get started:

MITRE's Top 12 Most Important Hardware Weaknesses

Back in 2021, MITRE released their list of most important hardware weaknesses compiled by the Hardware CWE Special Interest Group (SIG). MITRE is the creator of many cybersecurity information including the Common Weakness Enumeration (CWE) catalog, the Top 25 CWE Software weaknesses, top 12 Known Exploited Vulnerability list, as well as the cybersecurity frameworks MITRE ATT&CK, MITRE D3FEND, and Endpoint Detection and Response competition MITRE Enginuity. 

CWE itself, as well as MITRE's lists of top vulnerabilities, share the goal of preventing vulnerabilities at the source - during the planning and design phases. By considering the known sources of security weaknesses at early stages of the product development lifecycle, vendors can release more secure products out-of-the-box. Both internal and external engineers and security testers can use the list below to prepare appropriate product evaluations and reduce the number of vulnerabilities in their products.

  1. Improper Isolation of Shared Resources on System-on-a-Chip (SoC) [CWE-1189]: Several separate resources within a single SoC may be shared to multiplex and support different functions similar to how the "Don't Repeat Yourself" (DRY) principle effects software development. When different components or subsystems within a System-on-a-Chip (SoC) lack proper isolation mechanisms, they may allow unintended interactions or access between them. This can lead to security vulnerabilities allowing escape between multi-tenant environments, unauthorized access to sensitive data or shared resource manipulation [CAPEC-124]. Examples include CVE-2020-8698 and CVE-2019-6260

  2. On-Chip Debug and Test Interface With Improper Access Control [CWE-1191]: An affected chip does not effectively perform access control to verify whether users are authorized to access internal registers and test modes that are available via physical testing or debugging interface such as interfaces commonly used for debugging and testing include JTAG (Joint Test Action Group), SWD (Serial Wire Debug), and ICE (In-Circuit Emulator), or UART (Universal Asynchronous Receiver/Transmitter) among others. When an on-chip debug/test interface lacks proper access control mechanisms, it may allow unauthorized access to attackers. This weakness may be exploited to gain privileged access to the device, compromising its security

  3. Improper Prevention of Lock Bit Modification [CWE-1231]: Lock bits are secure memory locations used to prevent unauthorized modification of critical configuration settings or memory regions. In integrated circuits, device configuration is typically initialized during the boot sequence by trusted firmware or a software module such as a BIOS or bootloader. While lock bits are effective means to prevent access to memory registers, products must prevent the lock bit values themselves from unauthorized modification. Improper implementation can allow attackers to change fundamental device configurations such as the temperature when a device should shutdown

  4. Security-Sensitive Hardware Controls with Missing Lock Bit Protection [CWE-1233]: This weakness refers to security-sensitive hardware controls that lack lock bit protection. However, if the lock bit does not effectively write-protect all system registers or controls that could modify the protected system configuration, an attacker may be able to access the registers and modify the protected configuration. Compared to CWE-1231, CWE-1233 focuses on the absence of lock bit protection for security-sensitive hardware controls rather than an improper implementation of a lock bit. However, the resulting impact is the same as CWE-1231, where security sensitive device configurations may be modified by unauthorized processes

  5. Use of a Cryptographic Primitive with a Risky Implementation [CWE-1240]: Cryptographic primitives are low-level cryptographic algorithms fundamental to higher-level cryptographic algorithms. If a cryptographic primitive is implemented in a risky or insecure manner, such as using a very small number of safe-primes during a Diffie Helmen key exchange, it can introduce vulnerabilities that attackers may exploit to undermine the security of the system. Cryptographic functions should be verified to only include peer-reviewed, standard, proven, and compliant cryptographic functions

  6. Internal Asset Exposed to Unsafe Debug Access Level or State [CWE-1244]: This weakness occurs when internal assets or sensitive information within the chip are exposed to debug access levels or states that are not adequately secured. Unauthorized access during debugging or testing phases can lead to security breaches or leakage of sensitive data. One example is CVE-2019-18827, where JTAG debugging mode can be accessed before the ROM code is executed, allowing an attacker to modify the boot flow and successfully bypass the secure-boot process

  7. Improper Restriction of Software Interfaces to Hardware Features [CWE-1256]: When software interfaces do not properly restrict access to sensitive hardware features such as power and clock management, it may enable unauthorized software to compromise the security and integrity of the system. This weakness may even allow an attacker to remotely perform attacks such as fault injection and side-channel analysis that typically require an attacker to have physical access to the target device. One well known exploit that exemplifies CWE-1256 is the Rowhammer problem [REF-1083] where a software loop to read a particular memory address may result in the corruption of the hardware by changing the value of the targeted memory register

  8. Improper Handling of Overlap Between Protected Memory Ranges [CWE-1260]: If protected memory ranges overlap in an improper manner, it can lead to security vulnerabilities such as unauthorized access to protected data or code execution exploits. Proper management of memory protection mechanisms is essential to prevent such vulnerabilities

  9. Sensitive Information Uncleared Before Debug/Power State Transition [CWE-1272]: Failure to clear sensitive information from memory before transitioning to a debug or low-power state can result in data leakage or exposure. Attackers may exploit this weakness to retrieve sensitive information from the device's memory.

  10. Improper Access Control for Volatile Memory Containing Boot Code [CWE-1274]: Volatile memory containing boot code is critical for the initialization and operation of a device. If access control mechanisms for this memory are improperly implemented or absent, attackers may tamper with the boot process, leading to unauthorized code execution or device compromise

  11. Firmware Not Updateable [CWE-1277]: When firmware is not updateable, it becomes difficult to patch security vulnerabilities or address issues discovered after deployment. This lack of upgradability can leave devices vulnerable to exploitation by attackers, especially if security flaws are discovered post-production

  12. Improper Protection of Physical Side Channels [CWE-1300]: Physical side channels, such as power consumption or electromagnetic radiation, can leak sensitive information about the device's operation. Improper protection mechanisms against these side channels may enable attackers to extract confidential data or cryptographic keys through side-channel attacks

Conclusion

MITRE's Top 12 Most Important Hardware Weaknesses highlights the critical vulnerabilities that can undermine the security of computer systems, including embedded systems and IoT devices used for a variety of use-cases from consumer level products to national critical infrastructure. As custom System on a Chip (SoC) chip and integrated circuit design becomes more accessible, addressing these vulnerabilities at an early stage of development becomes more important for cybersecurity at all levels.

By understanding and mitigating these weaknesses, manufacturers and developers can enhance the security posture of their products and mitigate the risks posed by potential exploits.

Looking for more cybersecurity updates and news? Sign up for our informational zero-spam newsletter.

Sign up for our newsletter

Get the latest blog posts in your inbox biweekly!