Cisco RV110w UPnP stack overflow
# Analisi Cisco RV110W UPnP 0day
# Prefazione
Recentemente UPnP è diventato piuttosto popolare. Proprio in questo periodo ho tra le mani un Cisco RV110W. Nell'agosto 2021, Cisco ha annunciato pubblicamente un 0day relativo a UPnP per la serie RV, ma i dettagli specifici non sono stati divulgati. Quindi ho voluto utilizzare il dispositivo in mio possesso per eseguire un debug e scoprire questa vulnerabilità. L'annuncio della vulnerabilità può essere visto sul [sito ufficiale](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cisco-sb-rv-overflow-htpymMB5).
# Preparazione
Innanzitutto, aggiornare il firmware all'ultima versione [1.2.2.8](https://software.cisco.com/download/home/283879340/type/282487380/release/1.2.2.8?i=!pp). La prossima sfida è come eseguire il debug e localizzare la vulnerabilità. Per prima cosa risolviamo il problema del debug. Il primo passo per il debug è ottenere una shell del dispositivo. Tuttavia, l'ultimo firmware non fornisce un'interfaccia di debug. L'autore ha ottenuto i permessi di debug dell'ultimo firmware tramite porta seriale UART e modificando il pacchetto del firmware. Per il metodo specifico, fare riferimento a un articolo scritto in precedenza: [Debug del router: getshell](https://badmonkey.site/archives/router-debug-getshell).
## Preparazione per il debug
Cisco RV110W è basato su architettura mipsel, quindi è necessario trovare un gdb-server corrispondente. Può essere cross-compilato autonomamente o utilizzare uno già compilato da altri. Qui si consiglia [gdb-static-cross](https://github.com/stayliv3/gdb-static-cross).
## Localizzazione della vulnerabilità
L'annuncio ufficiale indica che la vulnerabilità risiede nel servizio UPnP. Prima di tutto, entrare nel pannello di amministrazione e nelle Impostazioni di base del FireWall abilitare la configurazione UPnP.
Successivamente, scansionare le porte con nmap; non sono state trovate porte UPnP, ma i test hanno dimostrato che UPnP era effettivamente attivo.
> L'autore ha utilizzato [UPnPy](https://upnpy.readthedocs.io/en/latest/) per testare e sfruttare la vulnerabilità.
>
```python
import socket
msg = \
b'M-SEARCH * HTTP/1.1\r\n' \
b'HOST:239.255.255.250:1900\r\n' \
b'ST:upnp:rootdevice\r\n' \
b'MX:2\r\n' \
b'MAN:"ssdp:discover"\r\n' \
b'\r\n'
# 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 locale
s.settimeout(2)
s.sendto(msg, (b'239.255.255.250', 1900))
addr = ('192.168.2.1', 1900) # IP gateway
try:
while True:
data, addr = s.recvfrom(65507)
print(addr,data)
except socket.timeout:
pass
```
Si è scoperto che il dispositivo rispondeva effettivamente a UPnP e che nel processo del dispositivo era presente un processo UPnP corrispondente.
### Analisi del servizio
UPnP è uno standard di protocollo universale. La maggior parte dei produttori lo implementa secondo lo standard, quindi molte azioni sono identiche. Tuttavia, è comunque necessario analizzare i servizi offerti dal dispositivo per localizzare e sfruttare la vulnerabilità. Anche in questo caso, si utilizza UPnPy per raccogliere informazioni.
```python
import upnpy
import socket
import requests
from upnpy.ssdp.SSDPDevice import SSDPDevice
msg = \
b'M-SEARCH * HTTP/1.1\r\n' \
b'HOST:239.255.255.250:1900\r\n' \
b'ST:upnp:rootdevice\r\n' \
b'MX:2\r\n' \
b'MAN:"ssdp:discover"\r\n' \
b'\r\n'
# 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 OK\r\nCache-Control: max-age=120\r\nDate: Fri, 01 Jan 2010 00:44:16 GMT\r\nExt: \r\nLocation: http://192.168.2.1:1780/InternetGatewayDevice.xml\r\nServer: POSIX UPnP/1.0 linux/5.70.48.16\r\nST: upnp:rootdevice\r\nUSN: uuid:31474a87-67ea-dae4-2f73-f157fb06d22b::upnp:rootdevice\r\n\r\n'
# data = b'HTTP/1.1 200 OK\r\nCache-Control: max-age=3600\r\nST: upnp:rootdevice\r\nUSN: uuid:824ff22b-8c7d-41c5-a131-8c3bad401726::upnp:rootdevice\r\nEXT:\r\nServer: Unspecified, UPnP/1.0, Unspecified\r\nLocation: http://192.168.3.1:56688/rootDesc.xml\r\n\r\n'
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)
```
Si possono ottenere una serie di informazioni sui servizi, alcune delle quali sono:
```
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
```
Questi servizi possono essere approssimativamente suddivisi in servizi di tipo `get` e `set`, oltre a pochi servizi di tipo `delete`. Poiché uno degli scopi principali di UPnP è esporre i dispositivi della rete interna a dispositivi della rete pubblica, è necessaria una certa configurazione (come il port mapping). Poiché è necessaria una configurazione, i parametri e le informazioni di configurazione sono indispensabili, e questi parametri sono proprio quelli nei servizi di tipo `set`.
### Localizzazione del servizio
Poiché non tutti i servizi sono implementati dal produttore, è necessario fare reverse engineering del firmware. Per prima cosa, localizzare `upnp_mainloop`.
Tutta la logica di elaborazione è implementata in `upnp_dispatch`. Analizzando ulteriormente, si trovano le parti di gestione delle richieste ssdp e http.
`ssdp_process` corrisponde alla gestione della richiesta M-Search durante l'indirizzamento, mentre `upnp_http_process` corrisponde alla gestione delle richieste HTTP. Poiché le normali chiamate ai servizi sono tutte richieste HTTP, si presume che `upnp_http_process` possa contenere la vulnerabilità. Un esempio di chiamata al servizio è mostrato nella figura seguente.
All'interno di `upnp_http_process`, viene chiamata `upnp_http_fsm_engine`.
Proseguendo con l'analisi, si scopre che vengono eseguite diverse funzioni in `off_45ab80`.
Queste funzioni includono l'inizializzazione e l'analisi delle intestazioni del protocollo. L'ultima funzione è `upnp_http_fsm_dispatch`. Si ipotizza che esegua la funzione del servizio corrispondente.
Proseguendo con `upnp_http_fsm_dispatch`, si scopre che effettivamente vengono chiamati metodi di funzione, ma sono chiamate di funzione basate su `a1` e `a2`, quindi non è possibile determinare la funzione specifica senza debug dinamico.
Se si tratta di una normale richiesta di indirizzamento ssdp, verrà chiamato `SUB_405B34` o `description_process`. Se si tratta di una richiesta relativa al servizio, verrà chiamato `soap_process`. All'interno di `soap_process`, in base alle informazioni dell'intestazione della richiesta, verrà chiamato `query_process` o `action_process`.
Ci si concentra principalmente su `action_process`. In base all'intestazione della richiesta di chiamata al servizio, si ipotizza che `soap_control` in `action_process` corrisponda alla chiamata al servizio.
All'interno di `soap_control` è ancora necessario il debug dinamico per determinare le informazioni specifiche della funzione.
Alla fine, tramite debugging dinamico, si determina che `sub_414C28` corrisponde all'azione `AddPortMapping`. La sua catena di chiamate è:
```
sub_414c28->upnp_portmap_add->upnp_osl_nat_config->strcpy(stack overflow)
```
Tuttavia, in `upnp_portmap_add` viene controllato l'indirizzo dell'interfaccia WAN del dispositivo. Poiché durante i test l'autore non ha configurato l'interfaccia WAN, ha impostato l'IP WAN direttamente tramite nvram.
Al momento del buffer overflow, è necessario far sì che il flusso del programma vada al blocco rosso, perché la funzione nel blocco blu accederebbe allo stack overflow e causerebbe il crash del programma prima dell'esecuzione del codice (RCE). Pertanto, è necessario che il valore di `*(a2+11)` sia 0. Fortunatamente, questo valore è controllabile.
# Sfruttamento della vulnerabilità
Poiché l'ultimo firmware non ha telnetd, è possibile ottenere una reverse shell e quindi caricare un utelnetd per abilitare telnet.
Fare riferimento a [Posture di reverse shell](https://brucetg.github.io/2018/05/03/%E5%A4%9A%E7%A7%8D%E5%A7%BF%E5%8A%BF%E5%8F%8D%E5%BC%B9shell/)