Command Injection in IoT Web Interfaces
The admin web interface on a router, camera, or gateway is where command injection lives. A diagnostics field that runs a ping, a setup form that sets a hostname, a backup tool that shells out: any of them can hand an attacker the device, because the web server usually runs as root. Here is how the bug looks and how to kill it.
Why It Is Game Over on IoT
On a desktop, command injection gets you the privileges of the web app. On most embedded devices the web server runs as root, so injection is immediate, total control. No privilege escalation step is needed because there is nowhere higher to go.
Finding the Bug
Look for any field whose value plausibly ends up in a shell command. A diagnostics ping is the classic. The payload appends a second command after the expected input:
curl -s 'http://192.168.1.1/diag.cgi' \ --data 'host=8.8.8.8;id'
PING 8.8.8.8: 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=118 time=12.4 ms uid=0(root) gid=0(root)
The ping ran, and then so did id, returning uid=0(root). The device executed an attacker-supplied command as root. From here a reverse shell is one more request away.
Three Injection Hotspots
Where this bug clusters in IoT web interfaces:
Fixing Command Injection
Never build a shell command from user input. Call programs directly with an argument array instead of a shell string, validate input against a strict allowlist, and drop the web server’s privileges so it is not running as root in the first place. Defense in depth means even a missed bug is contained.
Where This Fits
Testing the web interface for injection and proving the impact is a core part of a connected-product penetration test. That testing is the kind of work we do at Berkner Tech.