IoT Security: Real Threat Vectors and OWASP IoT Top 10

Firmware Extraction and Analysis

For an adversary with physical access to the device (or a device discarded in e-waste), extracting the firmware is trivial. An SPI flash clip (e.g., Pomona SOIC-8 clip) connected to a $30 USB logic analyzer or programmer (e.g., CH341A) allows reading the entire contents of the external flash memory chip in minutes, often without even desoldering it from the PCB. Tools like binwalk can then analyze the extracted binary, identifying file system partitions, extracting stored certificates, private keys, hardcoded Wi-Fi passwords, API tokens, and MQTT credentials.

Critical Design Rule: Store your device's certificate private key in hardware-protected storage. Options include:

• The Digital Signature (DS) peripheral on Espressif ESP32 series MCUs, which uses eFuse-protected keys that are never exposed to software.
• An external secure element such as the Microchip ATECC608A, which provides hardware-based key storage and cryptographic acceleration with tamper resistance.
A private key stored in plaintext within unprotected SPI flash is a liability waiting to be exploited. Once that key is extracted, an adversary can indefinitely impersonate your legitimate device to your cloud backend.

Man-in-the-Middle on Unencrypted Connections
If your device sends telemetry data over plain HTTP (port 80) or unencrypted MQTT (port 1883), anyone on the same local network segment, or any compromised router along the network path, can passively read and actively modify that data. This threat vector enables:
• Injection of false sensor readings (e.g., reporting a false high temperature to trigger a cooling system).
• Replay of previously captured commands (e.g., re-sending an "unlock door" command).
• Extraction of authentication tokens passed in clear text.

Transport Layer Security (TLS) prevents this. Proper TLS configuration requires certificate validation, not just encryption. Enabling TLS but accepting any self-signed certificate ("TLS without verification") provides encryption against passive eavesdropping but offers zero protection against an active Man-in-the-Middle (MITM) compromise. The device must validate the server's certificate against a trusted Certificate Authority (CA) or a pre-provisioned public key pinned in firmware.

Insecure OTA Update Channels
The Over-the-Air (OTA) firmware update mechanism is one of the highest-value threat targets in an IoT system. If an adversary can compromise the update channel, they can push malicious firmware to the entire deployed fleet simultaneously. Common vulnerabilities include:
• Update metadata or binaries fetched over HTTP (trivially MITM-prone).
• Firmware accepted from any server (no URL whitelist or validation).
• No cryptographic signature verification on the firmware image (any binary is accepted as valid).
• No anti-rollback protection (allowing an adversary to downgrade a device to an older, vulnerable firmware version with known CVEs).

OWASP IoT Top 10: The Engineer’s Reference: