Vulnerabilità Elementor PRO: come risolvere ed evitare danni

30 Marzo 2023

–

Pubblicato in: Sicurezza

by:

Attenzione, c’è una vulnerabilità di Elementor Pro in versione minore o uguale a 3.11.6, che potrebbe risultare nel tuo sito WordPress bucato. Se usi Elementor pro aggiorna subito, assicurandoti di avere almeno la versione 3.11.7. Se usi Elementor free il tuo sito è al sicuro.

Oggi c’è stato un attacco sfruttando questa falla, gli amici di wp-ok ci hanno avvisato in modo tempestivo, e di conseguenza avvisiamo i nostri clienti.

TLDR

Il 12 Marzo è stata scoperta e segnalata una vulnerabilità di Elementor Pro.

La nuova versione 3.11.7 è stata rilasciata da Elementor Ltd il 22 Marzo, chiudendo questa falla di sicurezza.

Oggi è stato notato un attacco di grandi dimensioni usando questa falla, e quindi è il momento di correre ai ripari.

Soluzione

La soluzione, per evitare che il tuo sito possa venire bucato, è di aggiornare Elementor Pro il prima possibile.

Dal momento che la falla di sicurezza è stata risolta con la versione 3.11.7 del plugin, non devi far altro che aggiornare il plugin all’ultima versione per dormire sonni tranquilli.

Causa del problema

Questa vulnerabilità tocca soltanto la versione Pro di Elementor, se usi Elementor free il tuo sito è al sicuro e non hai niente di cui preoccuparti.

Quando WooCommerce è attivato Elementor carica il file “elementor-pro/modules/woocommerce/module.php” che aggiunge 2 azioni ajax:

/**
 * Register Ajax Actions.
 *
 * Registers ajax action used by the Editor js.
 *
 * @since 3.5.0
 *
 * @param Ajax $ajax
 */
public function register_ajax_actions( Ajax $ajax ) {
   // `woocommerce_update_page_option` is called in the editor save-show-modal.js.
   $ajax->register_ajax_action( 'pro_woocommerce_update_page_option', [ $this, 'update_page_option' ] );
   $ajax->register_ajax_action( 'pro_woocommerce_mock_notices', [ $this, 'woocommerce_mock_notices' ] );
}

L’azione pro_woocommerce_update_page_option è usata dall’editor di elementor.

Quest’azione chiama la funzione update_option che viene usata per modificare le opzioni di WordPress nel database:

/**
 * Update Page Option.
 *
 * Ajax action can be used to update any WooCommerce option.
 *
 * @since 3.5.0
 *
 * @param array $data
 */
public function update_page_option( $data ) {
   update_option( $data['option_name'], $data['editor_post_id'] );
}

Come vedi questa funzione modifica l’opzione sul database usando due valori inviati dall’utente.

Questa funzione serve all’amministratore o allo shop manager di modificare alcune impostazioni di WooCommerce nel database.

Il problema è che non viene fatto un controllo sui dati inseriti dall’utente, né viene fatto un controllo sul ruolo che deve avere l’utente per usare questa funzione.

Elementor usa un suo hadler ajax per la maggior parte delle sue chiamate ajax, quindi anche per pro_woocommerce_update_page_option.

Questo handler lo troviamo nel file “elementor/core/common/modules/ajax/module.php”:

/**
 * Handle ajax request.
 *
 * Verify ajax nonce, and run all the registered actions for this request.
 *
 * Fired by `wp_ajax_elementor_ajax` action.
 *
 * @since 2.0.0
 * @access public
 */
