L’utilizzo di WordPress quale piattaforma CMS è uno di quelle cose che si definiscono tipicamente come uno “standard de facto”; il motore open-source per la costruzione di siti, blog e tutto quello che potete immaginare nel mondo del Web 2.0 è tra i più diffusi al mondo.

Sviluppato nel lontano 2003 in PHP con il backend dei dati realizzato mediante una istanza MySQL (ora Oracle), conta ad oggi oltre 700 milioni di siti, pari a circa il 43% del totale (stimato) del web pubblico.

Vanta tra i suoi utilizzatori alcune tra le “Fortune-500” (vedi https://wordpress.org/showcase/tag/fortune-500/), ossia le 500 più grandi aziende statunitensi così come stilate dalla periodica classifica redatta dalla rivista di settore Fortune. Tra queste ricordiamo solamente alcune aziende come Disney, Sony Music, Microsoft, ed altre certamente di grande calibro.

Purtroppo (parafrasando un altro detto) da gradi onori derivano grandi oneri, ed in questo l’onere più pesante è certamente quello di mantenere alto il livello di sicurezza del prodotto.

Compito difficile quando si ha una struttura estremamente personalizzabile mediante software di terze parti, quindi fuori dal controllo diretto. Sia chiaro: non è che il cuore del sistema CMS WordPress sia di per sé perfetto e che non soffra storicamente di limiti e problemi di sicurezza, ma è innegabile che la pletora di plug-in abbia innescato innumerevoli problemi di sicurezza, nonché una enorme difficoltà nell’analizzare le differenti condizioni di utilizzo delle componenti in uso nei siti.

Ed è questa l’origine dell’ultima storia di violazioni di sicurezza per il mondo WordPress.

Si tratta di una recente acquisizione nella nostra conoscenze delle vulnerabilità per WordPress e riguarda alcune versioni di un suo plug-in, PHP Everywhere (di Alexander Fuchs), plug-in che vanta l’utilizzo in non meno di 30000 siti. Il plug-in consente agli sviluppatori di siti WordPress di inserire il codice PHP aggiuntivo in vari componenti di un sito, incluse pagine, post e barre laterali, aiutando nella personalizzazione delle componenti del CMS.

Le vulnerabilità, censite come CVE-2022-24663, CVE-2022-24664 e CVE-2022-24665, derivano dalla incorretta configurazione di base del plug-in nelle versioni che precedono o sono uguali alla 2.0.3 (attualmente è invero disponibile la 3.0.0 che corregga appunto il problema). Tale configurazione errata autorizza l’uso di alcune funzionalità dove non dovrebbe.

Le vulnerabilità dunque affliggono solo le installazioni con le versioni indicate o semplicemente quelle che non abbiano apposto correttivi alla configurazione. Essendo una conoscenza acquisita solo di recente, ed essendo invero il software in esercizio da molto più tempo, questo problema potrebbe avere (o aver già avuto) un enorme impatto sull’esistente.

La prima vulnerabilità, la più grave con CVSS 9.9, è di tipo RCE, ed è dovuta alla implementazione da parte del plug-in (al pari di tanti altri) di shortcode (uno speciale tag di WordPress che consentono l'esecuzione di frammenti di codice PHP tramite questi); il problema è che tale implementazione consente l’uso a qualsiasi utente autenticato (di qualsiasi livello), aprendo a questo la possibilità di fare molto, fino a prendere il completo controllo del sito.

Anche le altre due sono di tipo RCE e sono state classificate parimenti gravi (con CVSS 9.9), anche se ristrette nell’uso ai soli utenti con autorizzazioni da editore dei post. Di nuovo le configurazioni di PHP Everywhere consentono l’esecuzione di codice arbitrario, questa volta attraverso i block gutenberg (gli editor specializzati per il layout dei contenuti) e i metabox (elementi per introdurre campi personalizzati, ossi metadati).

Naturalmente è compito degli amministratori di siti basati su WordPress porre subito rimedio, installando la nuova versione del plug-in o (quantomeno) mutare le configurazioni dello stesso secondo i criteri di sicurezza espressi nella nuova versione, riducendo il rischio delle vulnerabilità ora note. Ma è evidente che il tempo tra la versione che corregge il problema (la 3.0.0 è del 12/01/2022) e le precedenti (l’ultima versione precedente, e comunque vulnerabile, era del 23/12/2021, quella prima ancora del 03/08/2020, ecc) hanno lasciato un ampio margine di manovra agli agenti di minaccia che avessero voluto sfruttare tali vulnerabilità.

Tweet