Le 29 décembre 2020, l’équipe de Wordfence Threat Intelligence a été alertée d’une vulnérabilité potentielle à 0 jour dans le Télécharger des fichiers WooCommerce plugin, un add-on pour WooCommerce avec plus de 5000 installations.

Veuillez noter qu’il s’agit d’un plugin distinct du plugin principal de WooCommerce et qu’il est conçu comme un module complémentaire à ce plugin.

Après avoir confirmé la vulnérabilité, nous avons contacté le développeur du plugin, Domenico Lagudi, qui a répondu rapidement et a publié un correctif le même jour, le 29 décembre 2020.

Bien que les règles intégrées du pare-feu Wordfence aient fourni un certain degré de protection contre cette vulnérabilité, nous avons déterminé qu’un contournement était possible. Nous avons rapidement publié une règle de pare-feu pour nos clients premium le 29 décembre 2020. Les sites exécutant toujours la version gratuite de Wordfence ont reçu la règle de pare-feu 30 jours plus tard, le 28 janvier 2021.

Description: Téléchargement de fichiers arbitraires non authentifiés
Plugin concerné: Télécharger des fichiers WooCommerce
Plugin Slug: woocommerce-upload-files
Versions concernées:
ID CVE: CVE-2021-24171
Score CVSS: 9.8 (critique)
Vecteur CVSS: CVSS: 3.1 / AV: N / AC: L / PR: N / UI: N / S: U / C: H / I: H / A: H
Version entièrement corrigée: 59,4

WooCommerce Upload Files est un plugin premium conçu pour permettre aux clients de télécharger des fichiers lors de la vérification afin d’acheter des produits personnalisés. Afin de fournir cette fonctionnalité, il utilise une fonction AJAX accessible au public, ajax_manage_file_chunk_upload.

	function ajax_manage_file_chunk_upload()
	{
		global $wcuf_session_model ;
		
		if(!isset($_POST['wcuf_upload_field_name']))
			wp_die();
		
		$this->saving_on_session = true;
		$buffer = 5242880; //1048576; //1mb
		$target_path = $this->get_temp_dir_path();
		$tmp_name = $_FILES['wcuf_file_chunk']['tmp_name'];
		$size = $_FILES['wcuf_file_chunk']['size'];
		$current_chunk_num = $_POST['wcuf_current_chunk_num'];
		$file_name = str_replace($this->to_remove_from_file_name, "",$_POST['wcuf_file_name']);
		$tmp_file_name = $_POST['wcuf_current_upload_session_id']."_".$file_name;
		$upload_field_name = str_replace($this->to_remove_from_file_name, "", $_POST['wcuf_upload_field_name']);
		$wcuf_is_last_chunk = $_POST['wcuf_is_last_chunk'] == 'true' ? true : false;
	
		$com = fopen($target_path.$tmp_file_name, "ab");
		$in = fopen($tmp_name, "rb");
			if ( $in ) 
				while ( $buff = fread( $in, $buffer ) ) 
				   fwrite($com, $buff);
				 
			fclose($in);
		fclose($com);
		
		wp_die();
	}

Les noms de fichiers étaient basés sur une combinaison de wcuf_current_upload_session_id paramètre et le wcuf_file_name paramètre. Bien que la fonction ait tenté d’empêcher le téléchargement de fichiers avec des extensions exécutables, elle l’a fait en vérifiant le nom de fichier fourni dans le wcuf_file_name par rapport à une liste d’extensions dangereuses, puis en supprimant l’extension du nom de fichier au lieu de bloquer la demande.

	var $to_remove_from_file_name = array(".php", "../", ".jsp", ".vbs", ".exe", ".bat", ".php5", ".pht", ".phtml", 
										  ".shtml", ".asa", ".cer", ".asax", ".swf", ".xap", ";", ".asp", ".aspx",
										  "*", "<", ">", "::");

Par exemple, télécharger un fichier avec un wcuf_current_upload_session_id paramètre défini sur session1 et le wcuf_file_name paramètre défini sur shell.php entraînerait le nom du fichier effectivement téléchargé session1_shell comme le .php l’extension serait supprimée. La fonction n’a exécuté le processus de nettoyage qu’une seule fois, elle pouvait donc être contournée en envoyant un nom de fichier contenant une extension bloquée cachée dans une autre extension bloquée. Par exemple, si un attaquant a téléchargé un fichier avec le wcuf_current_upload_session_id paramètre défini sur session1 et le wcuf_file_name mis à shell.p.phphp, le milieu .php serait supprimé, laissant le nom de fichier final comme session1_shell.php.

