Tutti i gestori di siti Web basati su WordPress dovrebbero aggiornare al più presto il CMS all’ultima versione 5.1.1: in tutte le precedenti versioni è stata infatti indentificata una vulnerabilità critica di tipo Cross-Site Request Forgery (CSRF).
Il Cross-Site Request Forgery (CSRF), lo ricordiamo, è uno degli attacchi classici all’integrità delle sessioni Web. Consente ad un attaccante che controlla un sito malevolo di inviare richieste autenticate a nome della vittima, abusando così dei suoi privilegi presso un servizio online. In questo caso, consente ad un attaccante di sfruttare i privilegi di amministratore per compromettere qualsiasi sito basato su WordPress.
In particolare, la falla nel sistema di cyber security del famoso CMS potrebbe consentire a un eventuale attaccante di iniettare in maniera permanente codice HTML e JavaScript arbitrario in un sito WordPress. La nuova versione del CMS, oltre a introdurre altri 14 bug fix minori e alcuni miglioramenti secondari nei moduli di gestione, risolve la vulnerabilità nel core di WordPress causata dal modo in cui vengono filtrati i commenti non validati prima che vengano archiviati nel database dell’applicativo.
Indice degli argomenti
Vulnerabilità di WordPress: descrizione tecnica
La falla in WordPress è stata scoperta dal ricercatore di sicurezza Simon Scannell di RIPS Technologies. Dalle sue analisi è emerso che, attraverso l’uso dei commenti di WordPress, un criminal hacker potrebbe ingannare l’amministratore di un sito WordPress convincendolo a visitare un sito precedentemente compromesso.
A quel punto, un exploit in grado di sfruttare la vulnerabilità individuata nel CMS viene eseguito in background sul sito WordPress target, senza che l’amministratore si accorga di nulla.
In particolare, l’exploit CSRF sfrutta molteplici errori logici e di controllo degli input che, se combinati tra loro, portano all’esecuzione di codice in modalità remota e al controllo completo del sito da parte dell’attaccante.
Ciò è dovuto al fatto che WordPress non effettua alcun tipo di validazione CSRF quando un utente posta un nuovo commento ad un articolo pubblicato sul sito. Questo permette ad un attaccante di creare un commento a nome dell’utente Administrator contenente codice JavaScript creato ad hoc.
L’amministratore del sito, accorgendosi del nuovo commento, viene così indotto a visitare il sito Web malevolo. In questo frangente viene iniettato un payload XSS (il cross-site scripting è una vulnerabilità che affligge siti Web dinamici che non effettuano un controllo di sicurezza sui dati inseriti nei form per i commenti) nel sito web target vulnerabile a CSRF. Una volta memorizzato nel sito Web compromesso, il payload XSS viene eseguito all’interno di un iFrame nascosto.
In questo modo, l’attaccante ottiene accesso al CMS sfruttando una sessione con privilegi di amministratore. È a quel punto gioco facile, per lui, eseguire codice JavaScript per installare un plugin contenente una backdoor che gli consente il controllo da remoto del sito.
Ecco come correggere la falla di WordPress
Questa nuova “Security and Maintenance Release” di WordPress ci ricorda quanto i nostri sistemi siano fragili: è l’ennesimo tassello di difesa nella lotta quotidiana al cyber crime. È questo il commento di Andrea Muzzi, Technical Manager F-Secure, secondo cui “bisogna rendersi conto che sempre di più saremo esposti alle vulnerabilità. Le tempistiche sempre più frenetiche del mercato impediscono agli sviluppatori di lavorare con la dovuta accuratezza, regalandoci così software che necessitano di release correttive sempre più brevi e frequenti”.
“Da qui”, continua Muzzi, “la necessità sempre più impellente di adottare strumenti che aiutino nel controllo e nella gestione delle vulnerabilità. Molti IT Manager sono restii a sentir parlare di simili strumenti. Pensano che siano solo strumenti atti a giudicare la qualità del loro lavoro; ma così non è. Escono di media ogni giorno dalle 4/5 nuove vulnerabilità. È praticamente impossibile per un IT Manager pensare di poterle riconoscere e gestire tutte. Un sistema di “Gestione delle vulnerabilità”, come un radar, permette di mappare tutti gli asset della rete e di avere il polso della situazione per quanto riguarda le possibili falle”.
L’analista di F-Secure insiste sul fatto che “con un quadro più chiaro dei propri punti deboli, è possibile poi procedere con pratiche strutturate e ripetute nel tempo alla risoluzione delle vulnerabilità riscontrate. È fondamentale adottare fin da subito politiche per i controlli delle vulnerabilità e la gestione degli aggiornamenti. Non bisogna tergiversare ad aggiornare i propri software quando ci viene prontamente suggerito e come al solito è opportuno affidarsi sempre a vendor di sicurezza che abbiano uno standing serio in materia di cyber security”.
Per chiudere la falla di sicurezza è dunque fondamentale aggiornare WordPress all’ultima versione. Di default, il CMS installa automaticamente gli aggiornamenti di sicurezza e dunque i webmaster dovrebbero già ritrovarsi il sito aggiornato alla versione 5.1.1.
Qualora la funzionalità di auto-update fosse disabilitata o non si voglia procedere subito all’applicazione della security patch, l’unica soluzione per evitare attacchi di tipo CSRF è la disabilitazione dei commenti agli articoli pubblicati sul sito.
È inoltre sempre opportuno effettuare il logout dalla sessione di amministratore prima di visitare altri siti Web, così come è importante effettuare un backup completo del proprio sito internet prima di procedere con le operazioni di aggiornamento, avendo avuto cura di disabilitare i plugin di terze parti.
Ricordiamo, infine, che tutte le operazioni eseguite sul CMS avvengono via browser. Poiché i browser non proteggono nativamente dai CSRF, i siti interessati a proteggersi da questo tipo di attacchi dovrebbero implementare anche alcuni semplici meccanismi difensivi tra cui:
- utilizzo di token anti-CSRF: l’idea è di associare ad ogni richiesta sensibile un valore segreto impredicibile per l’attaccante, comunemente detto token, in modo che egli non sia in grado di comporre una richiesta legittima. Tutte le richieste senza un token valido vanno scartate;
- utilizzo di header HTTP: le richieste spedite dai browser standard includono un header chiamato Referer, che contiene l’indirizzo della pagina dalla quale la richiesta è stata spedita. Un sito può utilizzare il contenuto dell’header Referer per filtrare le richieste cross-site indesiderate;
- utilizzo di OTP e CAPTCHA: one-time password (OTP) nello stile delle chiavette normalmente impiegate dalle banche e CAPTCHA permettono di rendere ciascuna richiesta univoca ed autenticata, richiedendo un’interazione esplicita con l’utente per essere autorizzata.
