Insecure Firmware Updates

Insecure Firmware Updates is a high-severity IoT vulnerability encompassing flaws in how IoT devices receive, validate, and apply firmware updates. Firmware is the foundational software running on IoT devices—it controls all device behavior, security mechanisms, and communication. When the firmware update mechanism is insecure, attackers can inject malicious firmware that gives them complete and persistent control over the device, intercept and modify legitimate updates to include backdoors, or prevent devices from receiving critical security patches.

The firmware update process involves multiple security-critical steps: the device must discover available updates from an authentic source, download the update image over a secure channel, verify the integrity and authenticity of the downloaded image before applying it, safely apply the update without bricking the device, and verify the update was applied correctly. A failure at any step in this chain can be exploited by attackers to compromise the device at the most fundamental level.

Many IoT devices lack any firmware update mechanism entirely, meaning known vulnerabilities can never be patched and devices remain perpetually vulnerable throughout their operational lifetime—which for industrial, building automation, and infrastructure devices can be 10-20 years. Devices that do support updates frequently implement the mechanism insecurely: downloading updates over unencrypted HTTP, failing to verify cryptographic signatures, using weak or hardcoded signing keys, or providing no rollback protection that would prevent reinstallation of vulnerable older firmware versions.

Man-in-the-middle attacks on firmware updates are the most common exploitation technique. When a device checks for updates over unencrypted HTTP, an attacker positioned on the network (through ARP spoofing, DNS hijacking, or rogue WiFi) can intercept the update check and respond with a malicious firmware image, or modify a legitimate update in transit to include a backdoor. Even if the update server URL uses HTTPS, some devices fail to validate TLS certificates, making the HTTPS connection equally vulnerable to interception.

Firmware image analysis and modification is another critical attack vector. Attackers download legitimate firmware images from manufacturer websites, extract the filesystem using tools like binwalk and firmware-mod-kit, modify the firmware to include backdoors, rootkits, or botnet agents, repackage the modified firmware, and distribute it through compromised update servers, supply chain attacks on the manufacturer, or direct upload through device management interfaces. If the device does not verify firmware signatures or uses weak/known signing keys, the modified firmware will be accepted and installed.

Firmware downgrade attacks exploit the absence of anti-rollback protection. Even if a device has been updated to a patched firmware version, an attacker who can trigger a firmware update (through network access, physical access, or management interface compromise) can install an older, vulnerable firmware version that contains known exploitable bugs. This is particularly dangerous because it re-enables vulnerabilities that were previously patched, potentially including remote code execution or authentication bypass flaws that give the attacker persistent device access.

• Persistent device compromise through malicious firmware installation that survives device reboots, factory resets (in some cases), and legitimate update attempts
• Supply chain attacks at scale when firmware update infrastructure is compromised, allowing attackers to distribute malicious updates to thousands or millions of devices simultaneously
• Permanent vulnerability exposure on devices without update mechanisms, which can never receive security patches for discovered vulnerabilities
• Device bricking or denial of service through corrupted firmware updates that render devices non-functional, requiring physical replacement in hard-to-access installations
• Network infiltration through firmware-compromised IoT devices that serve as persistent backdoors, surviving remediation efforts that target software-level infections
• Industrial and critical infrastructure sabotage through modified firmware on PLCs, sensors, and actuators that could alter physical process behavior

1. Implement cryptographic firmware signing using asymmetric cryptography (RSA-2048+ or ECDSA-P256+). Sign firmware images during the build process using a private key stored in a hardware security module (HSM). The device must verify the signature against the corresponding public key (embedded in the bootloader or hardware trust anchor) before installing any firmware update. Reject unsigned or incorrectly signed images.
2. Secure the firmware delivery channel: serve updates exclusively over HTTPS with certificate validation, implement mutual TLS between devices and the update server, and use content delivery networks with integrity verification (SRI hashes). Implement update manifest files signed by the manufacturer that specify expected firmware versions, sizes, and cryptographic hashes.
3. Implement anti-rollback protection using hardware-backed monotonic counters or eFuse-based version counters that prevent installation of firmware versions older than the currently running version. This ensures that once a security patch is applied, the vulnerable firmware version can never be reinstalled.
4. Implement secure boot chain that verifies the integrity of each boot stage: the hardware root of trust verifies the bootloader, the bootloader verifies the kernel, and the kernel verifies the filesystem. If any stage fails verification, the device should refuse to boot and fall back to a recovery mode or known-good firmware image.
5. Support automatic over-the-air (OTA) updates with user notification and consent. Updates should be checked frequently (daily at minimum for security-critical devices), downloaded in the background, and applied during scheduled maintenance windows. Provide a mechanism for emergency security updates that bypass normal scheduling for critical vulnerabilities.
6. Implement A/B (dual-bank) firmware update schemes that maintain two firmware partitions. The update is written to the inactive partition, verified, and then the device switches to the updated partition on reboot. If the update fails verification or the new firmware does not boot successfully, the device automatically rolls back to the known-good firmware in the other partition.
7. Publish a firmware update security policy including: the expected update frequency, the minimum duration of security update support (matching or exceeding the expected device lifetime), the process for reporting and addressing security vulnerabilities, and end-of-life notification timelines. Comply with emerging IoT security regulations that mandate minimum update support periods.

Begin by analyzing the firmware update mechanism. Capture the device's update communication using a proxy or packet capture tool: identify the update server URLs, protocol (HTTP vs. HTTPS), authentication mechanism, and response format. Test whether the device validates TLS certificates by intercepting update traffic with a proxy using a self-signed certificate. Download the update manifest and firmware image directly and examine the packaging format, signature scheme, and verification process using binwalk and firmware analysis tools.

Test firmware integrity verification by modifying a legitimate firmware image and attempting to install it on the device. Methods to test include: flipping a single bit in the firmware image (should be detected by integrity checks), modifying the firmware filesystem content (should be detected by signature verification), removing or replacing the cryptographic signature (should cause installation failure), and creating a completely custom firmware image signed with a different key. Document whether the device rejects modified images, installs them silently, or provides error messages that could guide further attacks.

Test anti-rollback protection by attempting to install an older firmware version through the normal update mechanism and through any manual update interfaces (USB, serial console, TFTP, web upload). Verify that the device rejects firmware with version numbers lower than the currently installed version. Test secure boot by modifying the device's firmware through physical access (JTAG, UART, flash chip extraction) and verifying that the modified firmware is detected at boot time. Use tools like firmwalker and EMBA to perform automated firmware security analysis that checks for common vulnerabilities including hardcoded credentials, known vulnerable libraries, and insecure configurations.