Perché un plugin obsoleto resta il metodo n.1 per violare i siti delle piccole imprese

Chiedi a chiunque di immaginare un sito violato, e penserà a una figura incappucciata che digita freneticamente, alla ricerca di un exploit intelligente e su misura. Nella pratica, la stragrande maggioranza delle compromissioni di siti di piccole imprese non assomiglia affatto a questo. Assomiglia a questo: un plugin o una libreria ha una vulnerabilità resa pubblica, esiste una correzione da mesi, nessuno l’ha applicata, e uno strumento automatico ha trovato la falla prima di chiunque altro.

Il sistema CVE, in breve

Quando un ricercatore di sicurezza trova una vulnerabilità in un software, di solito le viene assegnato un identificativo CVE (Common Vulnerabilities and Exposures) e viene pubblicata in un database pubblico, insieme a un punteggio di gravità e — spesso — a codice di exploit dimostrativo. Questo processo esiste per permettere a chi si difende di tracciare e correggere problemi noti. L’effetto collaterale è che nel momento in cui una CVE viene pubblicata, diventa anche una lista pubblica e consultabile che dice esattamente agli attaccanti “ecco cosa cercare”.

Ecco perché la velocità delle patch conta più di quasi ogni altra cosa nella sicurezza pratica. La vulnerabilità non è segreta. L’unica domanda è se la chiuderai prima o dopo che venga scansionata.

Raramente è mirato — ed è questo che lo rende peggiore

La maggior parte di questa attività non è una persona che decide di attaccare specificamente la tua azienda. È un’infrastruttura di scansione automatica che perlustra continuamente internet cercando siti che eseguono una versione nota come vulnerabile di un plugin, tema o libreria molto diffusi — completamente indifferente a chi sei o quanto fatturi. “Sono troppo piccolo per essere un bersaglio” non si applica, perché nessuno ti ha scelto. Uno scanner ti ha trovato.

Perché è più difficile di “basta aggiornare regolarmente”

In teoria, aggiornare immediatamente risolve il problema. Nella pratica:

• Gli aggiornamenti possono rompere qualcosa. Un aggiornamento del plugin potrebbe entrare in conflitto con il tema o un altro plugin, quindi l’aggiornamento viene rimandato “finché qualcuno non trova il tempo di testarlo” — e quel ritardo è esattamente la finestra di esposizione.
• Nessuno traccia cosa è effettivamente installato. I siti costruiti nel corso di anni accumulano plugin che nessuno ricorda di aver installato, alcuni abbandonati dallo sviluppatore originale e che non riceveranno mai una correzione.
• La gravità non è ovvia dall’esterno. Non ogni nota di aggiornamento dice “questo corregge un bypass critico dell’autenticazione” — a volte è sepolta in una riga di changelog che sembra di routine.

Cosa chiude davvero la falla

• Un inventario reale. Non puoi aggiornare ciò che non sai di avere installato. Ogni plugin, tema e libreria dovrebbe essere elencato da qualche parte, non solo conosciuto implicitamente da chi ha configurato il sito originariamente.
• Scansioni che controllano specificamente i database CVE, non solo “è disponibile un aggiornamento” — i numeri di versione da soli non ti dicono se si applica una vulnerabilità nota specifica.
• Un SLA per le patch, non un’abitudine. “Ci arriveremo prima o poi” e “le criticità vengono corrette entro 48 ore” producono risultati molto diversi nel corso di un anno.
• Una fase di staging per tutto ciò che è più a rischio, così “l’aggiornamento potrebbe rompere qualcosa” smette di essere un motivo per saltarlo.

La verità scomoda è che questa è una delle categorie di violazione più prevenibili e che continua comunque a verificarsi costantemente — non perché sia difficile da risolvere, ma perché è noioso restarci sopra.