Malheureusement, le wcuf_current_upload_session_id Le paramètre n’était pas non plus suffisamment nettoyé et était vulnérable à la traversée de répertoire. Par exemple, si une demande a été envoyée avec le wcuf_current_upload_session_id paramètre défini sur ../../../../file et le wcuf_file_name mis à info.p.phphp, le fichier résultant serait nommé file_info.php et finirait dans la racine Web.

Cela signifiait également qu’une attaque à double extension était possible. Par exemple, définir le wcuf_file_name paramètre à test et le wcuf_current_upload_session_id paramètre à info.php. donnerait un nom de fichier de info.php._test qui serait exécutable dans les environnements Apache qui utilisent un AddHandler directive pour les fichiers PHP.

Quelle que soit la méthode utilisée, un attaquant capable de télécharger un fichier PHP exécutable sur un site Web en utilisant cette méthode serait en mesure d’infecter et de prendre complètement en charge ce site Web, ainsi que tout autre site sur le même compte d’hébergement.

Soyez prudent avec la désinfection des entrées

Alors que de plus en plus de développeurs WordPress se concentrent sur la sécurité, les vulnérabilités simples deviennent de moins en moins courantes. Bien que la plupart des développeurs soient conscients de l’importance de la désinfection des entrées, il est également important d’utiliser les bonnes fonctions pour la bonne entrée, sinon la désinfection peut en fait être utilisée pour contourner les fonctionnalités de sécurité. Il est important de comprendre le type d’entrée qu’une fonction attend et les dangers qu’elle peut présenter. Par exemple, une fonction conçue pour nettoyer l’entrée à utiliser dans une requête de base de données peut ne pas offrir une protection suffisante contre les scripts intersites (XSS), tandis qu’une fonction conçue pour supprimer les balises de script peut ne pas offrir de protection contre l’injection SQL (SQLi). En règle générale, il vaut mieux bloquer complètement les entrées malveillantes que d’essayer de les nettoyer avec la mauvaise fonction.

Chronologie

29 décembre 2020
08h25 MST – Wordfence Threat Intelligence prend connaissance d’un potentiel 0-day dans le plugin WooCommerce Upload Files.
09:09 MST – Nous trouvons le code vulnérable et développons un exploit de preuve de concept.
09:48 MST – Nous écrivons une règle de pare-feu pour bloquer l’exploit et commencer les tests.
10:36 MST – Nous prenons contact avec le développeur du plugin.
11h10 MST – Le développeur du plugin répond et nous fournissons une divulgation complète.
13:33 MST – Le développeur du plugin publie une version corrigée.
18h09 MST – Notre règle de pare-feu passe les tests finaux et est publiée pour les clients Wordfence Premium.

28 janvier 2021
La règle de pare-feu devient disponible pour les utilisateurs Wordfence gratuits.

Conclusion

Dans l’article d’aujourd’hui, nous avons détaillé une vulnérabilité critique de 0 jour dans le plugin WooCommerce Upload Files qui aurait permis aux attaquants d’infecter et de prendre complètement le contrôle d’un site Web. Cette vulnérabilité a été corrigée dans la version 59.4, et nous recommandons à tous les utilisateurs de mettre à jour vers la dernière version du plugin dès que possible, qui est 60.1 au moment de la rédaction de cet article.

Wordfence Premium les utilisateurs sont protégés contre cette vulnérabilité depuis le 29 décembre 2020, tandis que les sites exécutant toujours la version gratuite de Wordfence ont bénéficié de la même protection le 28 janvier 2021.

Si vous connaissez un ami ou un collègue qui utilise ce plugin sur son site, nous vous recommandons vivement de lui transmettre cet avis pour aider à garder ses sites protégés car il s’agit d’un problème de gravité critique pouvant entraîner l’exécution de code à distance et la prise de contrôle du site.

Un merci spécial au développeur de plugins Domenico Lagudi pour sa réponse extrêmement rapide et à l’analyste des menaces Greg Bloom pour son aide à déployer une règle de pare-feu pendant les heures de vacances.


Source link