0x01 前言

最近 UPnP 比较火，恰好手里有一台 Cisco RV110W，在 2021 年 8 月份思科官方公布了一个 Cisco RV 系列关于 UPnP 的 0day，但是具体的细节并没有公布出来。于是想要用手中的设备调试挖掘一下这个漏洞，漏洞的公告可以在官网 https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cisco-sb-rv-overflow-htpymMB5 看到。

0x02 准备工作

首先将固件更新到最新版本 1.2.2.8，传送门：https://software.cisco.com/download/home/283879340/type/282487380/release/1.2.2.8?i=!pp，接下来面临的一个问题就是如何调试和定位漏洞。

首先解决调试的问题，调试的首要工作就是拿到设备的 shell，不过最新的固件并没有提供调试的接口，笔者这里通过 UART 串口和修改固件包的方式拿到了最新固件的调试权限，具体的方法参考之前写过的一篇文章路由器调试之getshell，可见：https://badmonkey.site/archives/router-debug-getshell

调试准备

Cisco RV110W 是 mipsel 架构，所以需要先找一个对应的 gdb-server,可以自己交叉编译也可以使用别人编译好的，这里推荐 gdb-static-cross，传送门：https://github.com/stayliv3/gdb-static-cross

漏洞定位

官方公告指出漏洞存在于 UPnP 服务中，首先进入后台管理，FireWall 的 Basic Settings 打开 UPnP 的配置

然后 nmap 扫一下端口，并没有发现 UPnP 的端口，但是测试发现 UPnP 的确打开了。

