Full Report
MicroTik recently added the ability to containerize application running on their routing. This is the functionality being targeted in this attack. An interesting feature is allowing for mount points between the host and the container. For instance, if you wanted to allow the /etc folder on a disk into a container, the command would look like the following: /container/mounts/add name= src=disk1/etc dst= . The author realized a few flaws in this. First, paths are resolved through symbolic links. This means that the directory was being resolved prior to the mounting process. Second, symbolic links are resolved from the hosts root instead of the container root for both the src and dst parameters. Using this facts, many horrible things can be done. First, when performing the mounting of a drive in the container, we can mount arbitrary locations. For instance, we can mount into an arbitrary directory by using symlinks. This should be easy to exploit then, right? The mounts are created with nosuid, nodev and noexec permissions. Practically, this means that even if a binary or shared library was overwritten, it wouldn't matter because of these permission. The executor would simply get "permission denied". Config files would be a good target because of this; but the author couldn't find anything helpful. The author discovered that symlinking existing on the noexec file system but pointing to binaries outside of the filesystem would still be executed. The containers root file system does not have the noexec, which is helpful. So, they created a mount point over an existing binary, such as telnet to create a symbolic link. This link then pointed within the executable part of the container. Now, the next time telnet was ran, it was executed to give the author a reverse shell. This gives arbitrary code execution on the device from within the context of the container. In order to fix this, I assume some patching with the symbolic links was done. Overall, awesome post with very useful explanations.
Analysis Summary
# Vulnerability: MikroTik RouterOS Container Breakout via Symlink Mounts
## CVE Details
- **CVE ID:** CVE-2022-34960
- **CVSS Score:** 9.8 (Critical)
- **CWE:** CWE-59 (Improper Link Resolution Before File Operation), CWE-22 (Improper Limitation of a Pathname to a Restricted Directory)
## Affected Systems
- **Products:** MikroTik RouterOS v7
- **Versions:** Vulnerable from 7.4beta4 up to (but not including) 7.4beta5 / 7.4 Stable.
- **Configurations:** Systems where the `container` package is installed and support for Docker-style containers is enabled (ARM, ARM64, and x86 architectures).
## Vulnerability Description
The vulnerability stems from three implementation flaws in how MikroTik handles container mount points:
1. **Unsafe Path Resolution:** Paths are resolved through symbolic links prior to the mounting process.
2. **Path Traversal via Host-Root Resolution:** Symbolic links within the container's filesystem are resolved relative to the **host's root** instead of the container's root. This allows a user to create a symlink inside a container (e.g., `ln -s / /rootfs`) that points back to the host device's entire filesystem.
3. **Symmetric Vulnerability in Source and Destination:** Both the `src` and `dst` parameters of the `/container/mounts/add` command resolve symlinks.
By combining these, an attacker can designate a destination (`dst`) on the host system that is actually a symlink pointing to a sensitive system binary.
## Exploitation
- **Status:** PoC Available / Documented.
- **Complexity:** Medium (Requires knowledge of RouterOS internals and container management).
- **Attack Vector:** Local (Requires the ability to configure/add containers and mounts on the RouterOS device).
- **Technical Bypass:** While mount points are created with `noexec` (preventing direct execution of overwritten binaries), the researcher discovered that mounting a **symbolic link** over a system binary (like `/nova/bin/telnet`) redirects execution to a malicious binary located in a writable, executable part of the container's persistent storage.
## Impact
- **Confidentiality:** High (Full access to host filesystem).
- **Integrity:** High (Ability to overwrite or redirect system binaries).
- **Availability:** High (Potential for system bricking or service disruption).
- **Result:** Full Arbitrary Code Execution (RCE) on the host RouterOS device with root privileges.
## Remediation
### Patches
MikroTik has patched this issue in the following versions:
- RouterOS **7.4beta5** (Testing)
- RouterOS **7.4** (Stable)
- RouterOS **7.5beta1** and higher.
### Workarounds
- **Disable Containers:** If not required, uninstall or disable the "container" package.
- **Access Control:** Strictly limit access to the RouterOS management interface and the ability to run `/container` commands to highly trusted administrators.
## Detection
- **Indicators of Compromise:**
- Presence of unexpected mount points in `/container/mounts`.
- Unexplained symbolic links within container storage directories pointing to system paths like `/flash`, `/nova/bin`, or `/etc`.
- Unexpected network connections (reverse shells) originating from the router.
- **Detection methods:** Audit the output of `/container/mounts/print` and check for `src` or `dst` parameters referencing symlinks created within the container filesystem.
## References
- **Vendor Advisory:** hxxps://mikrotik[.]com/download/changelogs
- **Technical Write-up:** hxxps://blog[.]nns[.]ee/2022/08/05/routeros-container-rce/
- **NVD Entry:** hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2022-34960