Indice dei contenuti dell'articolo:
Quando un sito WordPress viene hackerato, il primo pensiero è quasi sempre lo stesso: individuare la vulnerabilità, eliminare il malware, ripristinare i file compromessi e riportare il sito online.
Sembrerebbe una procedura lineare.
Il sito viene compromesso, viene bonificato e il problema è risolto.
Purtroppo, nella realtà, non funziona sempre così.
In alcuni casi la vera emergenza inizia proprio quando il sito è già stato tecnicamente ripulito, perché durante il periodo di compromissione il dominio può essere finito nei database reputazionali utilizzati da antivirus, operatori telefonici e servizi di navigazione sicura.
Ed essere inseriti in una blacklist può essere questione di poche ore.
Uscirne, invece, può richiedere giorni o perfino settimane.
In Managed Server Srl, abbiamo sviluppato una metodologia e una procedura che a seguito della pulizia del sito Web (quindi sito non infetto), permette di eliminare il blocco in 24 / 48 ore nei giorni feriali. (Contattaci per risolvere il problema).
È esattamente il problema che ci siamo trovati recentemente a gestire su un e-commerce italiano di abbigliamento basato su WordPress e WooCommerce.
Il sito era stato affidato per la gestione applicativa al Webmaster e, con ogni probabilità, qualche aggiornamento importante di WordPress, del tema o di uno dei plugin installati era stato rimandato o saltato.
Il risultato è stato quello che purtroppo vediamo abbastanza frequentemente: una vulnerabilità sfruttata dagli attaccanti, il sito compromesso e successivamente rilevato dai sistemi automatici di sicurezza presenti su Internet.
La bonifica ha risolto il problema sul server.
Ma non quello della reputazione.
E per un e-commerce che produce fatturato ogni giorno, questa differenza può diventare estremamente costosa.
Il sito è pulito, ma molti utenti continuano a non entrare
La situazione inizialmente può sembrare incomprensibile.
Il server risponde correttamente.
WordPress funziona.
WooCommerce funziona.
Il certificato HTTPS è valido.
Il DNS risolve correttamente.
Il malware è stato eliminato.
Gli ordini possono essere effettuati normalmente.
Eppure iniziano ad arrivare segnalazioni:
«Il sito da me non si apre.»
Oppure:
«Dal cellulare riesco a entrare, dal computer no.»
O ancora:
«Da alcuni PC dell’azienda non riusciamo proprio ad accedere.»
È a questo punto che bisogna comprendere una distinzione fondamentale.
Un sito tecnicamente funzionante non è necessariamente un sito raggiungibile da tutti.
Esiste infatti un altro livello, completamente indipendente dall’infrastruttura che ospita WordPress: quello della reputazione del dominio.
Durante il periodo in cui il sito è stato compromesso, diversi sistemi di sicurezza possono averlo visitato, analizzato e classificato come pericoloso.
Una volta che questa informazione viene acquisita da un antivirus o da una piattaforma di threat intelligence, la successiva rimozione del malware dal server non comporta necessariamente l’immediata eliminazione dalla blacklist.
Ed è qui che iniziano i problemi.
TIM Navigazione Sicura, TIM Guardian e il blocco prima ancora di arrivare al server
Uno dei casi più difficili da gestire in Italia riguarda TIM Navigazione Sicura.
Il principio è relativamente semplice.
Quando un utente TIM utilizza il servizio di navigazione protetta, la richiesta può essere sottoposta a controlli reputazionali prima che venga effettivamente raggiunto il sito.
Il flusso, semplificando, può essere rappresentato così:
Il dettaglio importante è proprio questo:
il server Web può non essere raggiunto affatto.
Da un punto di vista sistemistico possiamo avere una macchina perfettamente funzionante, NGINX correttamente configurato, PHP-FPM operativo, database disponibile e WooCommerce che risponde in pochi millisecondi.
Non cambia nulla.
Se il blocco avviene prima, sulla rete dell’utente o all’interno del sistema di navigazione sicura, non esiste alcuna configurazione NGINX che possa risolvere il problema.
Non è un errore 500.
Non è un timeout PHP.
Non è Varnish.
Non è MySQL.
Non è un problema di CPU o RAM.
È un problema di reputazione.
«Cambiamo IP o spostiamo il sito su un altro server»
Quando il problema diventa economicamente urgente, una delle prime soluzioni proposte è quasi inevitabilmente:
«Spostiamo tutto su un nuovo server.»
Oppure:
«Cambiamo indirizzo IP.»
Comprensibile.
Ma nella maggior parte dei casi è necessario prima capire che cosa sia stato effettivamente inserito nella blacklist.
Se il problema riguarda la reputazione dell’indirizzo IP, cambiare IP può effettivamente avere senso.
Se invece è il dominio a essere classificato come malevolo, il discorso cambia completamente.
Supponiamo che:
www.esempio.it
sia classificato come sito pericoloso.
Spostarlo da:
192.0.2.10
a:
198.51.100.20
non modifica il fatto che l’utente stia comunque cercando di raggiungere:
www.esempio.it
La blacklist continua a vedere lo stesso dominio.
Il risultato rischia quindi di essere una migrazione effettuata in emergenza, con tutto ciò che comporta, senza aver realmente eliminato la causa del blocco.
Pulire il sito e ripristinare la reputazione sono due lavori differenti
Questo è probabilmente l’aspetto più importante da comprendere quando si gestisce un incidente del genere.
Esistono almeno due fasi completamente distinte.
La prima è la bonifica tecnica.
Significa verificare:
- file WordPress modificati;
- core compromesso;
- plugin vulnerabili;
- temi compromessi;
- webshell;
- backdoor;
- codice PHP offuscato;
- JavaScript iniettato;
- redirect malevoli;
- utenti amministratori creati abusivamente;
- cron sospetti;
- modifiche al database;
- credenziali FTP, SSH o WordPress potenzialmente compromesse.
Dopodiché bisogna risolvere la vulnerabilità che ha consentito l’ingresso.
Perché eliminare il malware senza chiudere la falla significa semplicemente aspettare la prossima compromissione.
La seconda fase è completamente differente:
ripristinare la reputazione del dominio.
Durante il periodo dell’attacco il sito può essere stato osservato da Google, antivirus, crawler automatici, servizi antiphishing, blacklist commerciali, provider DNS security e piattaforme di threat intelligence.
Questi sistemi hanno una propria memoria.
La compromissione può essere stata risolta oggi alle 10:00.
Non significa che alle 10:01 tutti abbiano già modificato la classificazione.
Avast, Norton e altri antivirus: il problema diventa ancora più grande
Nel caso specifico che abbiamo gestito, la situazione non riguardava solamente TIM.
Il dominio era stato intercettato anche da antivirus estremamente diffusi come Avast e Norton, oltre ad altri sistemi di reputazione.
A quel punto il problema diventa ancora più serio.
Perché l’utente può essere bloccato per motivi completamente differenti.
Può essere collegato attraverso TIM Navigazione Sicura.
Può avere Avast installato sul PC.
Può utilizzare Norton.
Può avere un prodotto aziendale di Web Security.
Può navigare attraverso DNS filtrati.
Può trovarsi dietro un firewall aziendale che importa feed reputazionali di terze parti.
Per l’utente finale il risultato è comunque identico:
il sito non si apre.
E soprattutto l’utente medio non distingue minimamente tra un blocco causato da un antivirus e un server realmente offline.
La conclusione sarà semplicemente:
«Il sito non funziona.»
Per un WooCommerce ogni ora ha un costo
Questo sarebbe già un problema serio per qualsiasi sito.
Per un e-commerce diventa decisamente peggiore.
Nel nostro caso parliamo di un negozio online di abbigliamento realizzato con WooCommerce, quindi di un sito il cui funzionamento genera direttamente fatturato.
Non stiamo parlando semplicemente di perdere qualche visita al blog.
Ogni utente che non riesce a raggiungere il sito è potenzialmente:
- un prodotto non visualizzato;
- un carrello non iniziato;
- un carrello non completato;
- una campagna pubblicitaria sprecata;
- una vendita persa;
- un cliente che acquisterà probabilmente da un concorrente.
Sulla base del normale volume di attività del negozio, il danno derivante da una giornata di operatività fortemente compromessa può essere stimato indicativamente nell’ordine dei 4.000 euro al giorno.
E questo rende evidente la differenza tra un incidente di sicurezza e il costo reale di un incidente di sicurezza.
Immaginiamo solamente che il problema perduri per una settimana.
Parliamo potenzialmente di decine di migliaia di euro di fatturato messo a rischio.
E il server, paradossalmente, potrebbe essere perfettamente online per tutto il tempo.
Perdere immediatamente il 30% del traffico non è un’ipotesi assurda ma pura realtà
Non possiamo naturalmente stabilire una percentuale universale valida per qualsiasi sito.
Dipende dalla composizione del traffico, dagli operatori utilizzati dai clienti, dai dispositivi e dai software di sicurezza installati.
Ma quando un dominio viene contemporaneamente bloccato da un importante operatore italiano e da antivirus molto diffusi come Avast e Norton, ipotizzare una perdita nell’immediato di almeno il 30% del traffico non è affatto irrealistico.
In determinate audience potrebbe essere anche superiore.
Consideriamo inoltre un altro aspetto.
Il traffico perso non viene necessariamente recuperato.
Se un cliente cerca una giacca, un paio di scarpe o un altro capo di abbigliamento e riceve dal browser o dall’antivirus un avviso del tipo:
SITO PERICOLOSO
difficilmente penserà:
«Proverò di nuovo domani.»
Molto più probabilmente tornerà su Google e aprirà il risultato successivo.
Magari quello di un concorrente.
Il danno reputazionale nei confronti dell’utente
Esiste inoltre un danno ancora più difficile da misurare.
La fiducia.
Per un e-commerce la sicurezza percepita è fondamentale.
L’utente deve inserire:
- nome;
- cognome;
- indirizzo;
- email;
- numero di telefono;
- informazioni relative all’ordine;
- eventualmente dati connessi al pagamento.
Se pochi secondi prima il proprio antivirus gli ha comunicato che il sito potrebbe essere pericoloso, convincerlo successivamente ad acquistare può diventare estremamente difficile.
Anche dopo il delisting.
Questo significa che il danno di un sito compromesso non termina necessariamente quando vengono rimossi i file infetti.
Può continuare attraverso la reputazione tecnica del dominio e perfino nella percezione umana del marchio.
Il problema delle blacklist: ciascuno ha i propri tempi
Uno degli aspetti più frustranti è che non esiste una singola blacklist centrale di Internet.
Ogni vendor dispone dei propri sistemi.
Google può considerare il sito pulito.
Avast può continuare a segnalarlo.
Norton può avere una classificazione differente.
TIM Navigazione Sicura può continuare a bloccarlo.
Un altro servizio può averlo già rimosso.
Un altro ancora potrebbe non averlo mai inserito.
È quindi perfettamente possibile trovarsi in questa situazione:
Google Safe Browsing CLEAN Antivirus A CLEAN Antivirus B MALICIOUS TIM Navigazione Sicura BLOCCATO Altro servizio CLEAN
Ed è proprio per questo che la fase successiva a una compromissione deve prevedere un monitoraggio reputazionale, non solamente la verifica del server.
Con TIM il delisting non è particolarmente semplice
Qui arriviamo probabilmente alla parte più antipatica dell’intera vicenda.
Alcuni servizi mettono a disposizione procedure relativamente semplici per richiedere la rivalutazione di un dominio.
TIM Navigazione Sicura utilizza tecnologie Akamai per la propria infrastruttura di protezione.
Akamai prevede strumenti specifici per contestare la classificazione di un dominio e indicarlo come Non-Malicious Domain, ma tali strumenti fanno parte principalmente della piattaforma professionale Secure Internet Access.
Non abbiamo quindi necessariamente a disposizione il classico form pubblico:
Inserisci dominio ↓ Richiedi nuova scansione ↓ Attendi il risultato
La procedura può richiedere contatti con TIM, segnalazioni tecniche, richieste di escalation verso i sistemi di sicurezza e, quando possibile, interventi sulla classificazione Akamai.
È esattamente il tipo di situazione nella quale è molto facile entrare e molto più difficile uscire.
E nel frattempo il cliente perde 4.000 euro al giorno
Questa è la parte che spesso viene sottovalutata quando si parla di aggiornamenti WordPress.
Viene rimandato un update perché:
«Tanto il sito funziona.»
Oppure:
«Lo facciamo la prossima settimana.»
Oppure ancora:
«Non aggiorniamo perché potrebbe rompersi qualcosa.»
Poi viene pubblicata una vulnerabilità.
Partono gli scanner automatici.
Il sito viene individuato.
Viene sfruttato.
Il malware rimane online abbastanza a lungo da essere rilevato.
E improvvisamente quello che sembrava un semplice aggiornamento rimandabile diventa un problema capace di produrre migliaia di euro di danni al giorno.
Non stiamo dicendo che ogni plugin non aggiornato porterà automaticamente a una compromissione.
Stiamo dicendo una cosa molto più semplice:
più a lungo una vulnerabilità nota rimane esposta, più aumenta la probabilità che qualcuno la trovi e la sfrutti.
E oggi trovare siti vulnerabili su Internet non richiede necessariamente qualcuno seduto davanti a un terminale che attacca manualmente un dominio alla volta.
Gran parte dell’attività è automatizzata.
La sicurezza WordPress non è installare un plugin di sicurezza
Mantenere sicuro un WooCommerce significa innanzitutto avere una procedura.
Bisogna conoscere:
- versione di WordPress;
- versioni dei plugin;
- versioni del tema;
- vulnerabilità conosciute;
- componenti abbandonati;
- utenti amministrativi;
- log degli accessi;
- modifiche inattese ai file;
- backup realmente ripristinabili.
E soprattutto gli aggiornamenti devono essere gestiti, non semplicemente ignorati.
Gestire significa anche verificarne la compatibilità, effettuare backup, eventualmente testare l’aggiornamento e controllare il sito successivamente.
Su un e-commerce importante è perfettamente comprensibile non voler aggiornare alla cieca in produzione.
Non è invece una buona strategia trasformare questa cautela in mesi di immobilismo.
Il vero costo della prevenzione si vede soltanto dopo un incidente
Aggiornare WordPress richiede tempo.
Testare un plugin richiede tempo.
Avere staging e backup richiede risorse.
Monitorare le vulnerabilità ha un costo.
Effettuare controlli periodici ha un costo.
Ma confrontiamolo con:
4.000 euro di fatturato potenzialmente compromesso ogni giorno.
Con una settimana di problemi reputazionali.
Con campagne Google Ads o Meta che continuano magari a portare utenti verso un dominio bloccato.
Con il personale commerciale che riceve telefonate.
Con clienti che vedono l’avviso di malware.
Con il Webmaster che cerca di capire perché da una connessione il sito funziona e dall’altra no.
Con sistemisti che verificano server perfettamente funzionanti.
Con richieste di delisting da inviare a più vendor contemporaneamente.
Improvvisamente il costo della manutenzione preventiva appare decisamente differente.
La lezione è semplice: dopo un hack non basta guardare il server
Quando un sito viene compromesso, la domanda non dovrebbe essere solamente:
«Abbiamo eliminato il malware?»
Bisognerebbe chiedersi anche:
«Chi ha visto quel malware mentre era online?»
Perché Google potrebbe averlo visto.
TIM potrebbe averlo visto.
Akamai potrebbe averlo classificato.
Avast potrebbe averlo registrato.
Norton potrebbe averlo inserito nei propri database.
E ciascuno di questi soggetti potrebbe avere tempi differenti per accorgersi che il sito è tornato pulito.
Conclusioni
L’incidente che abbiamo descritto rappresenta bene uno degli aspetti meno conosciuti della sicurezza WordPress.
Essere hackerati non significa solamente dover pulire WordPress.
Quando la compromissione dura abbastanza da essere rilevata dai sistemi di sicurezza distribuiti su Internet, il problema può continuare molto dopo la bonifica.
Ed è particolarmente doloroso quando il sito interessato è un WooCommerce che vende online e genera diverse migliaia di euro al giorno.
In questo caso, anche dopo aver ripristinato tecnicamente il sito, abbiamo dovuto confrontarci con blocchi provenienti da servizi come TIM Navigazione Sicura e antivirus diffusi come Avast e Norton.
Spostare il sito su un nuovo server non avrebbe necessariamente risolto il problema.
Cambiare indirizzo IP non avrebbe automaticamente restituito al dominio una reputazione pulita.
Perché server reputation e domain reputation sono due cose differenti.
E soprattutto perché Internet non dimentica una compromissione nello stesso istante in cui noi cancelliamo l’ultimo file infetto.
Possono essere necessari giorni.
In alcuni casi gli strascichi possono protrarsi anche per settimane.
Nel frattempo, una percentuale importante degli utenti può non riuscire a raggiungere il sito e, per un e-commerce, ogni visita persa può trasformarsi direttamente in fatturato perso.
La morale, quindi, non è semplicemente:
fate i backup.
È qualcosa di più ampio:
mantenete WordPress, WooCommerce, plugin e temi costantemente sotto controllo e aggiornati.
Perché aggiornare tempestivamente una vulnerabilità può richiedere mezz’ora.
Recuperare la reputazione di un dominio dopo una compromissione può richiedere settimane.
E quando il sito produce migliaia di euro al giorno, quelle settimane possono diventare estremamente costose.
