ripristinare Joomla dopo un hack - parte 3

WesLinks un hack vestito da plugin

Questo articolo continua la serie degli articoli dedicati alla individuazione delle compromissioni dei siti Joomla! e delle operazioni da compiere per il ripristino degli stessi. In questo terzo capitolo analizzeremo un nuovo tipo di hack.

 

Analisi dell'hack: i sintomi

La ricerca del nome del sito su Google riportava, subito il nome del sito, una scritta tipo "Play Roulette Online For Real Money", cosa che di sicuro non esaltava il proprietario; la scritta variava di volta in volta, ma l'argomento era sempre lo stesso. Selezionando il link dalla pagina di ricerca ci si ritrovava su un non meglio identificato casinò on-line.
Riepilogando:

• la ricerca tramite Google riporta nella descrizione sotto il titolo  del sito un messaggio relativo al gioco on-line;
• l'accesso al sito dalla pagina di Google porta, tramite vari reindirizzamenti, ad un sito per il gioco d'azzardo
• l'accesso diretto al sito visualizza le pagine corrette.

 

Analisi dell'hack: la diagnosi

Come di prassi si parte valutando i files del cms stesso, ed il primo file da analizzare è /index.php che potrebbe aggiungere opportune informazioni all'head della pagina per ottenere questo comportamento.

Constatato che tale file non era stato modificato, si controlla quella che di solito è la seconda alternativa: il file index.php del template in uso (e gli eventuali file di supporto), ma anche questo era perfettamente conforme all'ultima versione che era stata caricata sul server.

La procedura descritta è la metodologia standard: massima parte degli hacks ad un sito sono opera di script kiddies (ragazzini che giocano a fare gli hackers, quelli che si vedono in tv e che i telegiornali spacciano per esperti informatici) e pertanto nella quasi totalità degli hack si risolve in questi due passaggi. C'è, purtroppo da dire, che gli hack si stanno evolvendo.

A questo punto si è reso opportuno verificare quando Google avesse indicizzato il sito: pochi giorni prima. Caricata la home del sito e analizzatine il contenuto non si riscontra nulla di irregolare. Il passo successivo consiste nell'analizzare gli articoli contenuti nel DB alla ricerca di codice (con tutta probabilità javascript) malevolo, ma anche qui pare tutto a posto.

ok, non è stato uno script kiddy...

Riepiloghiamo la situazione:

• l'entry point di Joomla non è stato modificato;
• Il file principale del template non è stato modificato;
• i contenuti non sono stati modificati;
• Google vede del testo che accedendo direttamente al sito non si vede.

 

Analisi dell'hack: la soluzione

A dire il vero la soluzione non è banale per chi non ha una buona conoscenza del framework di Joomla! e del relativo flusso di esecuzione: non è stato modificato Joomla, ma è stata sfruttata la struttura modulare del CMS stesso per ottenere il risultato descritto. È stato installato un plugin di tipo system.

Come si trova una una soluzione a problemi come questo? Di solito si parte dal chiedersi come avremmo fatto noi ad ottenere quel risultato. Ovviamente è richiesta un'ottima conoscenza del funzionamento di Joomla! a livello di codice.

 

Analisi del codice dell'hack

Per ottenere un tale comportamento tramite i plugin di joomla è necessario, come sopra accennato, scrivere un plugin di tipo "system", pertanto, si seleziona tale tipo nel menù di gestione. Ed ecco ciò che è apparso: "Editor - WesLinks".

Visto nell'insieme dei plugins, il prefisso  'Editor' può trarre in in inganno, ma dopo aver selezionato la tipologia di plugin spicca proprio. 

 

File di installazione del plugin

<?xml version="1.0" encoding="utf-8"?>
<install version="1.5" type="plugin" group="system">
    <name>Editor - WesLinks</name>
    <author>Joomla! Project</author>
    <creationDate>February 2006</creationDate>
    <copyright>Copyright (C) 2005 - 2010 Open Source Matters. All rights reserved.</copyright>
    <license>http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL</license>
    <authorEmail>Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.</authorEmail>
    <authorUrl>www.joomla.org</authorUrl>
    <version>1.0</version>
    [...]
