Advisory: Cisco RV34X Series - Authentication Bypass and Remote Command Execution

In early 2021, we reported a few security issues to Cisco related to their RV34X series of routers, two of which have been recently patched. The issues in question were an authentication bypass and system command injection, both in the web management interface. These can be chained together to achieve unauthenticated command execution. Cisco , and assigned CVE IDs as follows: The issues have been fixed in firmware version 1.0.03.21 in the RV34X series. Cisco has noted that the RV26X and RV16X series are also affected by the authentication bypass issue, and has released firmware version 1.0.01.03 to address this. This post contains a root cause analysis for these bugs. Enjoy! [caption id="attachment_4060" align="aligncenter" width="719"] © Cisco[/caption] While Cisco has noted that this issue affects other devices, I'll only go over the specifics of how it affects the RV34X series here. On RV34X devices, the web management interface is served by  on port 443.  is configured (by files in ) so that requests made to the URIs ,  and  are all passed to a CGI binary called . Depending on which URI is requested, the behavior of  is slightly different. In firmware revisions earlier than 1.0.3.20, there was no real attempt to restrict access to these -related endpoints. In fact, a set of command injection issues from late 2020 affecting the RV34X series were initially disclosed as post-authentication issues but later revised to reflect the fact that these could be exploited pre-authentication (after a very charitable and publicly-uncredited researcher - cough cough - tipped off the Cisco PSIRT). These were tracked by the ZDI as  and , and you can see the . While the ZDI advisories have not been updated and still show the initial lower CVSS rating – the Cisco advisory and CVSS scores have been updated to reflect the pre-authentication nature of the bugs. In 1.0.03.20, an authentication check was implemented. This was written into configuration, which you can see here: The attempt here appears to be to check that some  header is set, and/or that a file exists in the  folder with the same name as the request  cookie. Then a user is assumed to be authorized. Unfortunately, there’s a fatal flaw in this fix. The logic is such that  would set  to “0”. So, sending literally  valid-looking  header as part of a request to  will bypass the authorization check. Once we have bypassed authentication, it’s then possible to interact directly with the  endpoint. Requests made to this endpoint are passed directly to the  binary by the  CGI configuration. Within the  function in , the  environmental variable is read, and the value from the  cookie is extracted using a simple series of  and . This specific -reading logic is notable because, due to the  call, it’s not possible to use “;” characters in any injection, as it will prematurely terminate the injection string. In pseudocode, it looks like this: Because our HTTP request is made to the  URI, the  function in  calls a function at , which I’ve named . This function takes a pointer to the  cookie value as its first argument. It also takes several other arguments, each of which are populated by the multipart request parsing that takes place in the  function. The names I’ve given these arguments roughly align with the names of the parameters that this multipart ingesting logic looks for. Within , a  command is constructed with a call to , the resulting buffer of which is then passed directly to : The  cookie value that we have passed in our request is passed directly into this  call. With a crafted  value, we would therefore be able to inject arbitrary commands into this command buffer. This will run the command with the privileges of the  binary which, in this case, is . Logic bugs can be quite easy to introduce, and sometimes tricky to identify. Authentication can be difficult to implement well, especially when multiple authorization methods might be accepted. As higher-end embedded devices start to use more common server software components (for purposes they were not necessarily intended for), there are often more layers of complexity introduced - thicker web servers requiring more precise configuration, CGI binaries, middleware gluing things together. Each layer introduces opportunities for mis-configuration, which could lead to security issues.