这里笔者使用 UPnPy (https://upnpy.readthedocs.io/en/latest/)进行漏洞的测试和利用。

import socket
msg = 
    b'M-SEARCH * HTTP/1.1rn' 
    b'HOST:239.255.255.250:1900rn' 
    b'ST:upnp:rootdevicern' 
    b'MX:2rn' 
    b'MAN:"ssdp:discover"rn' 
    b'rn'

# Set up UDP socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
s.bind((b"192.168.2.100",23333)) #本机IP
s.settimeout(2)
s.sendto(msg, (b'239.255.255.250', 1900))
addr = ('192.168.2.1', 1900) # 网关IP
try:
    while True:
        data, addr = s.recvfrom(65507)
        print(addr,data)

except socket.timeout:
    pass

发现确实得到了 UPnP 的响应，而且在设备的进程中存在对应的 UPnP 进程

服务分析

UPnP 是一种通用的协议标准，厂商大多按照标准实现,即很多 action 都是一致的，但是也有必要对设备提供的服务进行分析以便于漏洞的定位和利用，同样使用 UPnPy 进行信息的收集

import upnpy
import socket

import requests
from upnpy.ssdp.SSDPDevice import SSDPDevice
msg = 
    b'M-SEARCH * HTTP/1.1rn' 
    b'HOST:239.255.255.250:1900rn' 
    b'ST:upnp:rootdevicern' 
    b'MX:2rn' 
    b'MAN:"ssdp:discover"rn' 
    b'rn'

# Set up UDP socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
s.bind((b"192.168.2.100",23333))
s.settimeout(2)
s.sendto(msg, (b'239.255.255.250', 1900))
addr = ('192.168.2.1', 1900)
data = b""
try:
    while True:
        data, addr = s.recvfrom(65507)
        print(addr,data)
except socket.timeout:
    pass

# data = b'HTTP/1.1 200 OKrnCache-Control: max-age=120rnDate: Fri, 01 Jan 2010 00:44:16 GMTrnExt: rnLocation: http://192.168.2.1:1780/InternetGatewayDevice.xmlrnServer: POSIX UPnP/1.0 linux/5.70.48.16rnST: upnp:rootdevicernUSN: uuid:31474a87-67ea-dae4-2f73-f157fb06d22b::upnp:rootdevicernrn'
# data = b'HTTP/1.1 200 OKrnCache-Control: max-age=3600rnST: upnp:rootdevicernUSN: uuid:824ff22b-8c7d-41c5-a131-8c3bad401726::upnp:rootdevicernEXT:rnServer:  Unspecified, UPnP/1.0, UnspecifiedrnLocation: http://192.168.3.1:56688/rootDesc.xmlrnrn'

device = SSDPDevice(addr, data.decode())
services = device.get_services()

services_id = [services[i].id.split(":")[-1] for i in range(len(services))]

for id in services_id:
    service = device[id]
    actions = service.get_actions()
    for action in actions:
        for argument in action.arguments:
            print(id,action.name,argument.name)

可以得到一系列的服务信息，部分信息如下

WANIPConn1 AddPortMapping NewRemoteHost
WANIPConn1 AddPortMapping NewExternalPort
WANIPConn1 AddPortMapping NewProtocol
WANIPConn1 AddPortMapping NewInternalPort
WANIPConn1 AddPortMapping NewInternalClient
WANIPConn1 AddPortMapping NewEnabled
WANIPConn1 AddPortMapping NewPortMappingDescription
WANIPConn1 AddPortMapping NewLeaseDuration
WANIPConn1 DeletePortMapping NewRemoteHost
WANIPConn1 DeletePortMapping NewExternalPort
WANIPConn1 DeletePortMapping NewProtocol
WANIPConn1 GetExternalIPAddress NewExternalIPAddress

这些服务大致可以分为 get 类和 set 类，以及少数的 delete 类服务。由于 UPnP 的主要目的之一是将内网设备暴露给公网设备，这就需要进行一定的配置(端口映射等)，既然需要配置，那么配置的参数和信息必不可缺，而这些参数其实就是 set 类服务中的参数。

服务定位

由于并不是所有服务，厂商都有实现，因此需要自己逆向一下固件。首先定位到upnp_mainloop

所有的处理逻辑都是在 upnp_dispatch 中实现的，跟进分析发现了存在 ssdp 和 http 的请求处理部分

ssdp_process对应寻址时 M-Search 的请求，upnp_http_process 对应 http 请求的处理，由于正常的服务调用都是 http 请求，因此判断upnp_http_process可能存在漏洞，服务调用示例如下图所示

在upnp_http_process中进一步调用了upnp_http_fsm_emgine

跟进分析，发现会执行 off_45ab80 处的几个函数

这些函数包括了初始化和解析协议头的功能，最后一个函数为upnp_http_fsm_dispatch ,猜测会执行对应的服务函数。

跟进upnp_http_fsm_dispatch ，发现确实调用了函数方法，不过是根据 a1 和 a2 执行的函数调用，无法确定具体的被调用函数，需要动态调试。

如果是正常的 ssdp 寻址请求那么会调用SUB_405B34,description_process ,如果是服务相关请求，会调用soap_process ,在soap_process中根据请求头信息，调用query_process或者action_process

主要关注action_process,根据服务调用的请求头，猜测action_process中的soap_control对应服务调用

在 soap_control 中仍然需要动态调试，确定具体的函数信息。

最终经过动态调试确定sub_414C28 对应AddPortMapping action，其函数调用链为

sub_414c28->upnp_portmap_add->upnp_osl_nat_config->strcpy(stack overflow)

不过在 upnp_portmap_add 中检查了一下本机的 wan 口地址，由于笔者在测试的时候并没有配置 wan 口，所以直接用 nvram 设置了一下 wan 口 ip。

栈溢出的时候需要控制程序流走到红色的方块中，因为蓝色方块的函数会访问被溢出的栈导致程序在 RCE 之前崩掉，因此需要控制 *(a2+11) 的值为 0，幸运的是此处的值是可控的

0x03 漏洞利用

由于最新固件没有 telnetd，可以反弹 shell 然后自己上一个 utelnetd，然后开启 telnet