rilascio del sistema di gestione dei contenuti web . Questa versione è notevole per la conclusione per la realizzazione di verifica degli aggiornamenti e dei plugin tramite firma digitale.
Fino ad ora, nell'installazione degli aggiornamenti su WordPress, il fattore principale per garantire la sicurezza era la fiducia nell'infrastruttura e nei server di WordPress (dopo il caricamento, veniva eseguita la verifica dell'hash senza una verifica della fonte). In caso di compromissione dei server del progetto, gli attaccanti avrebbero potuto sostituire l'aggiornamento e diffondere codice malevolo tra i siti basati su WordPress che utilizzano il sistema di installazione automatica degli aggiornamenti. Secondo il modello di consegna basato sulla fiducia precedentemente adottato, una tale sostituzione sarebbe rimasta inosservata da parte degli utenti.
Considerando che, secondo il progetto w3techs, la piattaforma WordPress è utilizzata nel 33.8% dei siti web sulla rete, l'incidente avrebbe assunto proporzioni catastrofiche. Inoltre, il rischio di compromissione dell'infrastruttura non era ipotetico, ma molto reale. Ad esempio, alcuni anni fa, uno dei ricercatori sulla sicurezza una vulnerabilità che consentiva a un attaccante di eseguire il proprio codice sul server api.wordpress.org.
Nel caso in cui vengano utilizzate firme digitali, il controllo del server di distribuzione degli aggiornamenti non porterà a compromettere i sistemi degli utenti, poiché per condurre un attacco sarà necessario ottenere anche la chiave privata, custodita separatamente, utilizzata per firmare gli aggiornamenti.
L'implementazione della verifica della fonte degli aggiornamenti tramite firma digitale è stata ostacolata dal fatto che il supporto per gli algoritmi crittografici necessari è stato introdotto in PHP solo di recente. Gli algoritmi crittografici necessari sono stati integrati grazie alla libreria nel core . Ma la versione minima supportata in WordPress la release 5.2.4 (a partire da WordPress 5.2 — 5.6.20). L'inclusione del supporto per le firme digitali avrebbe portato a un aumento significativo delle richieste per la versione minima supportata di PHP o all'aggiunta di una dipendenza esterna, opzioni a cui gli sviluppatori non potevano accedere considerando la diffusione delle versioni di PHP nei sistemi di hosting.
La soluzione è stata e l'inclusione nella versione compatta di Libsodium in WordPress 5.2 — , in cui è implementato in PHP un set minimo di algoritmi per la verifica delle firme digitali. L'implementazione lascia a desiderare in termini di prestazioni, ma risolve completamente il problema della compatibilità e consente agli sviluppatori di plugin di iniziare a integrare algoritmi crittografici moderni.
Per la generazione delle firme digitali viene utilizzato l'algoritmo , sviluppato con la partecipazione di Daniel J. Bernstein. La firma digitale è creata per il valore dell'hash SHA384 calcolato dal contenuto dell'archivio con l'aggiornamento. Ed25519 offre un livello di sicurezza superiore rispetto a ECDSA e DSA, e mostra una velocità di verificazione e generazione delle firme molto elevata. La resistenza agli attacchi per Ed25519 è di circa 2^128 (in media, per attaccare Ed25519 sono necessarie circa 2^140 operazioni binarie), equivalente alla resistenza di algoritmi come NIST P-256 e RSA con una lunghezza della chiave di 3000 bit o al cifrario a blocchi a 128 bit. Ed25519 non è anche soggetto a problemi di collisione negli hash, non è vulnerabile agli attacchi di analisi del tempo (cache-timing) e ad attacchi attraverso canali laterali.
Nella versione di WordPress 5.2, la verifica della firma digitale copre solo gli aggiornamenti principali della piattaforma e non porta, per impostazione predefinita, al blocco dell'aggiornamento, ma informa solo l'utente di un problema sorto. È stato deciso di non includere il blocco per impostazione predefinita a causa della necessità di una verifica approfondita e di un'interruzione . In futuro si prevede di implementare anche il controllo tramite firma digitale per la verifica della fonte di installazione di temi e plugin (i produttori potranno firmare le release con la propria chiave).
Oltre al supporto delle firme digitali, in WordPress 5.2 si possono notare le seguenti modifiche:
- Nella sezione «Salute del sito» sono state aggiunte due nuove pagine per il debug dei problemi comuni di configurazione, insieme a un modulo attraverso il quale gli sviluppatori possono lasciare informazioni di debug agli amministratori del sito;
- È stata implementata la visualizzazione del «schermo bianco della morte», visualizzata in caso di problemi fatali, utile per l'amministratore per risolvere autonomamente problemi legati a plugin o temi, accedendo a una speciale modalità di ripristino dopo un'errore;
- È stato implementato un sistema di verifica della compatibilità con i plugin, che controlla automaticamente la possibilità di utilizzare un plugin nella configurazione attuale tenendo conto della versione PHP in uso. Se un plugin richiede una versione PHP più recente, il sistema bloccherà automaticamente l'attivazione di quel plugin;
- È stata aggiunta la possibilità di caricare moduli con codice JavaScript utilizzando e ;
- È stato aggiunto un nuovo modello privacy-policy.php che consente di personalizzare il contenuto della pagina sulle politiche di riservatezza;
- Per i temi è stato aggiunto un gestore wp_body_open hook, che consente di inserire codice subito dopo il tag body;
- I requisiti per la versione minima di PHP sono stati elevati a 5.6.20, e nei plugin e nei temi è stata introdotta la possibilità di usare spazi dei nomi e funzioni anonime;
- Aggiunte 13 nuove icone.
È possibile menzionare anche di una vulnerabilità critica nel plugin di WordPress (CVE-2019-11185). Questa vulnerabilità consente di eseguire codice PHP arbitrario sul server. Il plugin è utilizzato su oltre 27.000 siti per organizzare chat interattive con i visitatori, tra cui quelli di aziende come IKEA, Adobe, Huawei, PayPal, Tele2 e McDonald’s (Live Chat è spesso utilizzato per implementare chat pop-up invasive sui siti delle aziende con l'offerta di comunicare con un dipendente).
Il problema si manifesta nel codice di caricamento dei file sul server e consente di bypassare la verifica dei tipi di file consentiti e caricare uno script PHP sul server, che può poi essere eseguito tramite accesso diretto via web. È interessante notare che l'anno scorso, in Live Chat, è stata già identificata una vulnerabilità simile (CVE-2018-12426), che permetteva di caricare codice PHP spacciandolo per immagine, specificando un tipo di contenuto diverso nel campo Content-type. Nel tentativo di risolvere il problema, sono stati aggiunti ulteriori controlli basati su liste bianche e sul tipo MIME del contenuto. Come si è rivelato, questi controlli sono stati implementati in modo scorretto e sono facilmente eludibili.
In particolare, il caricamento diretto di file con estensione «.php» è vietato, ma l'estensione «.phtml», spesso associata all'interprete PHP, non è stata inserita nella lista nera. La lista bianca consente solo il caricamento di immagini, ma può essere aggirata specificando un'estensione doppia, ad esempio, «.gif.phtml». Per bypassare il controllo del tipo MIME all'inizio del file, prima dell'apertura del tag del codice PHP, era sufficiente indicare la stringa «GIF89a».
Fonte: opennet.ru
