Il 27 luglio, il team di Threat Intelligence di Wordfence ha evidenziato un problema di vulnerabilità di WPBakery, un plug-in di WordPress installato su oltre 4,3 milioni di siti. Questo difetto ha consentito agli aggressori autenticati con autorizzazioni a livello di collaboratore o superiori di inserire un JavaScript dannoso nei post.
Inizialmente Wordfence ha contattato il team dei plug-in il 28 luglio 2020 tramite il loro forum di supporto. Dopo aver ricevuto la conferma del canale di supporto appropriato, ha divulgato tutti i dettagli il 29 luglio 2020. Il Team dei plug-in ha confermato il problema di vulnerabilità di WPBakery rilevato e ha riferito che il loro team di sviluppo aveva iniziato a lavorare su una correzione il 31 luglio 2020. Dopo un lungo periodo di corrispondenza con il team di sviluppo dei plug-in e un numero di patch non funzionali, una patch utile finale è stata rilasciata il 24 settembre 2020.
Consiglio vivamente l’aggiornamento all’ultima versione: la 6.4.1, da subito.
Oltre a questo, consiglio anche di verificare di non avere alcun collaboratore non attendibile o account utente autore su siti WordPress.
Gli utenti di Wordfence Premium sono protetti dagli exploit mirati a queste vulnerabilità dal 28 luglio 2020 mentre gli utenti gratuiti di Wordfence hanno conseguito lo stesso livello di protezione dal 28 agosto 2020.
Descrizione: Authenticated Stored Cross-Site Scripting (XSS)
Plugin Interessato: WPBakery
Plugin Slug: js_composer
Versioni Interessate: <= 6.4
ID CVE: in attesa.
Punteggio CVSS: 6,4 medio
Vettore CVSS: CVSS: 3.1 / AV: N / AC: L / PR: L / UI: N / S: C / C: L / I: L / A: N
Versione Completamente Patchata: 6.4.1
Il page builder di WPBakery è il più popolare per WordPress. È uno strumento molto facile da usare che consente ai proprietari dei siti di creare pagine personalizzate utilizzando le funzionalità di trascinamento della selezione.
Sfortunatamente, il plug-in è stato progettato con un difetto che potrebbe dare agli utenti con ruoli a livello di contributore e autore la possibilità di inserire JavaScript dannosi in pagine e post. Questo difetto ha anche dato a questi utenti la possibilità di modificare i post di altri utenti. Il plug-in ha esplicitamente disabilitato qualsiasi controllo di filtro HTML del post di default nella funzione saveAjaxFe utilizzando kses_remove_filters () ;.
Perciò qualsiasi utente con accesso al generatore di WPBakery poteva inserire HTML e JavaScript ovunque in un post utilizzando il generatore di pagine.
public function saveAjaxFe() {
vc_user_access()->checkAdminNonce()->validateDie()->wpAny( 'edit_posts', 'edit_pages' )->validateDie();
$post_id = intval( vc_post_param( 'post_id' ) );
if ( $post_id > 0 ) {
ob_start();
// Update post_content, title and etc.
// post_title
// content
// post_status
if ( vc_post_param( 'content' ) ) {
$post = get_post( $post_id );
$post->post_content = stripslashes( vc_post_param( 'content' ) );
$post_status = vc_post_param( 'post_status' );
$post_title = vc_post_param( 'post_title' );
if ( null !== $post_title ) {
$post->post_title = $post_title;
}
kses_remove_filters();
remove_filter( 'content_save_pre', 'balanceTags', 50 );Inoltre, mentre WPBakery funzionava solo con le pagine create con il page builder di WPBakery modificabili tramite il builder, questi utenti potevano accedere all’editor fornendo i parametri e i valori corretti per qualsiasi post. Questo potrebbe essere classificato come un bug generale e come un problema di sicurezza, ed è ciò che ha reso possibile a collaboratori ed editori di utilizzare l’azione AJAX wp_ajax_vc_save e la corrispondente funzione saveAjaxFe per inserire JavaScript dannoso sui propri post e sui post di altri utenti.
Il plug-in aveva anche funzionalità onclick personalizzate per i pulsanti. Ciò ha permesso a un utente malintenzionato di inserire JavaScript dannoso in un pulsante che sarebbe stato eseguito con un clic. Inoltre, gli utenti a livello di contributore e autore sono stati in grado di utilizzare vc_raw_js, vc_raw_html e il pulsante utilizzando gli shortcode custom_onclick per aggiungere JavaScript dannoso ai post.
Tutto ciò significava che un utente con accesso a livello di collaboratore poteva inserire script nei post che sarebbero stati eseguiti non appena qualcuno accedeva alla pagina o faceva clic su un pulsante, utilizzando vari metodi diversi. Poiché gli utenti a livello di collaboratore richiedono l’approvazione prima della pubblicazione, è molto probabile che un amministratore visualizzi una pagina contenente JavaScript dannoso creato da un utente malintenzionato con accesso a livello di collaboratore. Eseguendo JavaScript dannoso nel browser dell’amministratore, sarebbe possibile per un utente malintenzionato creare un nuovo utente amministrativo dannoso o inserire una backdoor, tra molte altre cose.
Nell’ultima versione di WPBakery, gli utenti di livello inferiore non hanno più funzionalità unfiltered_html come impostazione predefinita, tuttavia gli amministratori possono concedere tale autorizzazione se lo desiderano. Inoltre, gli utenti senza i privilegi appropriati non possono più modificare i post di altri utenti, accedere al generatore di pagine se non consentito o utilizzare codici brevi che potrebbero consentire l’inserimento di JavaScript dannoso.
Dual Account Control
Una strategia per mantenere il tuo sito protetto dagli attacchi Cross-Site Scripting di account con privilegi elevati consiste nell’utilizzare due account. Il Dual Account Control (controllo del doppio account) utilizza appunto due account per qualsiasi utente che potrebbe richiedere capacità amministrative. Questo può essere fatto utilizzando un account utente con funzionalità amministrative per attività relative all’amministratore come l’aggiunta di nuovi utenti e plug-in e un altro account utente con funzionalità di editor utilizzato per esaminare e approvare i post di autori e collaboratori.
In questo modo si limiterà l’impatto che potrebbe avere una vulnerabilità di Cross-Site Scripting. Quando si accede a una pagina come amministratore del sito, qualsiasi JavaScript dannoso inserito da un utente malintenzionato può utilizzare solo funzioni amministrative come l’aggiunta di un nuovo utente o la modifica di un file del tema per infettare ulteriormente il sito. Utilizzando un account utente con solo funzionalità di editor durante la modifica, la creazione e il controllo dei post creati da utenti di livello inferiore, un tentativo di sfruttamento XSS potrebbe essere limitato, poiché un utente malintenzionato non potrà aggiungere con successo nuovi account amministratore o modificare temi tramite un editor account.
Soprattutto nei casi in cui molti utenti possono accedere ad azioni autenticate, si consiglia di utilizzare un account utente amministrativo solo quando è necessario eseguire funzioni amministrative sul proprio sito.
Tempistica di divulgazione
27 luglio 2020 – Scoperta della vulnerabilità di WPBakery. Viene sviluppata una firewall rule e indirizzata alla fase di test.
28 luglio 2020 – La firewall rule è sufficientemente testata e rilasciata agli utenti premium. Wordfence ha un primo contatto con il team di plug-in di WPBakery.
29 luglio 2020 – Il team di WPBakery risponde confermando la casella di posta appropriata e Wordfence invia i dettagli di divulgazione completi.
21 agosto 2020 – Dopo un po’ viene rilasciata una patch iniziale per risolvere i problemi di vulnerabilità di WPBakery.
26 agosto 2020 – Wordfence fa sapere al team di WPBakery che sono rimaste irrisolte alcune problematiche minori che richiedono un provvedimento.
28 agosto 2020 – Gli utenti gratuiti di Wordfence ricevono la firewall rule per risolvere il problema di vulnerabilità di WPBakery.
2 settembre 2020 – Wordfence chiede conferma al team di WPBakery di aver ricevuto la loro ultima email.
9 settembre 2020 – Il team di WPBakery conferma di aver ricevuto la loro email e che sta lavorando per ottenere il rilascio di una patch aggiuntiva.
11 settembre 2020 – Il team di WPBakery rilascia una patch aggiuntiva che non è del tutto sufficiente alla risoluzione del problema di vulnerabilità di WPBakery.
Dall’11 al 23 settembre 2020 – Wordfence lavora insieme al Team di WPBakery più a stretto rapporto per ottenere una patch adeguata.
24 settembre 2020 – Patch utile alla risoluzione del problema di vulnerabilità di WPBakery rilasciata nella versione 6.4.1.
Conclusione sulla vulnerabilità di WPBakery
Nel post di oggi ho descritto nel dettaglio un problema di vulnerabilità di WPBakery che forniva agli utenti autenticati la possibilità di inserire JavaScript dannoso nei post utilizzando il generatore di pagine WPBakery. Oltre a ciò, ho fornito alcune informazioni su come proteggersi dalle vulnerabilità a livello di collaboratore e autore. Questo difetto è stato completamente corretto nella versione 6.4.1. Si consiglia agli utenti di eseguire immediatamente l’aggiornamento all’ultima versione disponibile, che è la versione 6.4.1 al momento di questa pubblicazione.
Poiché WPBakery è un plug-in premium spesso incluso come generatore di pagine con numerosi temi premium, potrebbe essere necessario ricontrollare che eventuali aggiornamenti siano disponibili con l’acquisto del tema. La verifica del numero di versione del plug-in nella dashboard dei plug-in dovrebbe avvisarti della versione installata sul tuo sito.
I siti che utilizzano Wordfence Premium sono stati protetti dagli attacchi che tentano di sfruttare questa vulnerabilità dal 28 luglio 2020. I siti che utilizzano ancora la versione gratuita di Wordfence hanno ricevuto la stessa protezione dal 28 agosto 2020.
Se conosci un amico o un collega che utilizza questo plug-in sul proprio sito, ti consiglio vivamente di inoltrare loro questo avviso circa la vulnerabilità di WPBakery per aiutare a mantenere i loro siti protetti poiché si tratta di un aggiornamento di sicurezza significativo.
Ti è piaciuto questo post? Condividilo!
