Arriva la mail dell’hosting. Oggetto: questione di sicurezza critica sul tuo sito.
Dice che il loro sistema ha rilevato un’iniezione, che il sito potrebbe essere compromesso, che se non pulisci rischi di finire in blacklist su Google e di perdere posizionamento.
Il primo riflesso, di solito, è uno dei due sbagliati. C’è chi va nel panico e stacca tutto. E c’è chi archivia la mail pensando «sarà il solito allarme automatico» e va a dormire.
Guarda, su un sito che seguo l’allarme era vero. E siccome siamo andati a fondo fino ai log del server, per una volta posso raccontarti tutta la storia con i tempi al secondo: come sono entrati, quanto ci hanno messo, e soprattutto qual è il dettaglio che ha evitato che finisse male.
Cosa c’era davvero
Due file, dentro la cartella dei media. Quella dove WordPress mette le immagini che carichi.
Si chiamavano indexto.php, per sembrare uno di quei file di sistema che stanno lì da sempre e nessuno guarda mai. Uno da 212 KB, l’altro da 324. Scritti tutti e due la stessa notte, a un secondo di distanza.
Il trucco per farceli arrivare è quello che mi ha fatto più impressione. Non erano file di codice. Erano fotografie vere: se le aprivi, dentro c’era una JPEG perfettamente valida, con tanto di dati di compressione. Il codice malevolo stava attaccato in fondo, negli ultimi 360 byte.
Perché fare questo giro? Perché tanti controlli si limitano a guardare se il file «sembra» un’immagine. Apri i primi byte, vedi che è una foto, lo lasci passare. Quello che c’è in fondo non lo guarda nessuno.
È come far entrare una busta con dentro una lettera normale, e in fondo alla busta un foglietto ripiegato che nessuno apre.
Cosa faceva quel codice
Qui c’è la parte interessante, perché il codice non faceva danni da solo. Faceva una cosa sola:
si collegava a un server esterno, si scaricava altro codice, lo salvava in un file nascosto e lo eseguiva.
Tradotto: il file sul sito era solo la chiave. Il ladro decideva dopo, e da remoto, cosa farci dentro. Oggi ti riempie il sito di link a farmacie online, domani ti frega i dati dei clienti, dopodomani ti manda spam a nome tuo. Cambia idea quando vuole, senza toccare più niente sul tuo server.
Il problema di questi cosi è proprio lì. Non trovi il danno guardando il file, perché il danno non ci abita dentro. Trovi solo la porta aperta.
Perché non è successo niente
E adesso la parte che vale il prezzo del biglietto.
Quei file stavano lì da diciotto ore. E non avevano combinato assolutamente nulla.
Il motivo è una riga di configurazione messa lì da un plugin di sicurezza, che dice al server una cosa semplicissima: dentro la cartella delle immagini non si esegue codice, mai, per nessun motivo.
Ha senso, se ci pensi. In quella cartella ci vanno foto e PDF. Non c’è uno straccio di ragione al mondo perché un file lì dentro debba «girare».
Quindi loro hanno caricato l’arma, hanno provato a premere il grilletto, e il server ha risposto picche. Il codice non è mai partito. Il file scaricato da fuori non è mai stato creato: l’ho cercato in 47.000 file e non esiste.
Un sito senza quella riga, quella notte, si sarebbe svegliato con dentro chissà cosa.
La cronaca dei dieci secondi
Poi siamo andati a leggere i log del server, che è la cosa che quasi nessuno fa e che invece racconta tutto. Lì dentro c’è scritto chi ha bussato, a che ora, e cosa ha chiesto.
L’attacco è durato dieci secondi tondi, in piena notte, dall’1:18:27 all’1:18:37.
Il giro che ha fatto è questo. Primo, una richiesta di ricognizione per capire se il sito aveva un certo plugin di ottimizzazione immagini e per procurarsi la chiave di accesso di quel plugin. Secondo, un colpetto a una specifica porta di servizio del plugin, giusto per vedere se rispondeva. Terzo, e questa è la parte da cui si capisce che sapeva il fatto suo, si è fatto dare l’elenco delle immagini già presenti sul sito: gli servivano fotografie vere da usare come involucro.
E al secondo trentacinque e trentasei, le due scritture andate a buon fine. I due file che ho trovato avevano esattamente quell’ora. Coincidono al secondo.
Nessun essere umano davanti a una tastiera. Tutto automatico, dall’inizio alla fine.
Il dettaglio che fa riflettere
Nei log c’era anche il biglietto da visita che il programma lasciava a ogni richiesta, quello che in gergo si chiama user agent. Di solito ci trovi scritto «Chrome», «Safari», roba del genere.
Qui invece c’era scritto il nome dell’exploit e il numero della falla che stava sfruttando. Alla lettera. Come uno che si presenta alla porta dicendo «sono qui per quella finestra rotta al primo piano».
E la stessa sigla, identica, era scritta anche dentro il codice malevolo, come prima cosa che veniva eseguita.
Perché mai firmarsi così? Perché quando ne buchi migliaia in automatico, ti serve un modo per ritrovarti in lista quali sono andati a segno. Non è arroganza, è contabilità .
Non ce l’avevano con lui
Questa è la cosa che i titolari di sito fanno più fatica a mandare giù, e la ripeto sempre: non ti hanno scelto.
Guardando i giorni prima, nei log c’erano altri quattro indirizzi diversi che nelle ventiquattr’ore precedenti avevano provato la stessa identica porta. Uno si è beccato un «non autorizzato». Un altro pure. Un terzo ha insistito undici volte di fila prendendo sempre porta in faccia.
È un bot che passa per la strada e prova la maniglia di ogni portone del quartiere. Non gliene frega niente di chi ci abita e di cosa vendi. Prova, e se cede entra.
Quello che ci è riuscito, ci è riuscito perché aveva fatto un passaggio in più degli altri: si era prima procurato quella chiave di accesso. Gli altri avevano provato a spallate e la porta aveva tenuto.
La causa vera, che non è il malware
Adesso arriviamo al punto, perché tutto il resto è cronaca.
Quel plugin era indietro di undici versioni.
Non tre, non quattro. Undici. Un plugin di ottimizzazione, di quelli che installi una volta e poi te ne dimentichi perché fa il suo lavoro in silenzio. E infatti nessuno l’aveva più guardato.
Ma il pezzo peggiore è un altro, ed è quello che me lo ha fatto trovare.
Controllando il sito ho visto che WordPress aveva smesso di controllare gli aggiornamenti. Il registro dei controlli era completamente vuoto, come se non avesse mai guardato in vita sua. Dal pannello sembrava tutto a posto, tutto verde, nessun avviso.
Sembrava aggiornato. Era fermo.
Ho forzato il controllo a mano e sono saltati fuori dodici aggiornamenti in attesa, più il core di WordPress stesso.
Ecco il combinato che ti frega: il sistema che dovrebbe avvisarti si spegne in silenzio, e da quel momento tu vivi convinto di essere aggiornato mentre stai accumulando falle. Non ricevi nessun allarme, perché l’allarme è rotto.
È come il rilevatore di fumo con la batteria scarica. Il soffitto ce l’ha, l’apparecchio si vede, ti dà pure una certa tranquillità a guardarlo. Solo che quando c’è il fumo non suona.
Cosa portarti a casa
Il primo punto è che la porta d’ingresso, quasi sempre, non è il plugin scritto male. È il plugin buono che non aggiorni. Il produttore la falla la chiude, tira fuori la versione nuova e ha fatto la sua parte. Da lì in poi tocca a te. E se il sito resta indietro di undici versioni, quella patch è come una medicina comprata e lasciata nel cassetto.
Il secondo punto è che devi verificare che il controllo automatico degli aggiornamenti stia davvero girando. Non che ci sia: che giri. Sono due cose diverse, e la differenza la scopri solo andando a guardare.
Il terzo è che i livelli di sicurezza servono proprio per le volte in cui uno cede. Qui l’aggiornamento mancava, e quella falla è stata sfruttata in pieno. Ha retto il livello sotto: la regola che impedisce di eseguire codice nella cartella delle immagini. Da sola non ha impedito l’ingresso, ma ha impedito il danno. Ed è questo che si intende quando si dice che la sicurezza non è un prodotto che compri, è una serie di cose che si coprono le spalle a vicenda.
Il quarto è che i log del server esistono e nessuno li legge mai. Sono l’unico posto dove c’è scritto cosa è successo davvero, con ora e provenienza. Occhio però, che durano poco: ruotano e vengono buttati nel giro di qualche giorno. Se il fatto è recente si ricostruisce tutto, se aspetti due settimane resta solo da tirare a indovinare.
E l’ultimo, che vale come regola generale: quello che non usi si toglie, non si spegne. Un plugin disattivato ti sembra innocuo, ma il codice resta sul server, nessuno lo aggiorna più, e in certe condizioni fa danni lo stesso. Se non ti serve, va rimosso davvero.
Se non sai come sta messo il tuo
La cosa scomoda di questa storia è che dal pannello non si vedeva niente di strano. Nessun avviso, nessun sito lento, nessun cliente che si lamenta. Tutto tranquillo, mentre c’era un file caricato da uno sconosciuto che aspettava solo di partire.
Se hai un sito che porta lavoro e non sai da quanto tempo non viene guardato sul serio, un controllo ogni tanto ti costa molto meno di una pulizia dopo. E soprattutto te lo fai quando decidi tu, non alle due di notte perché è arrivata una mail.
Se vuoi capire come sta messo il tuo, lo guardiamo insieme: cosa è aggiornato davvero, cosa è esposto e cosa conviene togliere. Se posso aiutarti te lo dico, se non posso te lo dico lo stesso, così non perdiamo tempo né io né te.
Parliamo della tua situazione: prenota una call conoscitiva senza impegno.
