Il y a quelques semaines, notre équipe Threat Intelligence a découvert plusieurs vulnérabilités présentes dans Page Builder: PageLayer – Constructeur de site Web par glisser-déposer, un plugin WordPress installé activement sur plus de 200 000 sites. Le plugin provient des mêmes créateurs que wpCentral, un plugin dans lequel nous avons récemment découvert une vulnérabilité d’élévation de privilèges.

Une faille a permis à tout utilisateur authentifié disposant d’autorisations de niveau abonné et supérieur de mettre à jour et de modifier des publications avec un contenu malveillant, entre autres choses. Une deuxième faille a permis aux attaquants de forger une demande au nom de l’administrateur d’un site pour modifier les paramètres du plugin, ce qui pourrait permettre une injection Javascript malveillante.

Nous avons initialement contacté le développeur du plugin le 30 avril 2020 et après avoir établi un canal de communication approprié, nous avons fourni la divulgation complète le 1er mai 2020. Ils ont répondu rapidement le 2 mai 2020 en nous faisant savoir qu’ils commençaient à travailler sur corrections. Un patch initial a été publié le 2 mai 2020 et un patch optimal a été publié le 6 mai 2020.

Ceux-ci sont considérés comme des problèmes de sécurité de haut niveau qui pourraient potentiellement conduire à ce que des attaquants effacent le contenu de votre site ou prennent le contrôle de votre site. Nous recommandons fortement une mise à jour immédiate de la dernière version disponible au moment de cette publication, qui est la version 1.1.4.

Les clients Wordfence Premium ont reçu une nouvelle règle de pare-feu le 30 avril 2020 pour se protéger contre les exploits ciblant cette vulnérabilité. Les utilisateurs de Wordfence gratuits recevront cette règle après trente jours, le 30 mai 2020.

PageLayer est un plugin de création de page WordPress très facile à utiliser qui prétend fonctionner avec presque tous les thèmes sur le marché et dans le référentiel WordPress. Il offre une personnalisation étendue des pages grâce à l’utilisation de widgets qui peuvent ajouter des éléments de page tels que des boutons, des tableaux, des extraits, des produits et plus encore.

Nous avons découvert que presque tous les points de terminaison d’action AJAX de ce plugin ne comprenaient pas de vérification des autorisations. Cela signifiait que ces actions pouvaient être exécutées par toute personne authentifiée sur le site, y compris les utilisateurs de niveau abonné. En standard, ces points de terminaison AJAX ont uniquement vérifié si une demande venait de / wp-admin via une session authentifiée et n’ont pas vérifié les capacités de l’utilisateur envoyant la demande.

Il y avait des vérifications de nonce dans toutes ces fonctions, mais les nonces peuvent être facilement compromis s’ils sont incorrectement implémentés – par exemple, si un nonce utilisable est affiché dans le code source de la sortie du site. Malheureusement pour le plugin PageLayer, c’est précisément ce qui s’est passé. Un nonce utilisable était visible dans la section d’en-tête du code source de toute page précédemment modifiée à l’aide du plugin PageLayer. Tout visiteur du site peut trouver ce nonce, qu’il soit connecté ou non, permettant à tout utilisateur non authentifié d’obtenir un nonce légitime pour les actions AJAX du plugin.

PageLayer nonce pouvant être obtenu à partir de la page source.

L’utilisation d’un seul nonce comme mécanisme de contrôle des autorisations a provoqué divers problèmes de sécurité dans les fonctionnalités du générateur de pages, car ce nonce peut être facilement obtenu.

Les nonces WordPress ne doivent jamais être utilisés comme moyen d’autorisation car ils peuvent facilement être compromis s’ils sont mis en œuvre de manière incorrecte ou si une faille est trouvée. Les nonces WordPress sont conçus pour être utilisés pour la protection CSRF, pas pour le contrôle des autorisations. L’implémentation de vérifications de capacité conjointement avec la protection CSRF sur les fonctions sensibles pour une vérification complète offre une protection pour garantir qu’une demande provient d’un utilisateur autorisé.

L’impact

Comme mentionné précédemment, plusieurs fonctions AJAX ont été affectées, provoquant une grande variété d’impacts potentiels. Quelques-unes des actions les plus marquantes ont été wp_ajax_pagelayer_save_content, wp_ajax_pagelayer_update_site_title, et wp_ajax_pagelayer_save_template.

