Riparare Joomla 3, 2.5 , 1.5 dopo la vulnerabilità Code Injection [CVE-2015-8562]

La vulnerabilità, già corretta con l'aggiornamento Joomla 3.4.6 e le patch per le versioni 1.5 e 2.5, è di una gravità inaudita. Finora non era mai successo che il giorno di rilascio di un aggiornamento di sicurezza il 30% dei siti Joomla ricevessero il primo attacco. Le novità più interessanti sono:

• la velocità di rilascio
• l'indirizzamento preciso degli attacchi
• la qualità del mascheramento

Anche se hai già aggiornato alla 3.4.6, potresti esser stato attaccato prima! Leggi sotto come correggere il problema, come prevenirlo correttamente, e una breve analisi dell'exploit usato.

Identificare il problema

Tutti gli attacchi che abbiamo trovato hanno tentato di caricare un file specifico: libraries/joomla/exporter.php che a sua volta veniva usato per scriverne un altro: libraries/simplepie/simplepie.lib.php . Altri attacchi tentavano di scrivere in tmp, cache, logs e images, ma quelle sono cartelle che proteggiamo quindi non abbiamo potuto fare una raccolta completa degli exploit.

Se i due file sono presenti, eliminateli subito: non fanno parte di nessuna versione di Joomla e hanno solo scopi malefici. Il primo è una banale backdoor (protetta da password), il secondo invece  è più sottile, ne parleremo nel seguito.

Cerchiamo i punti di ingresso nei log

Un paio di chiamate ci permettono di filtrare subito le chiamate incriminate.

 Code:
