Rooting the USR-G805: A Field Pentest of an Industrial 4G Gateway

The device came up on 192.168.1.1 with telnet on 23, HTTP on 80, and FTP on 21 exposed. Telnet attempts with common embedded defaults failed, but the web UI accepted admin:admin immediately.

For this class of gateway, default credentials are not just poor hygiene. They become an operational risk because many devices are commissioned once and left untouched for years.

The Network Diagnosis feature exposed ping, traceroute, and nslookup operations from the web dashboard. The corresponding API endpoint accepted user input for ping address values.

Semicolon payloads were filtered, but backtick substitution executed. Command output did not render directly, so payloads were adapted into a binary success oracle by making ping receive a valid fallback address on success.

A write-to-temp approach was used to stage command output in /tmp for retrieval once a readable path was confirmed.

Reverse-engineering the syslog download flow revealed that exported files were written to /tmp and served directly by the web server. Firmware analysis later confirmed lighttpd was chrooted to /tmp.

That turned /tmp into a practical exfiltration channel for files generated through command execution, including passwd and shadow data.

The superuser account was usr (UID 0), not root, which explained earlier telnet misses based on common username assumptions.

With command execution in place, BusyBox telnetd was launched on an alternate port using a shell as its login program. That bypassed authentication and yielded an immediate root shell.

Time-to-root from first packet was roughly ninety minutes, without password cracking or physical access.

All MTD partitions were concatenated into a single image and downloaded through the same /tmp web path. The resulting dump was 16 MB and unpacked cleanly.

The writable configuration partition contained sensitive operational data in plaintext, including admin credentials, VPN settings, APN details, SIM PIN data, and DDNS secrets.

Init scripts and config entries showed an always-on cloud process maintaining persistent connectivity to infrastructure hosted in Shanghai, with periodic heartbeats and regional time-source preference.

The behavior was not transparently surfaced in the UI, and available settings suggested the cloud channel was effectively forced on in the observed firmware.

For regulated or critical environments, that has direct compliance and supply-chain implications even before considering exploitability.

The FTP daemon was started with full filesystem write access rather than a constrained directory. Combined with authenticated access, this enables straightforward persistence by writing to startup paths.

Individually, each weakness is severe. In combination, they form a low-friction compromise chain from default web login to root execution, firmware extraction, credential disclosure, and durable persistence.

If this gateway is in active use, immediate segmentation and hardening are warranted while replacement options are evaluated.