drupalgeddon2-cli

Una riscrittura da riga di comando del proof-of-concept di Drupalgeddon2 (CVE-2018-7600), realizzata come esercizio di studio mentre completavo il modulo Attacking Common Applications della Hack The Box Academy.

[!WARNING] Solo per test di sicurezza autorizzati e a scopo didattico. Eseguire questo strumento contro sistemi che non possiedi o per cui non hai esplicita autorizzazione scritta è illegale nella maggior parte delle giurisdizioni. Vedi Uso legale e responsabile.

[!NOTE] Implementazione scritta con assistenza AI. Vedi Nota sulla paternità.

Contesto — perché l'ho costruito

Drupal è una delle "applicazioni comuni" trattate nel modulo Attacking Common Applications di HTB Academy, e CVE-2018-7600 ("Drupalgeddon2") è il classico esempio di RCE non autenticata per questo contesto. Invece di copiare e incollare uno script usa-e-getta, volevo capire davvero l'iniezione nella Form API che rende possibile la vulnerabilità — così ho ricostruito da zero il PoC pubblico come esercizio di apprendimento.

L'originale ampiamente citato, a2u/CVE-2018-7600 di Vitalii Rudnykh, è ottimo per dimostrare il bug, ma richiede di modificare il payload direttamente nel codice a ogni esecuzione. In un flusso di lavoro da lab/CTF — rilanciando contro target diversi e volendo un punto d'appoggio riutilizzabile — tutto questo diventa noioso. Questa versione lo trasforma invece in un vero strumento CLI:

• target e comando vengono passati come argomenti; nessuna modifica al sorgente a ogni esecuzione
• installa automaticamente una piccola web shell PHP (il server vulnerabile scrive il file da solo), fornendo un punto d'appoggio stabile e riutilizzabile
• puoi lanciare un singolo comando, entrare in una pseudo-shell interattiva, oppure limitarti a installare la shell e andartene
• il nome del file della shell e il parametro del comando vengono randomizzati a ogni esecuzione, quindi una nuova esecuzione non collide e non lasci dietro di te una porta cmd= prevedibile

È volutamente limitato a una vulnerabilità nota e corretta da tempo (divulgata nel 2018). L'obiettivo era capire la tecnica e produrre un'implementazione di riferimento pulita e documentata — non una capacità offensiva inedita.

Nota sulla paternità

Il codice in questo repository è stato scritto con assistenza AI (Claude di Anthropic) mentre completavo il modulo HTB. Ho definito io gli obiettivi e i requisiti di design — ergonomia CLI, deploy automatico della web shell, modalità interattiva, nome della shell e parametro randomizzati — e ho revisionato e testato il risultato. Lo dichiaro perché è la cosa onesta da fare, e perché il valore qui sta nella comprensione e nelle decisioni ingegneristiche, non nella paternità di ogni singola riga.

Cosa fa

1. Usa l'iniezione nella Form API di CVE-2018-7600 per installare una piccola web shell PHP sul target. È il server vulnerabile stesso a decodificare e scrivere il file, il che evita i problemi di quoting/escaping del comando iniettato.
2. Ti permette di eseguire comandi tramite quella shell con --cmd, oppure di entrare in una pseudo-shell interattiva con --shell.
3. Verifica che la shell sia effettivamente installata ed esegua (restituisce un token casuale e ne verifica la presenza) prima di dichiarare il successo.

Versioni vulnerabili

CVE-2018-7600 colpisce:

• Drupal 7.x precedenti alla 7.58
• Drupal 8.x precedenti alla 8.5.1 (anche 8.3.x < 8.3.9 e 8.4.x < 8.4.6)

