mu-plugins e drop-in: le backdoor che WordPress carica da solo

WordPress carica alcuni file in modo automatico, senza che nessuno li attivi dal pannello: i plugin «must-use» e i cosiddetti drop-in. Sono funzioni utili e legittime, usate da hosting e plugin di cache, ma proprio perché si caricano da sole e non si possono disattivare dall’amministrazione sono anche tra i nascondigli preferiti per le backdoor.

I plugin must-use

Ogni file PHP presente direttamente nella cartella wp-content/mu-plugins viene caricato a ogni richiesta, prima dei plugin normali. Non si attiva e non si disattiva: se c’è, gira. WordPress li mostra in una scheda separata dell’elenco dei plugin, «Must-Use», che pochi aprono, e un file malevolo può anche togliersi da quell’elenco con un filtro.

Le sottocartelle di mu-plugins non vengono caricate automaticamente: per questo i plugin must-use legittimi composti da più file usano un piccolo file di avvio nella cartella principale, che include il resto. Un attacco fa spesso lo stesso, con un file di avvio dal nome rassicurante, come cache-loader.php o health-check.php, che include codice offuscato da una sottocartella o da un’opzione del database.

I drop-in

I drop-in sono file con nomi prestabiliti nella cartella wp-content, che sostituiscono o estendono parti del funzionamento di WordPress:

• advanced-cache.php, caricato molto presto quando la costante WP_CACHE è attiva, usato dai plugin di cache di pagina;
• object-cache.php, che sostituisce la cache degli oggetti, usato per esempio dai plugin per Redis o Memcached;
• db.php, che sostituisce la classe di accesso al database: lo usano alcuni strumenti di diagnostica e di gestione di più database;
• altri meno comuni come maintenance.php, db-error.php, fatal-error-handler.php e, nei multisito, sunrise.php.

Sono file particolarmente interessanti per chi attacca: vengono eseguiti prima dei plugin, quindi prima di molti controlli di sicurezza, e il file db.php vede passare ogni query, comprese quelle con le credenziali e i dati degli utenti.

Come verificarli

Un drop-in legittimo appartiene a un plugin preciso, che di solito lo crea copiando un proprio file o con un collegamento simbolico. La verifica consiste nel ricondurre ogni file al suo plugin:

ls -la wp-content/mu-plugins/ wp-content/*.php

# Il drop-in corrisponde al file del plugin che dovrebbe averlo creato?
diff wp-content/object-cache.php \
     wp-content/plugins/redis-cache/includes/object-cache.php

Se il plugin che dovrebbe averlo creato non è installato, se il contenuto è diverso dall’originale o se c’è del codice offuscato in fondo a un file altrimenti normale, il drop-in va considerato compromesso. Da WP-CLI, wp plugin list --status=must-use e wp plugin list --status=dropin li elencano, ma ricorda che anche WP-CLI carica WordPress: per un controllo indipendente dai filtri conviene guardare i file direttamente.

Pulizia e prevenzione

Un drop-in compromesso si sostituisce con la copia originale del plugin che lo gestisce, oppure si elimina, sapendo che la funzione collegata, per esempio la cache degli oggetti, smetterà di funzionare finché non viene reinstallata. Un file in mu-plugins che nessuno sa spiegare va salvato come prova e poi rimosso. Dopo la pulizia, il monitoraggio delle modifiche su queste cartelle è una delle misure più efficaci: sono file che cambiano raramente, quindi ogni modifica merita attenzione. Ne parliamo anche nell’articolo sulle backdoor nei cron job, dove i plugin must-use sono spesso il bersaglio della reinfezione.