public function handle_ajax_request() {
   if ( ! $this->verify_request_nonce() ) {
      $this->add_response_data( false, esc_html__( 'Token Expired.', 'elementor' ) )
         ->send_error( Exceptions::UNAUTHORIZED );
   }
   [...]

Questa funzione fa un check del nonce, per evitare che un malitenzionato possa sfruttare una vulnerabilità.

Elementor free carica tutti gli script javascript usando l’hook admin_enqueue_scripts col file “elementor/core/common/app.php”:

add_action( 'admin_enqueue_scripts', [ $this, 'register_scripts' ] );

Quindi se usi Elementor free dalla console js del browser puoi usare:

alert( elementorCommon.ajax.getSettings("nonce") );

Per vedere il nonce in questo modo:

Ho controllato e questo è stato risolto nell’ultima versione di Elementor.

Un attaccante può in questo modo recuperare il nonce, e fare una chiamata ajax, il tutto dalla console del browser e modificare le impostazioni di WordPress.

A questo punto dipende solo dalla creatività dell’attaccante decidere cosa fare.

Ad esempio è possibile modificare l’impostazione users_can_register per abilitare le nuove registrazioni ed impostare il nuovo ruolo come amministratore usando l’impostazione admin_email per poi registrarsi tramite il form di WordPress ed essere amministratore.

Oppure sarebbe possibile modificare l’impostazione siteurl per redirigere tutto il traffico su un altro sito.

Soluzione alternativa

Come ho spiegato sopra la soluzione è aggiornare Elementor Pro il prima possibile.

In alcuni casi è possibile che l’utente che usa WooCommerce e ElementorPro sia impossibilitato ad aggiornare Elementor Pro.

Non voglio in alcun modo favorire chi usa Elementor Pro senza licenza e quindi non può aggiornare direttamente dall’area amministratore di WordPress.

Questa soluzione vuole essere una toppa per quegli utenti che usano versioni vecchie a causa di incompatibilità tra addon o altri plugin. Una cosa assolutamente non raccomandata, e che consiglierei di risolvere il prima possibile per poter tenere il tutto aggiornato correttamente.

Puoi applicare una modifica al file “elementor-pro/modules/woocommerce/module.php” di Elementor Pro.

Cerca questa parte:

/**
 * Update Page Option.
 *
 * Ajax action can be used to update any WooCommerce option.
 *
 * @since 3.5.0
 *
 * @param array $data
 */
public function update_page_option( $data ) {
   update_option( $data['option_name'], $data['editor_post_id'] );
}

E sostituisci con:

	/**
	 * Update Page Option.
	 *
	 * Ajax action can be used to update any WooCommerce option.
	 *
	 * @since 3.5.0
	 *
	 * @param array $data
	 */
	public function update_page_option( $data ) {
		$is_admin = current_user_can( 'manage_options' );
		$is_shop_manager = current_user_can( 'manage_woocommerce' );
		$is_allowed = $is_admin || $is_shop_manager;

		if ( ! $is_allowed ) {
			return new \WP_Error( 401 );
		}

		$allowed_options = [
			'woocommerce_checkout_page_id',
			'woocommerce_cart_page_id',
			'woocommerce_myaccount_page_id',
			'elementor_woocommerce_purchase_summary_page_id',
		];

		$option_name = $data['option_name'];
		$post_id = absint( $data['editor_post_id'] );

		if ( ! in_array( $option_name, $allowed_options, true ) ) {
			return new \WP_Error( 400 );
		}

		update_option( $option_name, $post_id );
	}

In pratica fa le stesse cose, ma controlla che l’utente abbia i permessi per modificare le opzioni, e permette la modifica soltanto di alcune opzioni.

Una nota sulla modifica dei plugin

Questa è una pratica sbagliata, e sono io il primo a sconsigliare la modifica di temi e plugin.

Mentre coi temi abbiamo la possibilità di creare un tema child, coi plugin questo non è possibile.

In questo caso specifico sto parlando dell’impossibilità di aggiornare Elementor Pro, quale che sia il motivo. Inoltre sto applicando lo stesso codice della versione 3.11.7 di Elementor Pro che risolve questa vulnerabilità.

In pratica stiamo modificando il codice di un plugin che non possiamo aggiornare. E se lo aggiorniamo la nuova versione ha la stessa modifica, quindi di fatto il problema è ridotto al minimo.

Soluzioni non risolutive

Ci sono alcune soluzioni in rete, che non considero risolutive. Vediamo quali sono e perché non vanno bene.

Bloccare il range di IP

È stato consigliato di bloccare il range di IP 193.169.194.**

Questa è una toppa che aveva senso fino a quando non era stato capito cosa stava succedendo, visto che gli attaccanti stavano usando quel range di IP.

Ovviamente non ci vuole tanto a cambiare IP, quindi è una misura che protegge, ma come puoi capire protegge entro certi limiti.

Impostare il changelog in 404

È stato consigliato di impostare il changelog di elementor pro in 404, è possibile farlo con una semplice direttiva .htaccess

RewriteRule /wp-content/plugins/elementor-pro/changelog.txt - [L,R=404]

Anche questa è una soluzione, anche se non definitiva.

L’attacco viene fatto in maniera automatizzata, quindi se il bot vede un 404 per questo file (che presumibilmente usa per vedere che versione di elementor stai usando) potrebbe passare al prossimo sito.

Ma nulla vieta che il bot controlli le risorse della pagina, basta cercare qualcosa di questo tipo:

https://dominio.it/wp-content/plugins/elementor-pro/assets/js/nav-menu.bb5cce0a50480cdf695d.bundle.min.js

Per capire che il sito sta usando Elementor Pro e provare lo stesso l’attacco.

Sintomi di un sito attaccato

Finora sono stati notati questi sintomi nei siti attaccati, se noti una di queste cose è possibile che il tuo sito sia stato attaccato:

Il sito fa redirect su un altro sito. Potrebbe non essere visibile per via della cache, quindi aggiungi un parametro casuale all’url, tipo dominio.it?exsrcdtfvbgy=rdcftvbgy
Nelle impostazioni di WordPress vedi che chiunque può registrarsi e il ruolo di default non è subscriber:

Vulnerabilita Elementor Pro Impostazioni

Vedi degli utenti che non riconosci, al 99% amministratori.

Esempio di attacco: log del server

Sotto riporto cosa abbiamo trovato nei log del server dopo un tentativo di attacco:

/var/log/apache2/domlogs/hidden/hidden.net.hidden.it:193.169.194.63 - - [30/Mar/2023:14:35:05 +0200] "GET / HTTP/1.1" 301 707 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:05 +0200] "GET / HTTP/2" 200 51892 "http://hidden.net" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:06 +0200] "POST //wp-admin/admin-post.php HTTP/2" 200 20 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:07 +0200] "GET //wp-content/plugins/elementor-pro/changelog.txt HTTP/2" 200 25778 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:08 +0200] "GET / HTTP/2" 200 51892 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:09 +0200] "GET //wp-login.php?action=register HTTP/2" 302 20 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:10 +0200] "GET /wp-login.php?registration=disabled HTTP/2" 200 2839 "https://hidden.net//wp-login.php?action=register" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:11 +0200] "GET //my-account HTTP/2" 301 20 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:11 +0200] "GET /my-account/ HTTP/2" 200 31322 "https://hidden.net//my-account" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:12 +0200] "GET //my-account HTTP/2" 301 20 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:13 +0200] "GET /my-account/ HTTP/2" 200 31322 "https://hidden.net//my-account" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:14 +0200] "GET /my-account/ HTTP/2" 200 31322 "https://hidden.net/my-account/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:15 +0200] "POST / HTTP/2" 200 52314 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:17 +0200] "POST / HTTP/2" 200 52297 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:37:07 +0200] "POST / HTTP/2" 200 51845 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"