Questa implementazione mira al vettore della Form API di Drupal 8 (l'endpoint AJAX user/register). Drupal 7 è sfruttabile tramite un endpoint/payload diverso e non è gestito qui.

Le release corrette (7.58 / 8.5.1 e successive) non sono vulnerabili.

Requisiti

• Python 3.7+
• requests

pip install requests

Utilizzo

# one-off command
python3 drupalgeddon2.py -u http://target/ -c id

# interactive pseudo-shell
python3 drupalgeddon2.py -u http://target/ --shell

# just plant the shell, run nothing
python3 drupalgeddon2.py -u http://target/ --deploy-only

# route through Burp, ignore the proxy's self-signed cert
python3 drupalgeddon2.py -u http://target/ -c id --proxy http://127.0.0.1:8080 -k

Come funziona

CVE-2018-7600 è un difetto di sanitizzazione degli input nella Form API di Drupal. Drupal rappresenta i moduli come array renderizzabili annidati, e le chiavi dell'array che iniziano con # vengono trattate come speciali proprietà di rendering, non come dati utente. La patch (SA-CORE-2018-002) ha aggiunto una sanitizzazione per rimuovere queste chiavi con prefisso # dagli input forniti dall'utente.

Prima della patch, un attaccante non autenticato poteva iniettare proprietà di rendering in un elemento di modulo elaborato dal gestore AJAX di Drupal. Inviare proprietà come:

• #post_render — un elenco di callable che Drupal invoca dopo il rendering, e
• #markup — l'argomento passato a tali callable

contro l'elemento mail del modulo di registrazione utente fa sì che Drupal chiami una funzione PHP arbitraria (qui, exec) con input controllato dall'attaccante durante la fase di rendering — cioè esecuzione di codice remoto, senza richiedere autenticazione.

Questo PoC usa quella primitiva per codificare in base64 una shell PHP di una sola riga in locale, far sì che il server la decodifichi in un file nella webroot, e poi interagire con quel file tramite normali richieste GET.

Rilevamento e rimedio

Se sei dalla parte di chi difende:

Rimedio

• Aggiorna a Drupal 7.58 / 8.5.1 o successive (applica SA-CORE-2018-002). Questa è l'unica vera soluzione.
• Se il patching immediato è impossibile, il Drupal Security Team ha pubblicato una patch di mitigazione al momento della divulgazione — ma l'aggiornamento è fortemente preferibile.

Idee per il rilevamento

• Ispeziona i body delle POST verso endpoint di moduli/AJAX cercando chiavi di array di rendering: #post_render, #markup, #type, #lazy_builder, ecc. Le sottomissioni legittime di moduli non le contengono.
• Segnala le richieste a …/user/register?element_parents=…&_wrapper_format=drupal_ajax con parametri sospetti.
• Correla una POST a un endpoint di modulo AJAX con una successiva GET a un file .php di nuova creazione nella webroot.
• Controlla la creazione imprevista di file nella webroot di Drupal e la presenza di file PHP corti con un singolo parametro (shell system($_GET[...])).
• Questi comportamenti sono facili da codificare come firme Suricata/Snort o regole Sigma sui log del server web.

Crediti

• PoC originale e tecnica di base: Vitalii Rudnykh — a2u/CVE-2018-7600
• Divulgazione della vulnerabilità: Drupal Security Team — SA-CORE-2018-002
• Approfondimenti sulla tecnica che hanno ispirato questa riscrittura: gli articoli di ricerca di Check Point e Ambionics su Drupalgeddon2
• Questa riscrittura CLI: io, con assistenza AI (vedi Nota sulla paternità)

Uso legale e responsabile

Questo strumento è pubblicato per scopi didattici e per test di sicurezza autorizzati — i tuoi ambienti di lab, target HTB/CTF o sistemi per cui hai esplicito permesso scritto di valutazione. L'accesso non autorizzato a sistemi informatici è un reato ai sensi di leggi come il Computer Misuse Act 1990 del Regno Unito, il Computer Fraud and Abuse Act degli Stati Uniti e leggi equivalenti in altri paesi. Sei l'unico responsabile dell'uso che ne fai. L'autore non si assume alcuna responsabilità per usi impropri o per danni causati.

Licenza

MIT