Se avete aggiornato un plugin o il vostro CMS dopo aver ricevuto uno dei miei avvisi di sicurezza, bene. Quello era il passaggio importante, e per molti siti è l’unico necessario.

L’aggiornamento chiude la falla da adesso in poi. Non può dirvi se qualcuno l’avesse trovata prima che la chiudeste. Questa pagina è un controllo pratico di circa 30 minuti, da fare da soli, per rispondere a quella domanda, scritto per i proprietari di siti che non hanno competenze di sicurezza né un budget dedicato. Sono indicazioni generiche, non un rilievo sul vostro sito: dall’esterno posso vedere quale versione del software un sito dichiara, e nulla di più.

Passaggio 1: capire che cosa poteva davvero fare la falla

Non tutte le vulnerabilità meritano la stessa risposta. Trovate il vostro avviso nella pagina degli avvisi e verificate in quale categoria rientra (ogni pagina di avviso lo indica in cima):

  • Furto di account o esecuzione di codice (un aggressore poteva ottenere l’accesso come amministratore o eseguire codice proprio): svolgete l’intero elenco di controlli qui sotto.
  • Lettura di dati (un aggressore poteva leggere informazioni dal vostro database, ma non modificare il vostro sito): concentratevi sui passaggi 2 e 5. La domanda è quali dati fossero conservati, non se il vostro sito sia stato alterato.
  • Problemi più circoscritti (falle che richiedono una configurazione specifica, o che arrivano soltanto a una schermata di amministrazione): la pagina di avviso del vostro componente indica che cosa valga la pena controllare, se c’è qualcosa. Spesso il solo aggiornamento basta.

Passaggio 2: stabilire la vostra finestra di esposizione

Due date delimitano il periodo che conta:

  1. Quando la falla si è aperta sul vostro sito. Di solito il giorno in cui avete installato la versione interessata. Se non lo sapete, la data dell’avviso CVE citato nella notifica (collegato da ogni pagina di avviso) è un ragionevole punto di riferimento: da quella pubblicazione in poi, anche gli aggressori ne erano al corrente.
  2. Quando avete aggiornato. Il giorno in cui l’avete chiusa.

Tutto ciò che segue riguarda quella finestra. Se è breve, poniamo che abbiate aggiornato entro un giorno o due dall’avviso, il rischio è reale ma piccolo. Se la finestra è lunga mesi, prendete sul serio l’elenco di controlli.

Passaggio 3: verificare chi può accedere al vostro sito

Un aggressore che sia entrato si lascia quasi sempre un modo per rientrare. Controllate, in quest’ordine:

  • Gli account amministratore. In WordPress: Utenti, poi filtrate per Amministratore. In Joomla: Utenti, poi Gestione utenti. Cercate qualsiasi account che non abbiate creato voi. Attenzione: alcune falle (per esempio quella di Simple Membership) permettono a un aggressore di impossessarsi di un account già esistente invece di crearne uno nuovo, quindi questo controllo da solo non dimostra nulla. È per questo che il cambio delle credenziali del passaggio 4 conta anche quando l’elenco degli utenti sembra pulito.
  • Plugin, temi o estensioni aggiunti di recente che non avete installato voi.
  • Attività pianificate (in WordPress il plugin WP Crontrol le mostra; molte backdoor si reinstallano da un’attività pianificata).
  • Le password applicative (in WordPress: Utenti, Profilo, Application Passwords), un modo silenzioso per mantenere l’accesso via API dopo il cambio di una password.

Passaggio 4: cambiare le credenziali

Se il vostro avviso rientrava nella categoria del furto di account o dell’esecuzione di codice e la vostra finestra di esposizione è durata più di qualche giorno, cambiate le credenziali anche se il passaggio 3 non ha rilevato nulla:

  • Le password di tutti gli account amministratore.
  • Le chiavi segrete e i salt in wp-config.php (WordPress). Questo disconnette tutti, compreso un eventuale aggressore con una sessione rubata; il generatore ufficiale fornisce valori nuovi. Su Joomla l’equivalente è il valore $secret in configuration.php.
  • Le password del pannello di controllo dell’hosting e di FTP/SFTP se sono condivise con qualcuno o vecchie.

Costa dieci minuti e chiude la porta alle sessioni rubate e agli hash di password decifrati, che vi sia stata o meno un’intrusione.

Passaggio 5: eseguire una scansione e controllare i file

  • Avviate la scansione antimalware del vostro provider di hosting se il pannello di controllo ne offre una (la maggior parte degli hosting condivisi lo fa), oppure un buon scanner gratuito. Per WordPress, la scansione gratuita di Wordfence confronta i vostri file con le copie ufficiali.
  • Guardate i file modificati di recente, intorno e dopo l’inizio della vostra finestra di esposizione, in particolare i file PHP nelle cartelle di caricamento. Quelle cartelle non dovrebbero praticamente mai contenere PHP.
  • Se il vostro hosting conserva i log degli accessi, scorrete la finestra alla ricerca di richieste al componente vulnerabile provenienti da indirizzi che non riconoscete. L’assenza di prove qui vale poco, perché i log ruotano, ma una corrispondenza è decisiva.

Se il controllo fa emergere qualcosa

Non cancellate ancora nulla. Fate prima un backup completo, file e database, in modo che quanto è accaduto possa ancora essere esaminato. Poi, in ordine di costo:

  1. Il vostro provider di hosting. Quasi tutti offrono un servizio di pulizia dal malware o quantomeno vi confermano che cosa vedono i loro scanner. Per la maggior parte dei siti piccoli è la prima cosa giusta da fare.
  2. Un professionista. Se il sito tratta dati dei clienti o pagamenti, o se la scansione ha trovato una backdoor, vale la pena pagare qualcuno per stabilire a che cosa si sia avuto accesso; in molti paesi la normativa sulla protezione dei dati dipende proprio da quella risposta.
  3. La soluzione drastica che funziona sempre: ripristinate un backup precedente alla finestra di esposizione, oppure reinstallate il CMS e i plugin dalle fonti ufficiali, conservando solo i vostri contenuti. Poi aggiornate e cambiate tutte le credenziali di cui sopra.

Se non siete sicuri di che cosa avete davanti, potete anche semplicemente rispondere all’email dell’avviso. Leggo tutte le risposte, e indirizzare le persone nella direzione giusta è parte del motivo per cui invio questi avvisi. Non vendo servizi di pulizia e questa pagina non è una proposta commerciale; si veda la politica di divulgazione.

Se avevate già aggiornato prima che arrivasse la mia email

Vale lo stesso ragionamento: l’avviso significa che il vostro sito ha dichiarato di recente una versione interessata, quindi una finestra è esistita anche se ora è chiusa. I passaggi da 2 a 4 rispondono comunque alla domanda che conta.