Case Study: A Router That Shipped the Same Private Key to Everyone
- Home
- Blog
I’m Joe. Firmware work is the least glamorous part of what I do and the part that consistently produces the findings with the widest reach, because a single bad decision inside a router image ships to everyone who bought that model. This is a composite of consumer-router audits I have run, written up so the method is reusable. The details that identify a specific unpatched device are deliberately left out; the pattern is the point.
-
Why I Keep Looking at Consumer Routers
A home or small-office router is the single most privileged device most people own. It sees every DNS query, terminates every connection, and it is almost never patched after the first year. It is also cheap, which means the firmware was built to a deadline. When I audit one I am not looking for exotic memory corruption — I am looking for the shortcuts that get taken when a product has to ship, because those are the bugs that end up in millions of homes at once.
-
Unpacking the Image
The workflow is unglamorous and always the same. Pull the official firmware from the vendor’s support page, run binwalk to identify and carve the sections, mount the SquashFS root filesystem, and then just read. Before any clever analysis I grep the filesystem for the boring things: files named key or pem, base64 blobs in init scripts, hardcoded strings that look like passwords, and every binary that listens on a socket. Most of what I have reported over the years came out of that first pass, not out of a debugger.
-
One Private Key, Every Unit
The filesystem contained an RSA private key in the clear. Not a placeholder, not a development artefact — the key the device actually uses, identical in every unit that ships with that firmware. That single fact collapses the trust model. Anyone who downloads the public firmware image has the key, which means they can impersonate the device, decrypt anything protected with it, and sign things the device will accept. There is no user action that fixes this; the key has to be generated on the device at first boot, and that is a firmware change only the vendor can make.
-
Plaintext Management and an Unauthenticated Protocol
Two more findings stacked on top. The management interface was served without transport encryption on the local network, so administrator credentials crossed the wire in a form anyone on the same Wi-Fi could read. Separately, a vendor debug protocol was listening and accepted commands without any authentication at all. Individually each one is bad. Chained, they mean an attacker who reaches the LAN — a guest, a compromised laptop, a neighbour on a weak Wi-Fi password — does not need to guess anything to own the gateway.
-
Disclosure: Vendor First, Then the Agency
The process matters as much as the finding. Everything went to the vendor’s PSIRT first, with the exact firmware version, file paths, reproduction steps and a suggested remediation for each issue. Where a product is widely deployed or a vendor is slow to respond, I escalate to CISA’s coordinated vulnerability disclosure programme, which is how a related finding of mine — a TV box shipping with Android Debug Bridge exposed on the network — ended up published as CVE-2026-58378 under CISA advisory VA-26-190-03. No technical detail goes public before a fix exists.
-
What Owners Can Do This Week
You cannot regenerate a key the vendor baked in, but you can shrink what it is worth. Install the latest firmware and check for it again quarterly. Turn off remote management and UPnP unless you genuinely use them. Change the default administrator password and the Wi-Fi password, and put guests and IoT devices on a separate SSID so a compromised smart plug is not sitting on the same LAN as the management interface. If the model is out of support and the vendor has stopped shipping fixes, replace it — an unpatched gateway is not a device you can compensate for elsewhere.
-
What Vendors Should Change
Generate device keys on first boot, never in the build. Encrypt management traffic even on the LAN, because “local network” stopped meaning “trusted” a long time ago. Ship debug and manufacturing interfaces disabled in production images, not merely undocumented. And publish a security contact that answers — the slowest part of most disclosures I run is not writing the report, it is finding a human at the vendor who is allowed to receive it.
Comments (5)
-
netops_hana 2 days ago ReplyThe "generate keys at first boot" line should be printed on the wall of every embedded team. We found the exact same pattern in a camera vendor last year.
-
Cameras are worse. At least routers get firmware updates sometimes.
-
-
Separate SSID for IoT was the single highest-value change I made at home, and it cost nothing.
-
Curious how long the vendor took to respond. In my experience that is the whole story.
-
It varies enormously. Some PSIRTs acknowledge in days; others need an escalation path before anything moves. That is exactly why the agency route exists.
-