Advisory: Cisco RV34X Series - Privilege Escalation in vpnTimer

A few weeks ago, , where we outlined the root cause for authentication bypass and remote command execution issues. This week, around the same time: A privilege escalation issue, which could be used in combination with the other two issues to run arbitrary code with root privileges on affected RV34X devices. As embedded devices often run everything with root privileges, it’s relatively uncommon that we have the opportunity to find privilege escalation bugs, so this is a particularly interesting case. In this post, we’ll do a quick root-cause analysis of this bug we found. [caption id="attachment_4060" align="aligncenter" width="719"] © Cisco[/caption] It’s not often that one gets to report a privilege escalation in the embedded security world. So often, everything is running as root, that opportunities for privilege escalation are few and far between. However, on the RV34X series, the server runs as the user. This isn’t particularly useful for an attacker and, as such, a privilege escalation exploit is required in order to run code as root. Luckily, we identified a vulnerable service called , which runs as , and exposes a socket on the local loopback interface (on UDP/9999). This service receives data on this socket and passes it insecurely to a system command string. As such, if an attacker can run lower-privileged code on an RV34X device, they would be able to then send a crafted UDP packet to 127.0.0.1:9999, which will run an arbitrary command with root privileges. is simply a Perl script, which waits for connections on UDP/9999. is the main function of this script, and runs in a loop as follows (with some extraneous code snipped): Highlighted here are the key components. The is read from the socket. is initialized to contain the contents of without the first character (removed with this call to ). The first character of is then checked, to see if it is a “+” character. If it is, the value of is passed to a statement within two separate backtick strings. In Perl, statements within backticks are executed as a system shell command. Since the service is running as root, the command will be run as root. As such, sending a packet to UDP/127.0.0.1:9999 with the content “+;touch /tmp/test;“ will result in command being run, and the file being written to the filesystem by the user. We thought it might be interesting to see if we could quickly figure out how long this bug has been affecting the Cisco RV34X devices. Often, our assumption might be that a script with a 2015-dated copyright string at the top has not been thought about or actively changed since 2015. However, assumptions are always good to challenge. With our API, it’s relatively simple to script a set of GraphQL queries, and spit out a list of file hashes for all version of for all available RV34X firmware images: We can very easily see that between firmware versions 1.0.01.20 (released on the 19th October 2018) and 1.0.02.16 (released 1st January 2019), the script was actually slightly edited. The changes were not significant, mainly adding a function, and fixing a couple of typos: New function and logging lines added. A typo being fixed. But it does illustrate that this script was actively developed in the past couple of years, and that a bunch of small extra functionalities were added. This script may not have necessarily been thought about deeply, but it was certainly not a forgotten relic. This info does also show that this bug in the script has been present since at least the first firmware update package of the RV34X series (February 2017). When implementing different privilege levels, it's always important to follow the principle of least privilege. Does the component need root privileges, or is it possible to run it with a more limited set? In a well-hardened system, an attacker would be hard-pressed to come across a component running as root, which does not absolutely require root privileges. In more complex systems, you may even consider implementing SELinux (well) to provide an even more granular set of permissions to each process. Despite all this, since so many embedded devices run everything with root privileges, it's still heartening to see when privilege separation is at least attempted in a device. Thanks for the challenge, Cisco!