Blog

Four vulnerabilities were identified and used to successfully exploit a Cisco RV340 on the Local Area Network (LAN) side of the router during the Austin pwn2own competition in November 2021. The vulnerabilities for CVE-2022-20705 and CVE-2022-20707 were found by multiple entrants, including us, while CVE-2022-20700 and CVE-2022-20712 were unique to our entry. The vulnerabilities used are as follows:

• CVE-2022-20705 - Improper Session Management Vulnerability
• CVE-2022-20707 - Command Injection Vulnerabilities
• CVE-2022-20700 - Privilege Escalation Vulnerabilities
• CVE-2022-20712 - Upload Module Remote Code Execution Vulnerability

The following 9 models of Cisco devices are effected by both CVE-2022-20700 and CVE-2022-20705: RV160, RV160W, RV260, RV260P, RV260W, RV340, RV340W, RV345 and RV345P. The following 4 models of Cisco devices are effected by both CVE-2022-20707 and CVE-2022-20712: RV340, RV340W, RV345 and RV345P. More details can be found in the Cisco advisory.

This blog post details the vulnerabilities as used during pwn2own against a vulnerable Cisco RV340 device.

Introduction

By chaining several vulnerabilities, we can exploit a Cisco RV340 to achieve remote root privileges on the LAN side. We target the web server which provides the administration portal, it runs via a NGINX server listening on port 80 for HTTP and port 443 for HTTPS connections. We leverage an authentication bypass vulnerability and a logic issue to reach a command injection vulnerability. The webserver runs as user www-data, so we also chain an elevation of privilege vulnerability to elevate from www-data to root privileges. 

To follow along with this report you can download the firmware image RV34X-v1.0.03.22-2021-06-14-02-33-28-AM.img from the Cisco website. The firmware file format is a u-boot legacy uImage and can be extracted on a Linux machine using the dumpimage tool from the u-boot-tools package. Contained in the image is a UBIFS filesystem that can be extracted using the ubidump tool. Running the following commands will extract the required files from the firmware:

A folder “rootfs” will be created which contains the files described in this report.

Improper Session Management (CVE-2022-20705)

Command Injection (CVE-2022-20707)

Privilege Escalation (CVE-2022-20700)

Upload Module Remote Code Execution (CVE-2022-20712)

A remote pre-authentication buffer overflow vulnerability was identified in the Universal Plug and Play daemon (upnpd) shipped and enabled by default in multiple NETGEAR products. This vulnerability was used to successfully exploit a NETGEAR R6700v3 on the Local Area Network (LAN) side of the router during the Austin pwn2own competition in November 2021.

The following 22 models of NETGEAR devices are affected: D6220, D6400, D7000v2, EX3700, EX3800, EX6120, EX6130, R7100LG, R6400, R6400v2, R6700v3, R6900P, R7000, R7000P, R7850, R8000, R8500, RS400, WNDR3400v3, WNR3500Lv2, XR300, DC112A. More details can be found in both the NETGEAR advisory and the Zero Day Initiative advisory.

This blog post details both the vulnerability and exploitation technique as used during pwn2own against a vulnerable R6700v3 device. 

Introduction

To follow along with this report you can download the firmware image R6700v3-V1.0.4.120_10.0.91.zip from the Netgear website. The firmware image holds a Squashfs filesystem which can be extracted using binwalk by running the following commands:

A folder “squashfs-root” will be created which contains the files described in this report.

To assist in the debugging of the exploit, we will copy a statically linked GDB server onto a USB memory stick which is inserted into the R6700v3 device. We can establish a telnet session to the target device using the telnetenable.py script and attach the GDB server to the target upnpd process, e.g.

We can then connect to this remote GDB server from our development machine as follows:

The Vulnerability

The /usr/sbin/upnpd binary will listen on TCP port 5000 for HTTP requests and TCP port 5555 for HTTPS requests. A POST request to the /soap/server_sa endpoint will be handled by the function at virtual address (VA) 0x0003C784. If this POST request contains a SOAPAction header with the value "urn:NETGEAR-ROUTER:service:ParentalControl:1#Authenticate" the contents of the POST request, which is expected to be in XML format, will be parsed in an unsafe manor as show below.

We can see from the above code highlighted in yellow, that if a NewMACAddress XML tag is found, a call to strncpy will be performed to copy the contents of the NewMACAddress value to a static buffer. The logic of the call to strncpy is wrong, as the length value supplied to strncpy is the length of the attacker supplied source string and not the length of the destination static buffer, which is only 20 bytes. Therefore, if an attacker supplies a NewMACAddress value greater than 20 bytes they can overflow the static buffer and write attacker-controlled data into adjacent memory. Examining the location of the variable GLOBAL_NewMACAddress, highlighted in yellow below, we can see this variable is held in the upnpd binaries .bss section. Therefore, we can overwrite adjacent variables in the .bss section as well as the memory adjacent to the .bss section if it is mapped into the address space as writable.

