• Home
  • Info
  • Tips
  • Repair Joomla 3, 2.5 , 1.5 after a Code Injection [CVE-2015-8562]

Disinfesting Joomla!

...after being attacked!

How to clean an installation that was compromised, in many simple steps. How to secure Joomla! and keep it so.

Documents in support of our speech at the Joomladay Italy 2013, watch the video with the Q&A. Download the slides here (some italian required)

* Warning: this article is for system engineers & developers; it's not nice to read, rather a boring list.  It is strongly advised that you do not use a console if you don't know what rm -rf means.  Writing the wrong command could damage your server or delete the last good copy of your website.

 

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 &amp;&amp; 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?

  1. Sovrascrivo lavoro con i files dell'installazione pulita ovvero "sicuro";
  2. Esamino lavoro con strumenti di rilevazione malware
  3. Esamino le differenze con l'installazione "sicuro"
Code:
$maldet -a . <img src="images/tips/disinfestare/maldet-output.png" alt="" width="462" height="184" />   $ <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 <This email address is being protected from spambots. You need JavaScript enabled to view it.>  
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