rilascio del sistema di gestione dei contenuti web . Il rilascio è degno di nota per il suo completamento sull'implementazione verifica aggiornamenti e integrazioni tramite firma digitale.
Fino ad ora, durante l'installazione degli aggiornamenti in WordPress, il principale fattore di sicurezza era la fiducia nell'infrastruttura e nei server di WordPress (dopo il download, l'hash veniva controllato senza verificare la fonte). Se i server del progetto fossero compromessi, gli aggressori sarebbero in grado di falsificare un aggiornamento e distribuire codice dannoso tra i siti basati su WordPress che utilizzano un sistema di installazione automatica degli aggiornamenti. Secondo il modello di Trust Delivery precedentemente utilizzato, una simile sostituzione sarebbe passata inosservata da parte degli utenti.
Tenendo conto del fatto che del progetto w3techs, la piattaforma WordPress è utilizzata sul 33.8% dei siti della rete, l’incidente avrebbe assunto le dimensioni di un disastro. Allo stesso tempo, il pericolo di una compromissione delle infrastrutture non era ipotetico, ma piuttosto reale. Ad esempio, diversi anni fa uno dei ricercatori sulla sicurezza una vulnerabilità che ha consentito a un utente malintenzionato di eseguire il suo codice sul lato server di api.wordpress.org.
Nel caso delle firme digitali, la presa del controllo sul server di distribuzione degli aggiornamenti non comporterà la compromissione dei sistemi degli utenti, poiché per sferrare un attacco sarà inoltre necessario ottenere una chiave privata memorizzata separatamente con la quale verranno firmati gli aggiornamenti.
L'implementazione del controllo della fonte degli aggiornamenti tramite firma digitale è stata ostacolata dal fatto che il supporto per gli algoritmi crittografici necessari è apparso relativamente di recente nel pacchetto PHP standard. Gli algoritmi crittografici necessari sono comparsi grazie all'integrazione della libreria alla squadra principale . Ma come la versione minima supportata di PHP in WordPress versione 5.2.4 (da WordPress 5.2 - 5.6.20). Abilitare il supporto per le firme digitali comporterebbe un aumento significativo dei requisiti per la versione minima supportata di PHP o l'aggiunta di una dipendenza esterna, cosa che gli sviluppatori non potrebbero fare data la prevalenza delle versioni PHP nei sistemi hosting.
La soluzione era e l'inclusione di una versione compatta di Libsodium in WordPress 5.2 - , in cui un insieme minimo di algoritmi per la verifica delle firme digitali è implementato in PHP. L'implementazione lascia molto a desiderare in termini di prestazioni, ma risolve completamente il problema di compatibilità e consente inoltre agli sviluppatori di plug-in di iniziare a implementare moderni algoritmi crittografici.
Un algoritmo viene utilizzato per generare firme digitali , sviluppato con la partecipazione di Daniel J. Bernstein. Viene generata una firma digitale per il valore hash SHA384 calcolato dal contenuto dell'archivio di aggiornamento. Ed25519 ha un livello di sicurezza più elevato rispetto a ECDSA e DSA e dimostra una velocità molto elevata di verifica e creazione della firma. La resistenza all'hacking per Ed25519 è di circa 2^128 (in media, un attacco a Ed25519 richiederà operazioni di 2^140 bit), che corrisponde alla resistenza di algoritmi come NIST P-256 e RSA con una dimensione della chiave di 3000 bit o cifratura a blocchi a 128 bit. Ed25519 inoltre non è suscettibile a problemi con collisioni di hash e non è suscettibile ad attacchi di cache-timing o attacchi di canale laterale.
Nella versione WordPress 5.2, la verifica della firma digitale attualmente copre solo i principali aggiornamenti della piattaforma e non blocca l'aggiornamento per impostazione predefinita, ma informa solo l'utente del problema. Si è deciso di non abilitare immediatamente il blocco predefinito a causa della necessità di un controllo completo e di un bypass . In futuro è prevista anche l'aggiunta della verifica della firma digitale per verificare la fonte di installazione di temi e plugin (i produttori potranno firmare le liberatorie con la propria chiave).
Oltre al supporto per le firme digitali in WordPress 5.2, si possono notare le seguenti modifiche:
- Sono state aggiunte due nuove pagine alla sezione “Salute del sito” per il debug dei problemi comuni di configurazione, ed è stato inoltre fornito un modulo attraverso il quale gli sviluppatori possono lasciare informazioni di debug agli amministratori del sito;
- Aggiunta l'implementazione della "schermata bianca della morte", visualizzata in caso di problemi fatali e che aiuta l'amministratore a risolvere autonomamente i problemi relativi a plugin o temi passando a una speciale modalità di ripristino da crash;
- È stato implementato un sistema di verifica della compatibilità con i plugin che verifica automaticamente la possibilità di utilizzo del plugin nella configurazione attuale, tenendo conto della versione PHP utilizzata. Se un plugin richiede una versione più recente di PHP per funzionare, il sistema bloccherà automaticamente l'inclusione di questo plugin;
- Aggiunto il supporto per abilitare i moduli con codice JavaScript utilizzando и ;
- Aggiunto un nuovo template privacy-policy.php che permette di personalizzare il contenuto della pagina della privacy policy;
- Per i temi è stato aggiunto un gestore di hook wp_body_open, che permette di inserire il codice subito dopo il tag body;
- I requisiti per la versione minima di PHP sono stati aumentati alla 5.6.20; plugin e temi ora hanno la possibilità di utilizzare spazi dei nomi e funzioni anonime;
- Aggiunte 13 nuove icone.
Inoltre, puoi menzionare vulnerabilità critica nel plugin WordPress (CVE-2019-11185). La vulnerabilità consente l'esecuzione di codice PHP arbitrario sul server. Il plugin viene utilizzato su più di 27mila siti per organizzare una chat interattiva con un visitatore, anche sui siti di aziende come IKEA, Adobe, Huawei, PayPal, Tele2 e McDonald's (la Live Chat viene spesso utilizzata per implementare fastidiosi pop-up chat sui siti aziendali con offerte chat con il dipendente).
Il problema si manifesta nel codice per caricare i file sul server e permette di bypassare il controllo dei tipi di file validi e caricare uno script PHP sul server, per poi eseguirlo direttamente via web. È interessante notare che l'anno scorso una vulnerabilità simile era già stata identificata nella Live Chat (CVE-2018-12426), che consentiva di caricare codice PHP sotto forma di immagine, specificando un diverso tipo di contenuto nel campo Tipo di contenuto. Come parte della correzione, sono stati aggiunti ulteriori controlli per le whitelist e il tipo di contenuto MIME. A quanto pare, questi controlli sono implementati in modo errato e possono essere facilmente aggirati.
In particolare è vietato caricare direttamente file con l'estensione “.php”, ma l'estensione “.phtml”, che su molti server è associata all'interprete PHP, non è stata aggiunta alla lista nera. La whitelist consente solo il caricamento di immagini, ma puoi aggirarla specificando una doppia estensione, ad esempio ".gif.phtml". Per bypassare il controllo del tipo MIME all'inizio del file, prima di aprire il tag con il codice PHP, era sufficiente specificare la riga “GIF89a”.
Fonte: opennet.ru