Recupero di un sito compromesso da malware
Bonificare un sito infettato da malware senza distruggerlo: capire l'estensione reale del danno, ripulire codice iniettato in migliaia di file, chiudere le vie d'ingresso e rimettere in piedi una copia funzionante da cui ripartire. È il lavoro fatto sul sito di un'azienda, su una vecchia installazione Joomla mai aggiornata dentro cui qualcuno aveva infilato codice estraneo, trasformando le pagine in un veicolo di spam verso siti esterni.
Che cosa era successo
Non si trattava di uno o due file malevoli caricati in un angolo. Il codice estraneo era iniettato dentro i file esistenti: ogni pagina del sito, ogni libreria, ogni pezzo di codice legittimo era stato riaperto e modificato aggiungendoci in testa qualche riga. Il sito continuava a funzionare — ed è esattamente il motivo per cui una cosa del genere può passare inosservata per mesi.
Accanto all'iniezione c'era la seconda parte, quella più pericolosa: una serie di shell, cioè piccoli file-passepartout che permettono a chi li ha messi di rientrare e dare comandi al server quando vuole, anche dopo che le password sono state cambiate. Sono la ragione per cui non basta mai «ripulire e basta».
Prima di toccare qualsiasi cosa
Il primo problema è stato capire su cosa si stava lavorando. Il backup scaricato dall'hosting conteneva tre copie di database diversi, perché sullo stesso abbonamento convivevano più siti. Usare quello sbagliato avrebbe significato ricostruire il sito di qualcun altro. È stato identificato quello giusto guardando il prefisso delle tabelle, cioè la sigla con cui ogni installazione marchia le proprie.
Poi è stato ricostruito un ambiente di lavoro locale, sul computer e non sul server: una copia già ripulita del sito, il suo database importato, e la versione di PHP che quel Joomla richiede — la 7.4, perché su una versione più recente quel codice non parte nemmeno, si ferma con errori fatali. Serviva per due ragioni: vedere com'era fatto il sito prima di rompere qualcosa, e poter provare le correzioni senza toccare la produzione.
Un'altra cosa emersa subito: il backup fornito dall'hosting era incompleto. Mancavano fogli di stile e script del template, quindi la copia locale non assomigliava all'originale. Per avere il riferimento visivo fedele si è dovuto recuperare l'aspetto del sito dall'archivio storico del web.
La bonifica
La pulizia è stata fatta distinguendo due categorie di file, perché richiedono due trattamenti opposti.
- I file infettati — codice legittimo con dentro un'aggiunta estranea — non si cancellano: si disinfettano, togliendo l'innesto e lasciando il resto. Erano circa 5.300, e 5.284 sono stati ripuliti.
- I file interamente malevoli — le shell — non si disinfettano: si tolgono di mezzo. Ne sono state trovate 41, isolate in una cartella di quarantena fuori dal sito anziché cancellate, così da poterle riesaminare senza che possano più essere eseguite.
- Il file principale della cartella di partenza, quello che riceve tutte le visite, è stato ripulito a parte, perché era il punto in cui l'iniezione faceva più danno.
C'è poi una terza categoria di cui si parla poco: i falsi positivi. Ogni scansione automatica segnala codice legittimo che sembra sospetto — file compressi, codice generato a macchina, librerie di terze parti. Sedici file erano in questa condizione e sono stati ripristinati dopo verifica. Se si fa il contrario, cioè si cancella tutto ciò che la scansione segnala, si esce dalla bonifica con un sito pulito e rotto.
A pulizia finita il controllo è stato rifatto da capo sull'intera cartella: zero infezioni residue.
Chiudere anche le altre due falle
Una bonifica non è una messa in sicurezza. Ripulire i file toglie l'effetto, non la causa: finché le credenziali dell'hosting, del database e degli utenti restano quelle di prima, chi è entrato la prima volta ha ancora le chiavi in mano; e finché il sito gira su una versione di Joomla che non riceve più correzioni di sicurezza, la porta può riaprirsi con lo stesso metodo.
Per questo, chiusa la pulizia, è stato individuato e chiuso il punto d'ingresso usato per l'iniezione, e sono state reimpostate tutte le credenziali — pannello, FTP, database, utenti del sito. Il sito è stato poi ricostruito su una versione supportata, recuperando i contenuti dal database e rifacendo il template, che era anch'esso di una generazione senza più sviluppo. Sono state identificate le estensioni riutilizzabili e quelle da abbandonare.
È stato infine attivato un controllo automatico di manomissione: verifica nel tempo se i file tornano a essere alterati e avvisa in caso contrario. È un presidio che non dipende dalla memoria di nessuno.
Risultato: 5.284 file disinfettati, 41 file-passepartout isolati in quarantena, 16 falsi positivi riconosciuti e ripristinati, zero infezioni residue alla verifica finale, punto d'ingresso chiuso, credenziali reimpostate e controllo di manomissione attivo.