Disinfestare Joomla!
...dopo esser stati attaccati
Come ripulire una installazione che è stata compromessa, in tanti semplici passi. Come mettere in sicurezza Joomla e tenerlo al sicuro.
Documentazione di supporto all'intervento al Joomladay 2013, guarda il video con domande e risposte. Scarica le slides qui
* Attenzione: questo articolo è rivolto a sistemisti e programmatori; non è una lettura piacevole, ma un noioso elenco. L'utilizzo della console è sconsigliato a chi non sa che cosa fa rm -rf. Scrivere il comando sbagliato potrebbe danneggiare il tuo server o cancellare l'unica copia del sito.
Video dell'intervento al JoomlaDay 2013 Napoli
1. Preliminari
Per prima cosa metteremo il sito infetto in condizione di non nuocere.
Potrebbe essere infetto il sito, più siti sullo stesso server e/o il server stesso.
Per prima cosa rinominiamo la root web del sito infetto: questo renderà inaccessibili i files e rimuoverà temporaneamente le falle del sito che hanno permesso all'intruso di infettarci.
Se abbiamo un momento, mettiamo su una pagina di cortesia per avvisare gli utenti.
Attenzione! Mettere il sito offline da Joomla lo spegne solo per gli utenti legittimi, il cracker continuerà a poter usare le sue backdoor e sfruttare il nostro server per i suoi loschi fini.
Prima di procedere oltre controlleremo la presenza di rootkit o malware usando rkhunter, chkrootkit, e maldet sugli altri siti.
Facciamo un dump del database.
2. Predisposizione
Copiamo i files del sito infetto su un altro server oppure su una cartella non accessibile da web per lavorarci.
1. Copiare l'intero sito infetto in una cartella temporanea, i.e. /root/attack/infetto
2. Determinare la versione di Joomla:
Code:$ cat public_html/CHANGELOG.php | grep "\-\-\- " | head -n1 -------------------- 1.5.18 Stable Release [27-May-2010] ------------------ # cat public_html/joomla.xml | grep "<version" <version>2.5.8</version>
e poi scaricare il pacchetto da:
http://docs.joomla.org/Joomla_1.5_version_history
http://docs.joomla.org/Joomla_2.5_version_history
A questo punto scarichiamo l'immagine di Joomla della nostra versione; se abbiamo un sito base senza estensioni aggiuntive, scarichiamo l'update package; se invece abbiamo delle estensioni dovremo scaricare la full, tutte le estensioni, e riprodurre l'installazione su una macchina sicura (meglio se una VM offline). Ora seguiamo il caso dell'update package: a parte quanto appena detto il resto della procedura è identico se useremo un archivio del nostro Joomla appena installato con tutte le estensioni sopra.
Code:# wget http://joomlacode.org/gf/download/frsrelease/ 17716/77259/Joomla_2.5.8-Stable-Update_Package.zip # ls Joomla_2.5.8-Stable-Update_Package.zip infetto [root@dev attack]# mkdir sicuro && cd $_ [root@dev sicuro]# unzip -q ../Joomla_2.5.8-Stable-Update_Package.zip [root@dev sicuro]# cd .. [root@dev attack]# cp -R infetto/ lavoro [root@dev attack]# ls infetto Joomla_2.5.8-Stable-Update_Package.zip lavoro sicuro< [root@dev attack]#maldet -a lavoro
Riepilogo preparazione:
1. infetto è l'originale ed ora è identico a lavoro
2. sicuro contiene joomla (e qualche estensione i.e. community builder ecc.)
3. Pulizia dei files
3.1. Sito sotto git o svn?
git status
svn status
3.2. Tre copie attack lavoro e sicuro?
- Sovrascrivo lavoro con i files dell'installazione pulita ovvero "sicuro";
- Esamino lavoro con strumenti di rilevazione malware
- Esamino le differenze con l'installazione "sicuro"
Code:$maldet -a . <img src="images/tips/disinfestare/maldet-output.png" alt="" height="184" width="462" /> $ <strong>diff -qrwbBE lavoro sicuro</strong> ... Files infetto/plugins/content/joomla/joomla.php and sicuro/plugins/content/joom la/joomla.php <strong>differ</strong><strong>Only in</strong> infetto/plugins: jmonitoring<strong>Only in</strong> infetto/plugins: sh404sefcore … $ diff -qrwbBE lavoro sicuro | wc -l 169 # cd lavoro # unzip ../Joomla_2.5.8-Stable-Update_Package.zip
(oppure l'archivio della nostra installazione di riferimento che abbiamo preparato prima).
La cartella lavoro che contiene ancora delle differenze?
Code:$ diff -qrwbBE lavoro sicuro <strong>Only in</strong> lavoro/modules: mod_roknavmenu <strong>Only in</strong> lavoro/images: logo.png <strong>Only in</strong> lavoro/images: stories … <strong>Only in</strong> lavoro: index_old.php
(ma nessun differ)
$ cd lavoro
$ rm -rf cache/* logs/* administrator/cache/* tmp/*
$ cd ..
$ diff -qrwbBE lavoro sicuro | wc -l 124
maldet --report 100913-1557.17923
malware detect scan report for dev.tmg.it:
SCAN ID: 100913-1557.17923 TIME: Oct 9 15:57:13 +0200 PATH: lavoro TOTAL FILES: 6508 TOTAL HITS: 6 TOTAL CLEANED: 0 NOTE: quarantine is disabled! set quar_hits=1 in conf.maldet or to quarantine results run: maldet -q 100913-1557.17923 FILE HIT LIST: {CAV}PHP.Trojan.WebShell-1 : lavoro/images/fbfiles/avatars/l_2145.jpg {CAV}PHP.Trojan.WebShell-1 : lavoro/images/fbfiles/avatars/2145.jpg {CAV}PHP.Trojan.WebShell-1 : lavoro/images/fbfiles/avatars/s_2145.jpg {HEX}php.cmdshell.unclassed.347 : lavoro/modules/mod_google/mod_msn_show.php {HEX}base64.inject.unclassed.7 : lavoro/modules/mod_modules/mod_modules.php {HEX}php.cmdshell.unclassed.347 : lavoro/modules/mod_tools/mod_tools.php =============================================== Linux Malware Detect v1.4.2 <Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.>
rm -f lavoro/images/fbfiles/avatars/l_2145.jpg rm -f lavoro/images/fbfiles/avatars/2145.jpg rm -f lavoro/images/fbfiles/avatars/s_2145.jpg
considerazioni sui moduli: alcuni potrebbero essere una invenzione dell'attaccante per nascondere il file ad un'occhiata veloce; altri potrebbero essere files del core Joomla o di qualche estensione legittima che sono stati infettati. Ma avendo rimosso questa possibilità copiando i file della nostra installazione sicura / update package, rimaniamo con la prima ipotesi:
Code:less lavoro/modules/mod_google/mod_msn_show.php
rapidamente conferma la nostra ipotesi:
Dopo il tedioso lavoro di controllo manuale, avremo un filesystem pulito. Facciamo una copia tanto per sicurezza.
3. Esame / confronto database
Se il backup del db è valido, usare quello;
Fare un dump del db;
ricerca di xss nei contenuti (usare sql dump) e url esterne: script, iframe, https?://
Vuotare tabella session e controllare utenti
Cambiare le password degli admin
Se trovati, ripristinare il db dal dump pulito.
4. Prevenzione urgente
- cambiare password dell'utente apache e mysql; assicurarsi che l'utente sotto cui gira il sito non abbia privilegi su alcun altro sito sullo stesso server. Lo stesso per il db, un utente = un database.
- permessi files e cartelle: 755 oppure modalità più estreme (cambio di proprietario + 755/555)
- aggiornare Joomla ed estensioni
- estensioni vulnerabili?
- SEF abilitato?
- .htaccess in root images tmp cache logs; .htaccess sicuro
- Bloccare administrator: passw + ip, jSecure
- configuration.php controllato a mano
4.1. Little Helper ti aiuta
La funzione Security di Little Helper permette di creare file .htaccess che prevengono l'esecuzione nelle cartelle images, tmp e cache, le tre destinazioni di attacco più comuni.
4.2. Devo aggiornare anche le estensioni?
Le vulnerabilità delle estensioni sono centinaia! Spesso le estensioni giacciono in stato di semi-abbandono e non vengono rilasciate patch di sicurezza in maniera rapida.
Quelle di Joomla, poche decine, vengono tutte corrette velocemente.
Il grafico illustra le vulnerabilità negli ultimi 2 anni (arancione) e nei dieci precedenti (blu) per Joomla, le estensioni e altri prodotti di uso comune.
Conclusioni
- Fatto tre copie del sito
- Pulita la copia infetta
- Alzato il livello di sicurezza dell'installazione
- Messa da parte come buon punto di partenza nel caso riuscissero a (ri)farcela sotto il naso
- Ricaricare sul server e sostituire al sito infetto