</install>

Notate che:

• il plugin appartiene al gruppo system, anche se il nome usa il prefisso 'Editor, e questo chiaramente è un segnale molto sospetto';
• il copyright dichiara di essere un plugin realizzato dal team di Joomla! al fine di passare inosservato
• le varie informazioni aggiuntive tendono a farlo passare per un modulo proprio del sistema Joomla! stesso.

Si tenga presente che probabilmente l'hacker, o gli hackers, non utilizzeranno lo stesso nome su tutte le installazioni del plugin, quindi, se il vostro sito presenta il medesimo comportamento, non focalizzate la vostra attenzione solo sul nome. Immagino del resto che non via sfuggita la non casuale assonanza con weblinks, nome di un componente di sistema di Joomla! e dei relativi plugin.

Codice del plugin

Spiegherò alcuni aspetti del funzionamento del plugin, senza ovviamente addentrarmi troppo nello specifico e senza pubblicate il codice dell'hack stesso. Le ragioni di questa scelta editoriale dovrebbero apparire evidenti e ritengo non abbiano bisogno di spiegazione.

Il plugin aggancia un event handler al trigger onAfterRender() e, all'interno del metodo che gestisce l'evento controlla che:

• la richiesta arrivi da un determinato indirizzo ip (bots dei motori di ricerca), in tal caso:
  1. modifica il meta keyword della pagina;
  2. modifica il meta description della pagina;
  3. modifica il tag title nella sezione head della pagina html;
  4. crea del finto testo miscelando una serie di keywords e lo inserisce nella sezione body della pagina html;
• la richiesta contenga determinate keywords nell'header HTTP_REFERER, in tal caso:
  1. inserisce una istruzione location nell'head della risposta http ed interrompe l'elaborazione della pagina forzando la redirezione di chi proviene dal motore di ricerca al sito di gioco on-line.

 

È interessante notare che chi ha scritto questo plugin si è anche preoccupato di mantenerne il controllo qualora perda l'accesso al back end del cms, infatti agganciato al trigger onAfterInitialise() troviamo un metodo che sulla base delle variabili contenute nella richiesta http consente:

• visualizzare la mappa delle pagine del sito;
• leggere e scrivere i vari file di keyword, description, referrer, indirizzi ip in modo da verificarne e curarne l'aggiornamento;
• cancellare il plugin dalla tabella delle estensioni (ma non cancella i files).

 

Come è avvenuto l'hack?

L'analisi dei, peraltro pochi, files di log ed il fatto che il sito fosse correttamente aggiornato e in sicurezza, fa propendere per un problema del server e non del sito in sé. Per verificare la cosa, dopo gli scontati dinieghi del provider, e dopo aver notato che nel giorno successivo alla segnalazione del problema il finger print del server era cambiato (come se non ce lo aspettassimo) abbiamo ripristinato il sito senza modificare le password degli amministratori. Il sito non è stato più compromesso, il che, anche se non è di per sé elemento bastevole a confermare la diagnosi di cui sopra, di sicuro non ne diminuisce la validità.

 

Conclusioni

Come detto in un precedente articolo "chiedete garanzie, non sconti", anche per quanto riguarda la scelta del provider. A livello aziendale risparmiare due o tre decine di euro al mese non è un rischio accettabile di fronte alla perdita di profitto e di immagine che deriva da un down prolungato del sito.Il fatto che le pagine modificate fossero presenti sui motori di ricerca significa che il sito era stato compromesso almeno un paio di mesi di quando ci si è accorti, ed il tipo di hack non era rintracciabile se non tramite una ricerca mirata. Quanti clienti/prospects si sono persi prima che qualcuno avvisasse l'azienda?

Quindi: sviluppatori professionisti, hosting professionale.