Riportiamo un caso di ripristino di sito, effettuato per un utente, con infezione da malware su piattaforma WordPress che ha subito un attacco hacker, il tutto per educare chi tenta di rimuovere le infezioni semplicemente installando un plugin di sicurezza cliccando sul pulsante “scan”, che tali procedure sono inutili e potrebbero prolungare i tempi di bonifica con conseguenti danni. Tale post andrà a elencare solo alcuni passaggi eseguiti per questo caso. Ogni caso ha procedure diverse.
Premessa: Non è presente un backup del sito dal quale effettuare un recupero. Non è presente una cache su Google o altri motori o webarchive per visualizzare dati utili al ripristino del sito.
Il sito è stato attaccato su più fronti, FTP, Database, config, risulta inaccessibile per via della sospensione di servizio da parte del provider il quale farà puntare verso cgi-sys/suspendedpage.cgi, pertanto non è possibile operare direttamente da WordPress.
Analizzando via ftp il sito, si può comprendere da subito la gravità della situazione:
I file del core di WordPress sono stati parzialmente cancellati, ciò significa che non sarà possibile utilizzarlo per installare un plugin per effettuare una scansione (cosa che comunque non avremmo mai fatto). All’interno della public_html abbiamo una serie di pagine html con all’interno codice malevolo. Le pagine sono state indicizzate da Google e ciò ha comportato un ban dal motore di ricerca, questo per non avere preso in considerazione la pulizia dell’infezione nei giusti tempi.
Oltre i file .html, le poche pagine php che sono ancora sul server, sono state infettate da codice in base64
La cartella wp-content/plugin/ è stata eliminata pertanto non è inizialmente possibile risalire a quali plugin erano presenti sull’applicativo, successivamente però potremo capire dal Database quali plugin erano in uso prima dell’attacco.
Il numero di files infetti si attesta attorno a 1650 compreso il tema ed il child-theme. Il sistema interno del server ha settato come sospetti (alterando l’estensione file con .suspected) SOLO 140 files. Questo a prova che avere un sistema antivirus interno a volte serve a ben poco. L’infezione non ha interessato solo la public_html ma anche le subdirectory quali .cl.selector/
Andiamo a visualizzare il database per verificare la situazione. Risulta anche qui codice malevolo che utilizza shell_exec per essere eseguito. Oltre ciò a primo impatto è facile notare che ci sono ben 765 posts contenenti link esterni (generati per avere backlink verso siti esterni). Anche la tabella wp_users presenta utenze non autorizzate da eliminare. Gli utenti abilitati hanno subito un cambio password, pertanto tramite phpmyadmin è stata cambiata la password in md5, in modo da poter accedere successivamente e scegliere una nuova password (così da applicare il salt).
Sempre da database analizzando la lista delle tabelle è stato possibile risalire a quali plugin erano in uso, plugin successivamente scaricati direttamente dal repository di WordPress.
Dopo aver effettuato la pulizia del database è stato necessario creare un nuovo DB con utenze diverse dalle precedenti, parametri poi inseriti nuovamente sul file di configurazione wp-config.php
Avendo ora ripulito sistematicamente e manualmente i files ed il db, possiamo ospitare il core di WordPress, richiedere la riattivazione del servizio, testare il funzionamento del sito ed installare ed attivare i plugin precedentemente in uso.
Analizzando i logs è stato possibile capire chiaramente come la sede dell’intrusione sia stato un plugin non aggiornato e con grave falla di vulnerabilità. In questo caso avendo scaricato l’ultima versione del plugin, fixare la falla è stato molto semplice.
Tutte le password sono state variate oltre ad aver preso altre precauzioni.
N.B. Alcune procedure ulteriori non sono state riportate all’interno di questo articolo. Non consigliamo di effettuare operazioni di questo tipo senza la giusta preparazione. Hai un sito infetto e cerchi consulenza? non esitare a contattarci.
