Guida · Sicurezza
WordPress violato: la lezione della catena di fornitura
Quando furono presi i siti degli «esperti»: vettori d'infezione, comportamento del malware e dieci mosse di hardening pratiche per il CMS più diffuso del web.
Quando la notizia di un portale della community italiana di WordPress compromesso fece il giro dei blog tecnici, la reazione collettiva fu di sorpresa: i siti «degli esperti», quelli che spiegavano agli altri come fare, erano stati presi come gli altri. Fu una lezione salutare: la sicurezza di un WordPress non dipende dalla bravura di chi lo cura, ma dalla catena di fornitura del software — core, tema, plugin — e da come la si governa. Questa rilettura organizza quella lezione in un capitolo pratico.
Il vero punto di forza è il punto debole
WordPress alimenta una parte enorme del web perché il suo ecosistema di plugin e temi permette di costruire qualunque cosa in poche ore. Lo stesso ecosistema è la superficie d'attacco principale: un plugin popolare e trascurato dal suo autore è una porta aperta su milioni di siti contemporaneamente. Gli attaccanti non studiano il vostro sito: studiano i repository di plugin, cercano estensioni con vulnerabilità note e poi scandagliano il web per chi le porta ancora installate. La vostra importanza non c'entra; la vostra versione sì.
I vettori d'infezione più comuni
- plugin e temi non aggiornati, o abbandonati dagli autori: la via maestra;
- temi e plugin «nulled»: copie pirata dei commerciali, con codice aggiunto — il cavallo di Troia perfetto, perché lo installa volontariamente la vittima;
- credenziali deboli: amministratori con password semplici su pagine di login esposte;
- xmlrpc.php: interfaccia legittima usata per attacchi a dizionario e amplificazione;
- hosting condiviso carente: il caso trattato nel protocollo per gli account violati.
Come si comportano le infezioni
Raramente danneggiano in modo visibile: il malware moderno è un inquilino silenzioso. Backdoor nella cartella degli upload che riaprono l'accesso dopo la pulizia; utenti amministrativi aggiunti con nomi legittimi; redirect condizionati scritti in .htaccess, attivi solo per i visitatori dai motori; cron falsi che reintegrano i file cancellati; mailer che trasformano il sito in server di spam. E se il provider segnala invio di posta dal vostro account, la compromissione è già avvenuta: si passa al protocollo, senza discussione. Per questo una bonifica parziale è spesso peggio di nessuna bonifica: insegna all'attaccante che la porta è ancora aperta.
Il segno più sottovalutato è il traffico: picchi di visite da paesi lontani verso pagine che non esistono più nella navigazione, richieste POST verso file dai nomi strani. La Search Console e i log del server raccontano questi pattern ben prima che il danno sia visibile — leggerli una volta al mese è la forma più economica di sicurezza che esista.
Hardening in dieci mosse
- aggiornamenti automatici per le versioni minori del core;
- inventario pulito: ogni plugin e tema installato è necessario, aggiornato, di fonte ufficiale;
- disattivare l'editor di file dal pannello amministrativo (una riga di configurazione);
- chiavi e salti unici e rigenerati;
- verifica a due fattori sull'accesso amministrativo;
- limitazione dei tentativi di accesso e URL di login non standard dove possibile;
- xmlrpc disattivato se non serve;
- permessi corretti: configurazione scrivibile solo dal proprietario, upload senza esecuzione di codice;
- rete di distribuzione davanti con regole di protezione per il CMS — si collega alla guida all'edge;
- backup fuori sede, con restore provato.
Se il sito è già compromesso
Il protocollo è quello generale descritto per gli account di hosting violati: congelare, datare, confrontare, bonificare dalla copia pulita, aggiornare, verificare. Per WordPress un passo merita enfasi: la bonifica definitiva più affidabile è spesso la ricostruzione — core scaricato di fresco, plugin reinstallati dai repository ufficiali, contenuti ripristinati dal backup — perché elimina ciò che non si è riusciti a trovare.