[remote] Teltonika_RutOS 00.07.06.21

A vulnerability exists in the Teltonika RutOS operating system versions 00.07.06.21, affecting devices like RUT2XX and RUT200 routers. The flaw stems from command injection within the `ipsec.lua` module when handling status requests via the `/api/ipsec/status/` endpoint. An attacker can manipulate the path segments in a GET request to inject arbitrary shell commands by exploiting how the system constructs a command string using the output of the router's internal functions and passing it to `vuci.util.exec()`. The injection mechanism relies on specific construction within `logread -e` and the lack of proper quoting mechanisms for user-supplied input, allowing semicolon-separated commands to be executed with root privileges.
The vulnerability allows for arbitrary command execution as root by leveraging reflected output in the HTTP response data. This is demonstrated through both a self-contained proof of concept that executes a command and reflects its output, and an exploit mechanism designed to interact with a live device over HTTP, requiring prior authentication via a session token obtained through the standard login process. The flaw targets specific parts of the management plane's interaction with low-level system execution functions.

* The vulnerability affects Teltonika RutOS versions 00.07.06.21, targeting RUT2XX / RUT200 routers.
* The vulnerability resides in the `ipsec.lua` module when handling the `instancesstatus()` function, specifically via the `/api/ipsec/status/` endpoint.
* The injection occurs by manipulating path segments in the URL to influence the command constructed for execution.
* The mechanism involves using specific inputs (e.g., `;;echo '`) to break out of quoted arguments and introduce new commands separated by semicolons.
* The affected component uses `vuci.util.exec()`, which relies on `/bin/sh -c` execution, leading to arbitrary command execution.
* The command injection can be reflected in the HTTP response data under the `.logs` field.
* Arbitrary command execution occurs with root privileges because the underlying uhttpd process runs without user-dropping.
* A sibling sink exists in `openvpn.lua`, which shares the same root cause.
* Verification involves running a command like `id` and observing its output reflected in the response JSON.

The pattern observed is a classic example of insufficient input validation leading to system-level control, specifically exploiting ambiguity in shell command construction within a custom application layer. The core driver here is the failure to recognize that user-controlled string segments are being concatenated directly into a sensitive execution context without sufficient sanitization across multiple functions (`populateendpoint` and `instancesstatus`). This points toward a systemic design flaw where internal system calls implicitly trust data derived from external input, especially when reflection is involved. The existence of the sibling sink in `openvpn.lua` suggests that this class of vulnerability is not isolated to one service module but represents a recurring weakness across the routing stack, indicating a potential architectural oversight in privilege separation or command execution handling throughout the RutOS firmware.
The implications center on the inherent risk of running system commands with elevated privileges based solely on API interaction, even when seemingly restricted endpoints are used. The fact that reflection is guaranteed means that post-authentication access grants immediate and complete control over the underlying operating environment, regardless of the perceived security boundaries established by the web interface. The key concern for resilience is not just patching a single file, but understanding how deeply coupled these components are and whether similar unsanitized interactions exist elsewhere in the system.
Bridge Questions: If command execution is possible via this path, what other internal functions or modules might rely on similar insecure concatenation patterns that could be vulnerable to identical injection techniques? Does the presence of multiple, structurally similar sinks suggest a broader pattern of trust boundaries being managed inconsistently across the operating system's exposed services?