COMMON ATTACK PATTERN ENUMERATION AND CLASSIFICATIONLive MITRE record

CAPEC-680

Exploitation of Improperly Controlled Registers

An adversary exploits missing or incorrectly configured access control within registers to read/write data that is not meant to be obtained or modified by a user.

Abstraction

Detailed

Typical severity

High

Likelihood of attack

Medium

Understand the attack

What is this attack pattern?

An adversary exploits missing or incorrectly configured access control within registers to read/write data that is not meant to be obtained or modified by a user.

Extended description

Hardware systems often utilize trusted lock bits to prevent a set of registers from being written to or to restrict a register to only being written to once. Registers are also frequently used to store sensitive data leveraged in additional security operations, such as secure booting, authenticating code, device attestation, and more. However, the access control mechanisms meant to protect these registers may be fully missing or ineffective due to misconfiguration. If an adversary is able to discover improper access controls surrounding registers, it could result in the adversary obtaining sensitive data and/or modifying data that is meant to be immutable. This can ultimately result in processes like secure boot being circumvented or in protected configurations being modified.

Requirements

What does the attack require?

Prerequisites

  • Awareness of the hardware being leveraged.
  • Access to the hardware being leveraged.

Skills required

  • High: Intricate knowledge of registers.

Resources required

Not stated in the MITRE record.

Impact

What does a successful attack lead to?

Modify Data

Affected scopes: Integrity

Read Data

Affected scopes: Confidentiality

Defence

How is it prevented and mitigated?

1
Design proper access control policies for hardware register access from software and ensure these policies are implemented in accordance with the specified design.
2
Ensure security lock bit protections are reviewed for design inconsistencies and common weaknesses.
3
Test security lock programming flow in both pre-silicon and post-silicon environments.
4
Leverage automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros.
5
Ensure that measurement data is stored in registers that are read-only or otherwise have access controls that prevent modification by an untrusted agent.

Real world

MITRE example instances

Example instance 1Detail
During a System-on-Chip's (SoC) secure boot process, the code to be authenticated is measured to determine the code's validity. This entails the one-way hash of the code binary being calculated and extended to the previous hash. The value obtained after completion of the boot flow is then stored in a register with the intent of later verifying this value to determine if the boot flow has been tampered with. However, the register being used does not prevent an adversary from modifying the register's contents, which can result in the adversary spoofing the measurement data used in the attestation process.