WooCommerce
Il contesto
Un negozio online su WooCommerce, di dimensioni medie, con alcune migliaia di prodotti e ordini ogni giorno. Il sito era ospitato su un server virtuale gestito da un’agenzia web, che si occupava anche degli aggiornamenti. Per riservatezza, nome del cliente, settore merceologico e dettagli che permetterebbero di identificarlo sono stati omessi o modificati.
I sintomi
Alcuni clienti avevano segnalato addebiti sospetti sulle proprie carte di pagamento dopo aver acquistato sul sito. L’agenzia aveva trovato uno script estraneo nella pagina di pagamento, lo aveva rimosso e aveva aggiornato tutti i plugin. La mattina dopo lo script era di nuovo lì. La stessa sequenza si era ripetuta per tre notti: pulizia di giorno, reinfezione durante la notte, sempre tra le due e le quattro.
Quando il cliente ci ha contattato, la priorità era chiara: fermare subito la sottrazione di dati di pagamento e capire perché la pulizia non teneva. Ha scelto il servizio con intervento entro 6 ore.
Cosa abbiamo trovato a livello applicativo
Lo script nella pagina di pagamento era uno skimmer: intercettava i dati inseriti nel modulo della carta e li inviava a un dominio che imitava quello di un servizio di statistiche. Veniva aggiunto al sito da un file nella cartella mu-plugins, con un nome simile a quello di un plugin di cache, che WordPress carica automaticamente e che non compare tra i plugin attivi, ma solo nella scheda separata «Must-Use», dove nessuno l’aveva cercato. Il codice era offuscato con una catena di base64_decode e gzinflate e si attivava solo nelle pagine del checkout.
Abbiamo trovato anche un utente amministratore creato di recente, con un indirizzo email simile a quello del titolare, e una copia della backdoor dentro la cartella degli upload, con l’estensione di un’immagine e incluso da una riga aggiunta in fondo al functions.php del tema figlio.
Cosa abbiamo trovato a livello di sistema
Qui c’era la spiegazione della reinfezione notturna. Nel crontab dell’utente con cui girava il sito c’era una voce eseguita ogni notte alle 2:30, nascosta sotto una serie di righe vuote, che scaricava da un indirizzo esterno una versione aggiornata del malware e la reinstallava nei punti in cui era stata rimossa. Era affiancata da una voce @reboot, che avrebbe riattivato tutto al primo riavvio del server.
Non era l’unico meccanismo. Tra i processi in esecuzione ce n’era uno con il nome [kworker/1:2], che a prima vista sembrava un thread del kernel. Ma girava con l’utente del sito, aveva come padre un processo PHP e il suo eseguibile, visto da /proc, era l’interprete PHP con uno script di avvio ormai cancellato dal disco. Era un processo PHP residente in memoria, avviato giorni prima, che ogni pochi minuti controllava che il file in mu-plugins esistesse e lo ricreava se mancava. Per questo, anche prima dell’esecuzione notturna del cron, alcune pulizie venivano annullate nel giro di pochi minuti.
L’analisi dei log di accesso ha ricondotto l’ingresso iniziale a un plugin per la gestione di moduli non aggiornato da oltre un anno, con una vulnerabilità nota che permetteva il caricamento di file.
Come l’abbiamo rimosso
Prima di toccare qualunque cosa abbiamo salvato le prove: una copia dei file sospetti, del crontab, dell’elenco dei processi e dello script in esecuzione, recuperato dalla memoria attraverso /proc. Poi abbiamo proceduto in quest’ordine:
- terminato il processo residente e disattivato le due voci del crontab, per fermare la persistenza;
- rimosso lo skimmer, il file in
mu-plugins, la copia negli upload e la riga aggiunta al tema; - confrontato core, plugin e tema con le versioni originali e sostituito ogni file modificato;
- eliminato l’amministratore non autorizzato e verificato gli altri account con privilegi elevati;
- controllato database, trigger e opzioni, che in questo caso non contenevano altro codice malevolo;
- cambiato tutte le credenziali: password degli amministratori, chiavi e salt di WordPress, password del database, accessi SFTP e SSH e chiavi API dei servizi di pagamento.
Abbiamo anche consigliato al cliente di informare il proprio fornitore dei servizi di pagamento, come previsto in caso di possibile compromissione dei dati delle carte.
L’hardening
Il plugin vulnerabile è stato sostituito con un’alternativa mantenuta. Abbiamo impedito l’esecuzione di PHP nella cartella degli upload, limitato il crontab dell’utente del sito, disattivato WP-Cron basato sulle visite a favore di un cron di sistema controllato e attivato il monitoraggio delle modifiche ai file del checkout, del tema e delle cartelle mu-plugins.
Il risultato
Il sito è stato dichiarato pulito entro le 6 ore previste dal servizio. Nei trenta giorni successivi il monitoraggio non ha rilevato nessuna modifica non autorizzata, e lo script nella pagina di pagamento non è più ricomparso. Il cliente ha ricevuto un rapporto con la ricostruzione dell’attacco, l’elenco degli interventi e le misure per evitare che si ripeta.