No SSH To Your Router? Vendor Might Have Things To Hide

The talk looks at why many consumer and business routers ship with firmware that blocks root access, even though most of them are built on OpenWRT or its forks. The presenters explain the usual reasons researchers want root, such as testing exploits on real hardware, running dynamic analysis tools, or customising a device. They then outline where to look first: vendor documentation, recurring and historical bugs, hidden support features, and above all the web management interface.

The middle of the talk focuses on a TP-Link Omada router. An older debug mechanism let anyone derive the root password from the MAC address, and the vendor later replaced it with a challenge-response scheme tied to a private key. A leftover debug-file fallback kept a weaker path alive, and the same key also signs firmware, which makes downgrades impossible. The team turned to the LuCI web interface component instead and found that the vendor had altered the Lua bytecode format in unusual ways. Once they corrected those deviations, they could recover readable source and found a newline-handling flaw in a WireGuard key setting that allowed chained OS commands, though it required authentication first.

The closing live demo showed a related TP-Link device where the same approach produced a root password. The takeaways are that root access is often reachable through documentation, support paths or the web UI, and that vendors who lock down open-source software without contributing back tend to create more security problems.