Come controllare il log

cPanel offre uno strumento: Raw access log, Accesso non elaborato nella versione italiana.

Da qui vedi un lista dei siti sul tuo account, basta cliccare sul nome del log da scaricare, probabilmente dovrai scaricare la versione che indica SSL tra parentesi:

Scompatti il file, lo apri con un editor di testo e cerchi la stringa:

/wp-content/plugins/elementor-pro/changelog.txt

Oppure gli IP che iniziano per:

193.169.194.

Nota che l’IP potrebbe cambiare, se noti che vengono usati IP diversi avvisaci per poter aggiornare questo articolo.

Conclusioni

Il tuo sito è a rischio solo se usi WooCommerce ed Elementor Pro in versione inferiore o uguale alla 3.11.6

Puoi risolvere la vulnerabilità aggiornando Elementor Pro.

Se non puoi aggiornare Elementor Pro per qualche motivo puoi controllare la soluzione alternativa e modificare alcuni files di Elementor Pro.

Questo articolo ti è stato utile? Hai dubbi, domande o consigli per migliorare questo articolo ed evitare che altri siti vengano bucati? Fammelo sapere in un commento!

Ivan

Fondatore di SupportHost. Con oltre 10 anni di esperienza nel web hosting, lavora ogni giorno per migliorare il servizio e riservare attenzione a ogni singolo cliente.

Commenti

2 risposte a “Vulnerabilità Elementor PRO: come risolvere ed evitare danni”

Stefano

30 Marzo 2023

Considerando che PRO vuol dire soldi mi sembra una grave mancanza quella di non fare controlli sui form…
Io poi ho una certa allergia ai Page builder.

Rispondi
1. Ivan Messina
  
  30 Marzo 2023
  
  Diciamo che è leggermente più complessa di un controllo sui form.
  
  Sicuramente un errore evitabile, anzi un doppio errore, visto che parte era su Elementor free, che permetteva di vedere il nonce.
  
  Rispondi

50% di sconto fino a Sabato