rilascio del sistema di gestione dei contenuti web . Questo rilascio è notevole per la conclusione per la realizzazione del controllo degli aggiornamenti e delle estensioni tramite firma digitale.
Fino ad ora, durante l'installazione degli aggiornamenti in WordPress, il fattore principale per garantire la sicurezza era la fiducia nell'infrastruttura e nei server di WordPress (dopo il download si verificava l'hash senza verificare la sorgente). 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 aggiornamenti automatici. Secondo il modello di consegna fidato precedentemente applicato, tale sostituzione sarebbe passata inosservata dagli utenti.
Considerando che progetto w3techs la piattaforma WordPress è utilizzata nel 33,8% dei siti in rete, l'incidente avrebbe assunto proporzioni catastrofiche. Inoltre, il pericolo di compromissione dell'infrastruttura non era ipotetico, ma del tutto reale. Ad esempio, alcuni anni fa, uno dei ricercatori di sicurezza ha identificato una vulnerabilità che consentiva all'attaccante di eseguire il proprio codice sul server api.wordpress.org.
Nel caso di utilizzo delle firme digitali, il controllo sul server di distribuzione degli aggiornamenti non porterebbe alla compromissione dei sistemi degli utenti, poiché per effettuare un attacco sarebbe necessario ottenere anche la chiave privata conservata separatamente, tramite la quale vengono firmati gli aggiornamenti.
L'implementazione del controllo delle sorgenti degli aggiornamenti tramite firma digitale è stata ostacolata dal fatto che il supporto per gli algoritmi crittografici necessari è apparso nella distribuzione standard di PHP relativamente di recente. Gli algoritmi crittografici richiesti sono stati introdotti grazie all'integrazione della libreria nel core . Ma come 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 comportato un significativo aumento dei requisiti per la versione minima supportata di PHP o l'aggiunta di una dipendenza esterna, cosa che gli sviluppatori non potevano accettare considerando la diffusione delle versioni di PHP nei sistemi di hosting.
La soluzione è stata e l'inclusione in WordPress 5.2 di una versione compatta di Libsodium — , in cui è implementato un insieme minimo di algoritmi in PHP 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 ad adottare algoritmi crittografici moderni.
Per la generazione delle firme digitali è stato utilizzato l'algoritmo , sviluppato con la partecipazione di Daniel Bernstein. La firma digitale è generata per il valore dell'hash SHA384, calcolato dal contenuto dell'archivio con gli aggiornamenti. Ed25519 offre un livello di sicurezza superiore rispetto a ECDSA e DSA, e dimostra una velocità di verifica e di generazione delle firme molto elevata. La resistenza all'attacco per Ed25519 è di circa 2^128 (in media, per attaccare Ed25519 è necessario eseguire 2^140 operazioni bit), il che è equivalente alla resistenza di algoritmi come NIST P-256 e RSA con una chiave di 3000 bit o di un cifrario a blocchi a 128 bit. Ed25519 non è neppure soggetto ai problemi di collisione negli hash, non è sensibile agli attacchi tramite analisi del timing della cache e agli attacchi tramite canali laterali.
Nella versione WordPress 5.2, la verifica della firma digitale copre attualmente solo gli aggiornamenti principali della piattaforma e non blocca l'aggiornamento per impostazione predefinita, ma informa semplicemente l'utente di un problema riscontrato. Non è stata inclusa la funzionalità di blocco per impostazione predefinita a causa della necessità di una verifica completa e di una possibilità di bypass . In futuro, è previsto che la verifica della firma digitale venga aggiunta anche per la verifica della provenienza dei temi e dei plugin (i produttori potranno firmare le release con la propria chiave).
Oltre al supporto per le 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 di problemi tipici di configurazione, e viene fornito un modulo attraverso il quale gli sviluppatori possono inviare informazioni di debug agli amministratori del sito;
- È stata aggiunta l'implementazione dello 'schermo bianco della morte', visualizzato in caso di problemi fatali e che aiuta l'amministratore a risolvere autonomamente i problemi legati ai plugin o ai temi, accedendo a una modalità di recupero dopo un guasto;
- È 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 necessita di una versione PHP più recente, il sistema bloccherà automaticamente l'attivazione di quel plugin;
- È stato aggiunto il supporto per l'attivazione dei moduli con codice JavaScript utilizzando e ;
- È stato aggiunto un nuovo template privacy-policy.php, che consente di configurare il contenuto della pagina relativa alle condizioni di privacy;
- Per i temi di design è stato aggiunto un gestore del wp_body_open hook, che consente di inserire codice subito dopo il tag body;
- I requisiti per la versione minima di PHP sono stati aumentati a 5.6.20, nei plugin e nei temi è stata introdotta la possibilità di utilizzare spazi dei nomi e funzioni anonime;
- Aggiunte 13 nuove icone.
Inoltre, si può menzionare una vulnerabilità critica nel plugin di WordPress (CVE-2019-11185). La vulnerabilità consente di eseguire codice PHP arbitrario sul server. Il plugin è utilizzato su più di 27 mila siti per gestire chat interattive con i visitatori, inclusi i siti di aziende come IKEA, Adobe, Huawei, PayPal, Tele2 e McDonald’s (Live Chat è spesso utilizzato per implementare chat fastidiose sui siti delle aziende con l'offerta di interagire con un dipendente).
Il problema si presenta nel codice di caricamento dei file sul server e consente di eludere la verifica dei tipi di file consentiti e caricare uno script PHP sul server, per poi eseguirlo tramite accesso diretto via web. È interessante notare che l'anno scorso nel Live Chat è stata già identificata una vulnerabilità simile (CVE-2018-12426), che consentiva di caricare codice PHP spacciato per un'immagine, specificando un diverso tipo di contenuto nel campo Content-type. Nell'ambito della risoluzione del problema sono state aggiunte ulteriori verifiche basate su whitelist e sul tipo MIME del contenuto. Si è scoperto che queste verifiche sono state implementate in modo errato e possono essere facilmente aggirate.
In particolare, il caricamento diretto di file con estensione '.php' è vietato, ma non è stata aggiunta alla blacklist l'estensione '.phtml', spesso associata all'interprete PHP su molti server. La whitelist consente solo il caricamento di immagini, ma può essere aggirata specificando una doppia estensione, ad esempio '.gif.phtml'. Per bypassare il controllo del tipo MIME, era sufficiente inserire la stringa 'GIF89a' all'inizio del file, prima dell'apertura del tag con il codice PHP.
Fonte: opennet.ru