zgrep "JDatabaseDriverMysqli" /var/log/virtualmin/*access_log-* > /tmp/step1.list
 grep "JDatabaseDriverMysqli" /var/log/virtualmin/*access_log >> /tmp/step1.list
 zgrep "JDatabaseDriverMysqli" /var/log/virtualmin/*error_log-* >> /tmp/step1.list
 grep "JDatabaseDriverMysqli" /var/log/virtualmin/*error_log >> /tmp/step1.list
 zgrep -e "(exporter.php|simplepie.lib)" /var/log/virtualmin/*access_log-* > /tmp/step2.list
 egrep "(exporter.php|simplepie.lib)" /var/log/virtualmin/*access_log >> /tmp/step2.list
 zgrep -e "(exporter.php|simplepie.lib)" /var/log/virtualmin/*error_log-* >> /tmp/step2.list
 egrep "(exporter.php|simplepie.lib)" /var/log/virtualmin/*error_log >> /tmp/step2.list 
 

Da qui passiamo ad analizzare i file creati, nel primo troveremo l'exploit della vulnerabilità, nel secondo la backdoor installata permanentemente.

Gli exploit sono di questo tipo:

mentre i tentativi di sfruttamento successivi:

Javascript Code:
/var/log/virtualmin/example.it_access_log:192.32.126.16 - - [17/Dec/2015:19:33:58 +0100] "POST /libraries/joomla/exporter.php HTTP/1.1" 301 264 "http://example.it/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36"

Da qui avremo la immediata misura della situazione. Un veloce controllo ci darà l'elenco dei siti più compromessi.

Troviamo eventuali files modificati

Dopo aver aggiornato Joomla (evitiamo che mentre facciamo pulizia rientri qualcuno), ed elimninato i files (se presenti):

• libraries/joomla/exporter.php
• libraries/simplepie/simplepie.lib.php

dovremo effettuare un confronto con un backup sano (uno precedente la prima data che avrete riscontrato nel file /tmp/step1.list appena creato).

Dovremo esplodere questo backup, applicarci l'aggiornamento di Joomla 3.4.6, e poi eseguire:

diff -qrwbBE /home/backups/cartellabackupricostruito /home/cartellaproduzione/public_html

Vi consiglio di reindirizzare la vista su un file, perché a meno di siti estremamente semplici, un po' di "grep -v" sarà necessario per filtrare le modifiche legittime del sito.

Qui una volta identificati i files diversi, una veloce diff vi dirà se sono legittimi o meno. Ma per sapere cosa cercare, guardate l'ultimo paragrafo, la questione è diventata sottile.

Eliminiamo / ripristiniamo gli originali

Beh qui non avete bisogno di molto aiuto, vero?

Prevenzione

Oltre all'aggiornamento (che è disponibile anche per Joomla 1.5 e 2.5, vedi https://docs.joomla.org/Security_hotfixes_for_Joomla_EOL_versions ), e ad assicurarci che non ci siano altri exploit in corso, si può aggiungere una regola all'.htaccess per evitare che ulteriori attacchi raggiungano il sito; trovate RewriteEngine on, e subito sotto inserite:

 Code:
RewriteCond %{REQUEST_URI} ^.*(preg_replace|eval|JDatabaseDriverMysqli).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(preg_replace|eval|JDatabaseDriverMysqli).* [NC]
RewriteRule .* - [F]
 

Queste regole possono anche esser messe all'interno della direttiva

 Code:
<strong><VirtualHost 95.110.201.240:80></strong> 

di httpd.conf (il file di configurazione di apache); questo è più veloce nell'esecuzione, perché la regola non deve esser letta ad ogni passaggio.

Attenzione: oltre all'attacco specifico, la regola sopra previene anche l'uso della parola "eval" nella url, questo potrebbe rendere inaccessibili pagine che legittimamente lo usano; se questo fosse il caso,

 Code:
RewriteCond %{REQUEST_URI} ^.*(preg_replace|JDatabaseDriverMysqli).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(preg_replace|JDatabaseDriverMysqli).* [NC]
RewriteRule .* - [F]

 non blocca "eval".

Password

La prima attività che viene svolta è acquisire le password dei database, cambiatele subito. Tutte.

Altri passi di prevenzione

Tutte le normali raccomandazioni:

• File e cartelle devono essere 755 al massimo.
• Se volete essere cauti, mettete file e cartelle 555, e lasciate 755 solo administrator/cache, cache, tmp e logs. Quando vorrete installare un aggiornamento, metterete 755 salvo poi rimettere in readonly appena fatto. Nota: molte estensiioni scrivono in posti strani, se vedete errori che la tal cartella non è scrivibile, rendetela scrivibile.
• Tenete Joomla e tutte le estensioni aggiornati
• Disinstallate le estensioni che non usate: possono ancora essere usate per exploit. Il 98% delle vulnerabilità Joomla viene dalle estensioni.
• Usate un servizio di monitoraggio

Descrizione dell'Exploit

Exporter

La prima parte carica il file libraries/joomla/exporter.php, che contiene:

Ogni istanza che abbiamo trovato aveva password diverse, ed esattamente lo stesso codice. In soldoni, questa è la chiamata che fa:

ovvero: esegui il codice che ti ho mandato se la password corrisponde.

Noterete lo stile carino di nascondere il flag preg_replace /e usando i separatori #e. Ma fin qui, nulla di nuovo.

Simplepie.lib

La seconda parte invece merita proprio la nostra ammirazione.

libraries/simplepie/simplepie.lib.php sembra un file di Joomla normale: a una occhiata veloce non si nota nulla di strano, ho evidenziato in grassetto le parti compromesse:

Intanto, la solita protezione Joomla, così il file è sicuro:

PHP Code:
!defined('JPATH_PLATFORM') or die;
 

Ma c'è un ! all'inizio riga!!! Me ne sono accorto alla terza lettura!

Quindi una bella funzione, sembra proprio parte del framework vero?

Invece ha ben due insidie: l'accesso al cookie, nascosto in mezzo al commento, e $a='as'; alla fine.

E qui il prestigio. Cosa sarà mai questo ${a} ? Andiamo a lettere, e $a = 'as'.'sert' ... inizia a suonare familiare? assert è un comando usato quando si scrivono unit test principalmente, ed esegue un eval! Solo che dà molto meno nell'occhio...

Elegante ed efficace, subdolo ma bello.  Un peccato doverlo cancellare.

Una spiegazione completa dell'attacco al session handler è qui. Scopri se ti sei messo al sicuro qui.