add_action('wp_ajax_pagelayer_save_content', 'pagelayer_save_content');
add_action('wp_ajax_pagelayer_update_site_title', 'pagelayer_update_site_title');
add_action('wp_ajax_pagelayer_save_template', 'pagelayer_save_template');

le pagelayer_save_content La fonction est utilisée pour enregistrer les données d’une page via le générateur de page. L’absence de vérification des autorisations sur cette fonction a permis aux utilisateurs authentifiés, quelles que soient leurs autorisations, de modifier toutes les données d’une page éditée avec PageLayer.

function pagelayer_save_content(){

	// Some AJAX security
	check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');

	$content = $_POST['pagelayer_update_content'];

	$postID = (int) $_GET['postID'];

	if(empty($postID)){
		$msg['error'] =  __pl('invalid_post_id');
	}

Un attaquant pourrait effacer complètement les pages ou injecter le contenu qu’il souhaite sur les pages et les publications du site. De plus, quelques widgets ont permis d’injecter Javascript, dont le widget “Button”. Il n’y a pas de nettoyage sur le texte du widget “Bouton”, ce qui permet d’utiliser du Javascript malveillant comme texte. Ce Javascript s’exécuterait une fois qu’un utilisateur aurait accédé à une page contenant ce bouton.

Bouton PageLayer avec alerte JS injecté.

le pagelayer_update_site_title est utilisée pour mettre à jour le titre d’un site. L’absence de vérification des autorisations sur cette fonction a permis aux utilisateurs authentifiés de changer le titre d’un site en n’importe quel titre de leur choix. Bien que moins préjudiciable, cela pourrait toujours affecter le classement des moteurs de recherche de votre site s’il n’est pas remarqué pendant une longue période.

function pagelayer_update_site_title(){
	global $wpdb;

	// Some AJAX security
	check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');

	$site_title = $_POST['site_title'];

	update_option('blogname', $site_title);

	$wpdb->query("UPDATE `sm_sitemeta` 
				SET meta_value = '".$site_title."'
				WHERE meta_key = 'site_name'");
	wp_die();
}

le pagelayer_save_template La fonction est utilisée pour enregistrer les modèles PageLayer pour le générateur de thèmes PageLayer. L’absence de vérification des autorisations sur cette fonction a permis aux utilisateurs authentifiés de créer de nouveaux modèles PageLayer enregistrés en tant que nouveaux messages.

function pagelayer_save_template() {
	
	// Some AJAX security
	check_ajax_referer('pagelayer_ajax', 'pagelayer_nonce');
	
	$done = [];
	
	$post_id = (int) $_GET['postID'];
	
	// We need to create the post
	if(empty($post_id)){
	
		// Get the template type
		if(empty($_POST['pagelayer_template_type'])){
			$done['error'] = __pl('temp_error_type');
			pagelayer_json_output($done);
		}
		
		$ret = wp_insert_post([
			'post_title' => $_POST['pagelayer_lib_title'],
			'post_type' => 'pagelayer-template',
			'post_status' => 'publish',
			'comment_status' => 'closed',
			'ping_status' => 'closed'
		]);

Bien que cette fonction soit destinée à être utilisée dans la version PRO du plugin, la fonction pouvait toujours être exécutée dans la version gratuite, affectant tous les 200 000 utilisateurs et plus du plugin PageLayer. Un attaquant pourrait créer un nouveau modèle, ce qui a créé une nouvelle page sur le site, et injecter du Javascript malveillant de la même manière qu’avec le pagelayer_save_content une fonction.

Javascript malveillant peut être utilisé pour injecter de nouveaux utilisateurs administratifs, rediriger les visiteurs du site et même exploiter le navigateur de l’utilisateur d’un site pour compromettre son ordinateur.

Le patch

Dans la dernière version du plugin, les développeurs ont implémenté des vérifications des autorisations sur toutes les fonctions sensibles qui pourraient apporter des modifications à un site, et ont reconfiguré le plugin pour créer des zones distinctes pour les zones publiques et administratives d’un site WordPress.

	// Are you allowed to edit ?
	if(!pagelayer_user_can_edit($postID)){
		$msg['error'][] =  __pl('no_permission');
		pagelayer_json_output($msg);
	}

Le plugin PageLayer enregistre une zone de paramètres où des modifications de configuration peuvent être apportées. Cela inclut des fonctionnalités telles que l’emplacement où l’éditeur est activé, les paramètres de contenu de base, les configurations d’informations de base, etc.

Zone de paramètres de PageLayer.

La fonction de mise à jour des paramètres a utilisé une vérification des capacités pour vérifier qu’un utilisateur tentant d’apporter des modifications dispose des autorisations appropriées. Cependant, il n’y avait aucune protection CSRF pour vérifier la légitimité de toute demande tentant de mettre à jour les paramètres d’un site. Cela a permis aux attaquants d’inciter un administrateur à envoyer une demande de mise à jour des paramètres de PageLayer.

function pagelayer_settings_page(){

	$option_name = 'pl_gen_setting' ;
	$new_value = '';

	if(isset($_REQUEST['pl_gen_setting'])){
		$new_value = $_REQUEST['pl_gen_setting'];
		
		if ( get_option( $option_name ) !== false ) {
	
			// The option already exists, so we just update it.
			update_option( $option_name, $new_value );

L’onglet «Informations» dans la zone des paramètres permet aux propriétaires de sites de définir une adresse, un numéro de téléphone et une adresse e-mail de contact par défaut qui s’affichent chaque fois que les widgets correspondants sont utilisés sur une page. Il n’y a pas eu de nettoyage des paramètres d’adresse ou de numéro de téléphone, et en raison de la capacité de l’administrateur à utiliser unfiltered_html, Javascript pourrait être injecté dans ces paramètres.

Adresse de PageLayer mise à jour avec l’alerte JS.

L’impact

Cela a permis aux attaquants d’injecter des scripts malveillants tout en exploitant la vulnérabilité CSRF dans les paramètres. Si le widget était déjà activé, tout script malveillant injecté s’exécutait chaque fois que quelqu’un accédait à une page contenant ce widget. Si le widget n’était pas encore activé, les scripts malveillants pouvaient être exécutés une fois qu’un administrateur avait commencé à modifier et à insérer le widget dans une page. Comme toujours, ces scripts peuvent faire des choses comme créer un nouveau compte administratif et rediriger les utilisateurs vers des sites malveillants.

Le patch

Dans la version corrigée du plugin, les développeurs ont implémenté la protection CSRF consistant en un nonce WordPress et une vérification de ce nonce lors de la mise à jour des paramètres.

	if(isset($_REQUEST['submit'])){
		check_admin_referer('pagelayer-options');
	}

24 avril 2020 au 30 avril 2020 – Découverte initiale d’une faille de sécurité mineure et analyse de sécurité plus approfondie du plugin.
30 avril 2020 – La règle de pare-feu a été publiée pour les clients Wordfence Premium. Nous avons fait notre première tentative de contact avec l’équipe de développement du plugin.
1 mai 2020 – L’équipe de développement du plugin confirme la boîte de réception appropriée pour gérer la discussion. Nous fournissons une divulgation complète.
2 mai 2020 – Le développeur accuse réception et confirme qu’il commence à travailler sur les correctifs. Une mise à jour est publiée le même jour.
4 mai 2020 – Nous analysons les correctifs et découvrons quelques problèmes de sécurité non corrigés et divulguons ces problèmes de manière responsable au développeur.
6 mai 2020 – Le développeur publie le correctif final suffisant.
30 mai 2020 – Les utilisateurs de Wordfence gratuits reçoivent une règle de pare-feu.

Dans la publication d’aujourd’hui, nous avons détaillé plusieurs failles liées aux actions AJAX non protégées et à la divulgation de nonce qui permettaient aux attaquants d’apporter plusieurs modifications malveillantes aux pages et aux publications d’un site en plus d’offrir aux attaquants la possibilité d’injecter du Javascript malveillant. Ces failles ont été entièrement corrigées dans la version 1.1.2. Nous recommandons aux utilisateurs de mettre immédiatement à jour la dernière version disponible, qui est la version 1.1.4 au moment de cette publication.

Sites en cours d’exécution Wordfence Premium sont protégés des attaques contre cette vulnérabilité depuis le 30 avril 2020. Les sites exécutant la version gratuite de Wordfence recevront cette mise à jour des règles de pare-feu le 30 mai 2020. Si vous connaissez un ami ou un collègue qui utilise ce plugin sur leur site, nous recommande fortement de leur transmettre cet avis pour aider à protéger leurs sites.


Source link

%d blogueurs aiment cette page :