dungsocool/cve-2017-11610Analisi passo-passo dell'exploit per CVE-2017-11610 (Supervisord XML-RPC RCE) con analisi della superficie d'attacco, scoperta di traversal dei namespace e tecniche di post-exploitation in un ambiente lab Docker.
Iniziando con ciò che è in esecuzione nell'ambiente. Elenco tutti i contenitori attivi:``` docker ps-a
**La vittima espone una singola porta: `9001`**.
La porta 9001 non è un'applicazione web standard. Consultando il **database delle porte** si scopre che questa porta potrebbe essere associata a **Supervisord** (ETL Service Manager secondo IANA), Tor proxy, o qualche altro servizio interno. Tuttavia, non possiamo trarre una conclusione basandoci unicamente sul numero di porta.
⇒ Eseguo curl direttamente per leggere la risposta e accedo anche all'interfaccia web per raccogliere ulteriori informazioni.```
curl -i http://192.168.3.137:9001/
Analisi della risposta:
Server: Medusa/1.12 e il titolo Supervisor Status→ Confermato che si tratta di Supervisord, non di Tor o altri servizi.
REFRESH, RESTART ALL, STOP ALLSupervisord è un gestore di processi su Linux. Se porta 9001 è esposta in rete senza password, questa è una configurazione pericolosa. Un attaccante potrebbe visualizzare servizi, riavviare/fermare processi e, in determinate configurazioni, sfruttarla per eseguire comandi se dispone dei privilegi per modificare o controllare i programmi gestiti.
Conclusione dell'analisi: Possiamo confermare che il target sta esponendo l'interfaccia di amministrazione di Supervisord in rete sulla porta 9001. Non si tratta di un servizio web standard, ma di un'interfaccia di gestione utilizzata per monitorare e controllare i processi. La possibilità di accedere a questa interfaccia senza autenticazione crea un rischio che un attaccante possa visualizzare lo stato dei servizi gestiti o interagire con essi.
Tuttavia, dobbiamo distinguere tra l'interfaccia utente visibile e il meccanismo di controllo sottostante. Pulsanti come REFRESH, RESTART ALL e STOP ALL non elaborano richieste autonomamente sul frontend; invece, devono chiamare un'interfaccia/backend di Supervisord per recuperare lo stato o inviare comandi di controllo dei processi. Pertanto, dopo aver confermato che la Web UI è esposta, il passo successivo dell'analisi è determinare se l'interfaccia di controllo sottostante esiste dietro la Web UI e se richiede autenticazione.
⇒ Riflessione: Necessità di verificare se l'interfaccia di controllo dietro la Web UI esiste e se richiede autenticazione.
Secondo la documentazione di Supervisor, [inet_http_server] è un server HTTP che ascolta su un socket TCP. Questa interfaccia non è abilitata per impostazione predefinita, dovrebbe essere utilizzata solo in ambienti fidati, non supporta la crittografia e non ha autenticazione predefinita a meno che non siano configurati username/password.
La documentazione indica anche che la porta di [inet_http_server] è utilizzata per ricevere richieste HTTP/XML-RPC; supervisorctl utilizza XML-RPC per comunicare con supervisord tramite questa porta. Ciò corrisponde alla nostra osservazione in laboratorio: il contenitore espone 0.0.0.0:9001->9001/tcp, la Web UI è accessibile senza autenticazione e la versione visualizzata è Supervisor 3.3.2.
Pertanto, dopo aver confermato la Web UI sulla porta 9001, il passo successivo è ispezionare l'endpoint XML-RPC /RPC2. Basandoci sul meccanismo ufficiale di Supervisord, dobbiamo verificare questi obiettivi:
/RPC2 esista.supervisor.getState o system.listMethods.Verificare se l'endpoint è attivo:```
curl -i -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.getState'
http://192.168.3.137:9001/RPC2
Il risultato restituisce `HTTP/1.1 200 OK`, non `401 Unauthorized` o `403 Forbidden`, dimostrando che la richiesta è stata accettata dal server senza credenziali. La risposta è nel formato XML-RPC `<methodResponse>` e contiene `statename=RUNNING` e `statecode=1`, provando che l'endpoint `/RPC2` è attivo e che il metodo `supervisor.getState` è stato eseguito con successo.
**⇒ Riflessione:** La superficie d'attacco non è più limitata all'interfaccia Web, ma si è estesa all'API XML-RPC, dove vengono gestiti i comandi di controllo dei daemon/processi. Da qui, la prossima direzione di analisi è **verificare come Supervisor** gestisce `methodName` in **XML-RPC**, per determinare se il target corrente **mostra il comportamento di CVE-2017-11610**, che risiede nel meccanismo di dispatch/ricerca di questo metodo. Dobbiamo verificarlo per concludere se si tratta di **CVE-2017-11610**.
### **Analisi dell'elaborazione del nome del metodo in XML-RPC**
Nel passaggio precedente, abbiamo chiamato con successo il metodo `supervisor.getState` tramite l'endpoint `/RPC2`. Questo solleva la domanda successiva: quando riceve un `methodName` basato su stringa, come fa Supervisord a mappare quella stringa alla funzione Python interna?
In XML-RPC, i metodi tipicamente utilizzano namespace, ad esempio:
- `supervisor.getState`
- `supervisor.stopProcess`
- `supervisor.getAllProcessInfo`
Logicamente, il server riceve la stringa `methodName`, la divide in base al punto `.` e cerca l'oggetto/funzione corrispondente all'interno dell'handler registrato.
Il pseudo-codice può essere compreso come segue:
```python
# Pseudo-code: method dispatch in XML-RPC
def dispatch_method(methodName):
parts = methodName.split('.')
# parts[0] = namespace (e.g., 'supervisor')
# parts[1] = method name (e.g., 'getState')
handler = get_handler(parts[0])
method = getattr(handler, parts[1])
return method(*args)
``````python
# Pseudo-code simulating the dispatch method concept in XML-RPC
def dispatch(method_name, params):
parts = method_name.split(".") # ["supervisor", "getState"]
obj = registered_handlers[parts[0]] # get namespace "supervisor"
for attr in parts[1:]:
obj = getattr(obj, attr) # lookup the next attribute
return obj(*params) # call the final function
Per i metodi standard come supervisor.getState, questo meccanismo funziona normalmente: il server recupera il gestore supervisor, quindi chiama la funzione getState. Tuttavia, il problema principale di CVE-2017-11610 è che questo meccanismo di ricerca non limita sufficientemente gli attributi che possono essere acceduti. Se un attaccante controlla methodName, può non solo chiamare metodi pubblici come getState, ma anche addentrarsi più a fondo negli oggetti/moduli interni raggiungibili dal gestore supervisor.