dungsocool/cve-2018-7600Guida passo-passo di laboratorio per sfruttare CVE-2018-7600 (Drupalgeddon2) RCE in Drupal 8.5.0, che copre l'analisi della superficie d'attacco, il fingerprinting della versione e lo sfruttamento tramite iniezione di Form API.
Inizia elencando i container in esecuzione:
docker ps
Dai risultati di docker ps, il container per questo laboratorio è:
p1/lab09:latest
Questo container espone la porta:
0.0.0.0:8011->80/tcp
Ciò indica che il servizio all'interno del container è in ascolto sulla porta 80/tcp, ed è mappato sulla porta 8011 dell'host.
La porta 80/tcp è la porta standard per HTTP. Pertanto, questo laboratorio target è molto probabilmente un'applicazione web HTTP. Per confermare il servizio web, invio una richiesta HTTP usando curl combinato con l'accesso all'interfaccia grafica della pagina web.
curl -i http://192.168.3.137:8011/
Valutazione della Superficie d'Attacco
Dalla risposta HTTP e dall'interfaccia web, sono state identificate le seguenti informazioni:
Web server: Apache/2.4.25 (Debian) Backend: PHP/7.2.3 CMS: Drupal Versione Drupal: 8.5.0 Percorso di installazione: /core/install.php Porta pubblica: 8011 -> 80/tcp
Queste informazioni fungono da impronte digitali cruciali per correlare con le CVE. In particolare, Drupal 8.5.0 è la versione direttamente correlata a CVE-2018-7600, nota anche come Drupalgeddon2.
Secondo l'avviso ufficiale di Drupal, SA-CORE-2018-002 / CVE-2018-7600 interessa le seguenti versioni:
>= 8.5.0 < 8.5.1
Il target attuale esegue:
Drupal 8.5.0
rientrando quindi nell'intervallo di versioni interessate.
⇒ Pensiero:
A questo punto, la versione Drupal 8.5.0 è una forte evidenza per identificare la CVE sospetta. Ragiono come segue:
docker ps mostra che il Laboratorio espone il servizio HTTP tramite la porta 8011.curl -i restituisce una risposta HTTP valida da Apache/PHP./core/install.php.Drupal >=8.5.0 <8.5.1 è interessato da CVE-2018-7600.Drupal 8.5.0, rendendolo idoneo secondo i criteri di versione per testare CVE-2018-7600.Il target è Drupal 8.5.0 in esecuzione su Apache/PHP. Questa versione rientra nell'intervallo interessato da CVE-2018-7600 secondo l'avviso ufficiale di Drupal. Il passo successivo è verificare le reali condizioni di sfruttamento per accertare se il target può essere soggetto a RCE.
Dal precedente passaggio di impronta digitale, il target mostra chiaramente: Drupal 8.5.0. Secondo l'avviso ufficiale di Drupal, la vulnerabilità SA-CORE-2018-002 / CVE-2018-7600 interessa le versioni core di Drupal:
>= 8.5.0 < 8.5.1. Il target attuale esegue esattamente Drupal 8.5.0, collocandolo nell'intervallo di versioni interessate. Secondo l'avviso Drupal, si tratta di una vulnerabilità di Esecuzione di Codice Remota nel core di Drupal, che potrebbe consentire a un attaccante di sfruttare molteplici vettori d'attacco e portare al compromesso dell'intero sito.
Tuttavia, si può notare che il target reindirizza a /core/install.php e l'interfaccia mostra la schermata di installazione di Drupal. Ciò suggerisce che Drupal potrebbe essere in uno stato di installazione incompleta. Se la configurazione del sito non è stata completata, gli endpoint comuni usati per attivare Drupalgeddon2 come /user/register, /user/password e /user/login potrebbero non funzionare correttamente. Pertanto, è necessario controllare questi endpoint.
curl -i http://192.168.3.137:8011/user/register curl -i http://192.168.3.137:8011/user/password curl -i http://192.168.3.137:8011/user/login
Si può vedere che gli endpoint vengono ancora reindirizzati a /core/install.php
Conclusione:
Il target esegue Drupal 8.5.0, rientrando nell'intervallo di versioni interessato da CVE-2018-7600 secondo l'avviso ufficiale di Drupal. Tuttavia, al momento del test, l'applicazione è in stato di installer e reindirizza continuamente rotte come /user/register, /user/password e /user/login a /core/install.php.
Ciò mostra che gli endpoint comunemente usati per verificare Drupalgeddon2 non sono ancora funzionanti come su un sito Drupal completamente installato. Pertanto, il target attualmente soddisfa solo la condizione di versione ma non soddisfa ancora le condizioni di runtime per dimostrare l'Esecuzione di Codice Remota.
=> Pensiero:
Dobbiamo provare ulteriormente che Drupal nel suo stato di runtime può elaborare le rotte/form vulnerabili, che un attaccante può accedere agli endpoint senza autenticazione, e che i payload di verifica come id possono essere eseguiti con successo.
Sul target attuale, gli endpoint reindirizzano all’installer, quindi il percorso successivo è valutare se la schermata di installazione di Drupal crea una propria superficie d'attacco, invece di concludere immediatamente una RCE Drupalgeddon2.
Dopo aver verificato che gli endpoint di runtime di Drupal come /user/register, /user/password e /user/login sono tutti reindirizzati a /core/install.php, ho proceduto ad analizzare la schermata dell'installer.
Verifica del servizio database a supporto dell'installer
Poiché l'installer di Drupal è attualmente bloccato al passaggio di configurazione del database, ho controllato se i servizi database comuni sono esposti esternamente:
nmap -sV -p 3306,5432,33060 192.168.3.137
Il target attualmente espone l'installer di Drupal esternamente, ma non sono stati rilevati servizi database accessibili direttamente dalla macchina attaccante.
Conclusione: Il laboratorio espone l'installer di Drupal 8.5.0 e presenta una divulgazione di informazioni riguardanti la versione vulnerabile. CVE-2018-7600 è un vettore sospetto valido, ma non è ancora stato provato lo sfruttamento con successo.
CVE-2018-7600 sfrutta una vulnerabilità nella Form API di Drupal - il sistema di rendering dei form che utilizza la struttura Render Array. Durante l'elaborazione di una richiesta AJAX, Drupal usa il parametro element_parents per individuare gli elementi nell'albero del form senza verificare (sanitizzare) le chiavi che iniziano con il carattere #. Gli attaccanti iniettano proprietà come #post_render, #markup e #type tramite dati POST per forzare il motore di rendering a eseguire funzioni PHP arbitrarie (ad es., exec, passthru, system).
Condizione prerequisita: Almeno un endpoint che utilizza la Form API deve restituire una risposta valida (non reindirizzata, non bloccata dal controllo di accesso) in modo che l'attaccante possa inviare una richiesta AJAX contenente il payload.
Endpoint comunemente utilizzati nei PoC pubblici: