Cisco RV110w UPnP stack overflow
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.
Innanzitutto, aggiornare il firmware all'ultima versione 1.2.2.8. 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.
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.
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 per testare e sfruttare la vulnerabilità.
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.
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.
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.
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.
