WordPress
Il contesto
Il sito istituzionale di un’azienda manifatturiera, realizzato con WordPress qualche anno prima e aggiornato di rado: poche pagine, un modulo di contatto, un catalogo in PDF. Nessuno lo seguiva con continuità, perché non vendeva online. Per riservatezza, nome e dettagli dell’azienda sono stati omessi.
I sintomi
Una mattina i dipendenti e alcuni clienti, aprendo il sito, hanno trovato la schermata rossa di Google Safe Browsing che avvisava di un sito ingannevole. Poco dopo sono arrivati altri problemi: le email aziendali, inviate dallo stesso dominio, finivano più spesso nello spam, e Google Search Console segnalava problemi di sicurezza con alcuni esempi di pagine coinvolte.
Il cliente ha scelto l’intervento entro 24 ore.
Cosa abbiamo trovato a livello applicativo
Gli URL indicati da Search Console portavano a pagine di phishing che imitavano l’accesso a una banca, ospitate dentro una sottocartella di wp-content/uploads. Erano state caricate da un kit di phishing completo, con un piccolo script che inviava le credenziali inserite a un indirizzo esterno.
Il kit era gestito da un plugin falso, con un nome che richiamava la sicurezza e un’intestazione copiata da un plugin reale. Non compariva nell’elenco dei plugin, perché nascondeva sé stesso con un filtro sull’elenco, e forniva all’attaccante un pannello per caricare file e creare pagine. Oltre al plugin, l’analisi ha individuato una ventina di file PHP offuscati sparsi nelle cartelle del tema e degli upload, con catene di base64_decode, str_rot13 e funzioni variabili, e alcuni file del core modificati con poche righe in più.
Il tema commerciale in uso conteneva anche file cifrati con ionCube. Li abbiamo confrontati con il pacchetto originale scaricato dall’area clienti del produttore: erano identici, quindi legittimi, e sono rimasti al loro posto.
Cosa abbiamo trovato a livello di sistema
Sul server non c’erano voci di cron malevole né processi estranei in esecuzione, ma i permessi dei file erano troppo larghi: l’utente del server web poteva scrivere ovunque, compresi i file del core. Il sito girava con una versione di PHP non più supportata. I log di accesso hanno mostrato l’ingresso: un accesso riuscito all’amministrazione di WordPress dopo migliaia di tentativi di login, con la password di un account non più usato da un ex collaboratore, seguito dall’installazione del plugin falso.
Come l’abbiamo rimosso
- Salvate le prove e l’elenco delle pagine segnalate da Search Console.
- Rimosso il kit di phishing, il plugin falso e tutti i file offuscati, dopo averne verificato la funzione.
- Sostituiti core, plugin e tema con copie originali, mantenendo i file cifrati legittimi del tema.
- Controllati database, utenti e trigger, eliminando l’account dell’ex collaboratore e un amministratore creato dall’attacco.
- Corretti i permessi dei file, aggiornato PHP a una versione supportata e cambiate tutte le credenziali.
- Richiesta la revisione tramite la sezione Problemi di sicurezza di Search Console, con la descrizione degli interventi eseguiti.
L’hardening
Abbiamo attivato l’autenticazione a due fattori per gli amministratori, limitato i tentativi di accesso, rimosso gli account non più in uso, disattivato la modifica dei file dal pannello di WordPress e impedito l’esecuzione di PHP nella cartella degli upload. Il sito ora riceve gli aggiornamenti di sicurezza con regolarità ed è sotto monitoraggio.
Il risultato
Il sito è stato ripulito entro le 24 ore previste e la richiesta di revisione è stata inviata subito dopo. I tempi della revisione dipendono da Google e non da noi: in questo caso l’avviso è stato rimosso dopo la verifica, e i problemi di sicurezza in Search Console risultano risolti. Nei giorni successivi abbiamo verificato anche la reputazione del dominio per l’invio di email e la configurazione dei record SPF, DKIM e DMARC, per aiutare la posta aziendale a tornare nella casella principale.