CWE-1328: Security Version Number Mutable to Older Versions

How it's found

Security Version Number Mutable to Older Versions is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.

A System-on-Chip (SoC) implements secure boot or verified boot. It might support a security version number, which prevents downgrading the current firmware to a vulnerable version. Once downgraded to a previous version, an adversary can launch exploits on the SoC and thus compromise the security of the SoC. These downgrade attacks are also referred to as roll-back attacks. The security version number must be stored securely and persistently across power-on resets. A common weakness is that the security version number is modifiable by an adversary, allowing roll-back or downgrade attacks or, under certain circumstances, preventing upgrades (i.e. Denial-of-Service on upgrades). In both cases, the SoC is in a vulnerable state.

Consequences

• Other: Impact includes roll-back or downgrade to a vulnerable version of the firmware or DoS (prevent upgrades).

Mitigations

• Architecture and Design: When architecting the system, security version data should be designated for storage in registers that are either read-only or have access controls that prevent modification by an untrusted agent.
• Implementation: During implementation and test, security version data should be demonstrated to be read-only and access controls should be validated.

Where this fits in a TurboPentest engagement

This weakness is not covered by the automated black-box pentest. IntegSec pentesters cover it in a manual engagement.

Frequently asked questions

Related CWEs

• Class weakness
  CWE-285: Improper Authorization
• Base weakness
  CWE-757: Algorithm Downgrade