Of note is the adjacent variable GLOBAL_new_http_passwd, highlighted in pink above. We will leverage this during exploitation.

Exploitation

The R6700v3 device is running a Linux kernel version 2.6.36.4 on ARM. The kernel is configured with randomize_va_space = 1, which randomizes the processes stack and shared libraries but not the main binary or the process heap. The upnpd binary is not built as a position independent executable (PIE). This results in the .bss section being at a fixed address in memory and directly adjacent to the .bss section is the process heap which services allocations from calls to malloc.

The strategy for exploitation will be as follows.

1. Leverage the overflow to target a function pointer in heap memory and overwrite the function pointer with an attacker-controlled value.

2. Leverage the overflow a second time to overflow a variable in the .bss section that holds the value of a password which will be set to the nvram http_passwd entry.

3. Force the upnpd service to call the overflowed function pointer and redirect the flow of execution to a sequence of instructions that will set the nvram http_passwd.

4. With the http_passwd set to an attacker-controlled value, we can log into the admin portal and take full control of the device.

Program Counter Control

As the process heap is directly adjacent to the upnpd image in memory and the heap will not be randomized, we can make some assumptions regarding the layout of the heap. We can rely on many of the early allocations serviced by malloc as having the same address in the processes address space. These allocations occur before the upnpd accepts external network traffic and as such will always be performed in the same order. Of interest to us is how the upnp binary initializes the OpenSSL library (Version 1.0.2h). The upnpd main() function will call a function at VA 0x00025034 to initialize SSL and this will perform a call to SSL_load_error_strings(). This call will perform many heap allocations to generate a hash map of strings that will later be used for generating human readable error strings. A core data structure in this is the _LHASH struct which contains a function pointer “hash” as highlighted in red below.

With some debugging we can discover a _LHASH structure will always be allocated in the heap at a fixed offset of 7500 from the start of the upnpd binaries GLOBAL_NewMACAddress variable in the .bss section. We can therefor leverage the overflow to reliably overwrite this hash function pointer. The next challenge is to discover how we trigger a call to the overwritten function pointer, if we review the OpenSSL source we can see ERR_print_errors_fp will call ERR_print_errors_cb, which will call ERR_error_string_n, which will call ERR_lib_error_string, which will call int_err_get_item, which will call lh_ERR_STRING_DATA_retrieve, which is a macro for lh_retrieve, which calls getrn, which (finally!) calls the hash function pointer from a _LHASH structure on the heap.

With a path to triggering the overwritten hash function pointer, we can see from the upnpd binary that a call to ERR_print_errors_fp exists in upnpd!upnp_main when a HTTPS connection to port 5555 fails to establish the TLS/SSL handshake from the client during SSL_accept.

We can therefore perform an invalid HTTPS connection to TCP port 5555 after we perform the overflow to gain control of the processes program counter (PC) register. To demonstrate this, we can issue the following two curl commands, the first to perform the overflow and the second to trigger a call to the overwritten function pointer and gain PC control.

If we have GDB attached, we can see the following, the four D characters from the overflow are highlighted in yellow.

If we investigate the address in the back trace which transfers control to our attacker-controlled value, via a “blx r3” instruction, we can verify this originates from /lib/libcrypto.so.1.0.0!lh_retrieve (The compiler must have chosen to inline getrn).

Target Function Gadget

Now we can control the flow of execution we must choose what to do with this. As the GLOBAL_NewMACAddress variable we overflow is adjacent to a variable (Which we will call GLOBAL_new_http_passwd) used to change the password of the http admin, we will investigate this further. We can see below in yellow, that upnpd!func_0x289C8+0x10 will use the GLOBAL_new_http_passwd variable to set the http_passwd in the routers nvram configuration via a call to acosNvramConfig_set.

We can examine the disassembly of the call which begins at VA 0x00028A74. The two parameters are set in the registers r0 and r1 before a call to acosNvramConfig_set is performed.

If we use the overflow vulnerability to overwrite the target _LHASH::hash function pointer with a value of 0x00028A74 (upnpd is not built with PIE so this address is fixed) and then use the overflow vulnerability a second time to overwrite the value of GLOBAL_new_http_passwd with a password value of the attackers choosing, we can redirect the flow of execution to change the password by performing an invalid HTTP connection to TCP port 5555. We can rely on the vulnerable function at upnpd!func_0x3C784 to null terminate the GLOBAL_NewMACAddress variable during the overflow which allows us to write a value that contains a null byte. (We can note that the 0x00028A74 address we want to write contains a null byte and on a little endian device this will be the null terminator charachter that is written).

Setting the http_passwd to an attacker controlled value allows us to log into the routers web interface. At this point we have full control of the device, and can leverage telnetenable.py to gain a root shell if required.