C Labs
Explore 2 labs in C.
The firmware does not properly verify the cryptographic signature of firmware images before execution. If it accepts unsigned, tampered, or incorrectly signed firmware, an attacker may be able to bypass the device’s security and execute unauthorised code at startup. This undermines the root of trust for the device, allowing malicious firmware to persist below the operating system or application layer and potentially evade higher-level security controls.
In an industrial or OT environment, this weakness can have severe consequences because compromised firmware may alter device behaviour, disable safety controls, manipulate telemetry, or provide long-term attacker persistence. Secure boot should fail closed when firmware authenticity cannot be verified.
Implement strict cryptographic signature verification before loading or executing firmware. Validate the firmware image against a trusted public key or certificate chain, reject unsigned or invalidly signed firmware, and halt or update process safely if verification fails. Private signing keys should be protected, and test cases should confirm that modified, unsigned, or incorrectly signed firmware is never executed.
Select a language to explore available labs for this vulnerability.
Try adjusting your language filter.
Want to skill-up in secure coding and AppSec? Try SecDim Wargames to learn how to find, hack and fix security vulnerabilities inspired by real-world incidents.
Join our secure coding and AppSec community. A discussion board to share and discuss all aspects of secure programming, AppSec, DevSecOps, fuzzing, cloudsec, AIsec code review, and more.
Read more