La vulnérabilité expose plus de 4 millions de sites utilisant WPBakery

Le 27 juillet, notre équipe Threat Intelligence a découvert une vulnérabilité dans WPBakery, un plugin WordPress installé sur plus de 4,3 millions de sites. Cette faille a permis aux attaquants authentifiés avec des autorisations de niveau contributeur ou supérieures d’injecter du JavaScript malveillant dans les publications.

Nous avons initialement contacté l’équipe du plugin le 28 juillet 2020 via leur forum de support. Après avoir reçu la confirmation du canal de support approprié, nous avons divulgué tous les détails le 29 juillet 2020. Ils ont confirmé la vulnérabilité et ont signalé que leur équipe de développement avait commencé à travailler sur un correctif le 31 juillet 2020. Après une longue période de correspondance avec le équipe de développement de plugins, et un certain nombre de correctifs insuffisants, un correctif final suffisant a été publié le 24 septembre 2020.

Nous vous recommandons vivement de mettre à jour immédiatement vers la dernière version, 6.4.1, à compter d’aujourd’hui. Ce faisant, nous vous recommandons également de vérifier que vous n’avez aucun compte utilisateur contributeur ou auteur non approuvé sur votre site WordPress.

Les utilisateurs de Wordfence Premium sont protégés contre les exploits ciblant ces vulnérabilités depuis le 28 juillet 2020. Les utilisateurs gratuits de Wordfence ont reçu la même protection le 28 août 2020.

Le constructeur de pages WPBakery est le constructeur de pages le plus populaire pour WordPress. C’est un outil très facile à utiliser qui permet aux propriétaires de sites de créer des pages personnalisées à l’aide de fonctionnalités de glisser-déposer.

Malheureusement, le plugin a été conçu avec une faille qui pourrait donner aux utilisateurs avec des rôles de contributeur et d’auteur la possibilité d’injecter du JavaScript malveillant dans les pages et les articles. Cette faille a également donné à ces utilisateurs la possibilité de modifier les publications d’autres utilisateurs. Le plugin a explicitement désactivé toutes les vérifications de filtrage HTML de publication par défaut dans le saveAjaxFe fonction utilisant kses_remove_filters();. Cela signifiait que tout utilisateur ayant accès au générateur WPBakery pouvait injecter du HTML et du JavaScript n’importe où dans une publication à l’aide du générateur de page.

	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 );

De plus, bien que WPBakery ne prévoyait que les pages créées avec le générateur de page WPBakery pour être modifiables via le générateur, les utilisateurs pouvaient accéder à l’éditeur en fournissant les paramètres et les valeurs corrects pour n’importe quel article. Cela pourrait être classé comme un bogue général ainsi que comme un problème de sécurité, et c’est ce qui a permis aux contributeurs et aux éditeurs d’utiliser le wp_ajax_vc_save Action AJAX et correspondant saveAjaxFe fonction d’injecter du JavaScript malveillant sur leurs propres publications ainsi que sur les publications d’autres utilisateurs.

Le plugin avait également une fonctionnalité onclick personnalisée pour les boutons. Cela a permis à un attaquant d’injecter du JavaScript malveillant dans un bouton qui s’exécuterait en un clic. De plus, les utilisateurs de niveau contributeur et auteur ont pu utiliser le vc_raw_js, vc_raw_html, et bouton utilisant custom_onclick shortcodes pour ajouter du JavaScript malveillant aux publications.

Tout cela signifiait qu’un utilisateur disposant d’un accès de niveau contributeur pouvait injecter des scripts dans les publications qui s’exécuteraient plus tard une fois que quelqu’un accédait à la page ou cliquait sur un bouton, en utilisant différentes méthodes. Étant donné que les utilisateurs de niveau contributeur nécessitent une approbation avant de publier, il est fort probable qu’un administrateur affichera une page contenant du JavaScript malveillant créé par un attaquant disposant d’un accès de niveau contributeur. En exécutant du JavaScript malveillant dans le navigateur de l’administrateur, il serait possible pour un attaquant de créer un nouvel utilisateur administratif malveillant ou d’injecter une porte dérobée, entre autres.

Dans la dernière version de WPBakery, les utilisateurs de niveau inférieur n’ont plus unfiltered_html capacités par défaut, cependant, les administrateurs peuvent accorder cette autorisation s’ils le souhaitent. De plus, les utilisateurs ne disposant pas des privilèges appropriés ne peuvent plus modifier les publications des autres utilisateurs, accéder au générateur de page sauf autorisation, ou utiliser des codes courts qui pourraient permettre l’injection de JavaScript malveillant.

Contrôle de double compte

Une stratégie pour protéger votre site contre les attaques de type Cross-Site Scripting contre les comptes à privilèges plus élevés consiste à utiliser des comptes doubles. Le contrôle de double compte utilise deux comptes pour tout utilisateur pouvant nécessiter une capacité administrative. Cela peut être fait en utilisant un compte utilisateur avec des capacités administratives pour les tâches liées à l’administration comme l’ajout de nouveaux utilisateurs et plugins et un autre compte utilisateur avec des capacités d’éditeur utilisé pour examiner et approuver les publications des auteurs et des contributeurs.

Cela limitera l’impact qu’une vulnérabilité de script intersite peut avoir. Lorsque vous accédez à une page en tant qu’administrateur de site, tout JavaScript malveillant injecté par un attaquant peut utiliser uniquement des fonctions administratives telles que l’ajout d’un nouvel utilisateur ou la modification d’un fichier de thème pour infecter davantage le site. En utilisant un compte utilisateur avec uniquement des capacités d’éditeur lors de l’édition, de la création et de la vérification des publications créées par des utilisateurs de niveau inférieur, une tentative d’exploitation XSS pourrait être limitée, car un attaquant ne peut pas ajouter avec succès de nouveaux comptes d’administrateur ou modifier des thèmes via un éditeur. Compte.

En particulier dans les cas où de nombreux utilisateurs peuvent accéder à des actions authentifiées, nous vous recommandons d’utiliser un compte d’utilisateur administratif uniquement lorsque vous devez effectuer des fonctions administratives sur votre site.

Calendrier de divulgation

27 juillet 2020 – Découverte initiale de la vulnérabilité. Nous développons une règle de pare-feu et la déplaçons dans la phase de test.
28 juillet 2020 – La règle de pare-feu est suffisamment testée et publiée pour les utilisateurs premium. Nous faisons notre premier contact avec l’équipe du plugin WPBakery.
29 juillet 2020 – L’équipe WPBakery répond en confirmant la boîte de réception appropriée et nous envoyons tous les détails de divulgation.
21 août 2020 – Après quelques suivis, un patch initial est publié.
26 août 2020 – Nous informons l’équipe WPBakery qu’il y a quelques problèmes mineurs supplémentaires manqués qui doivent être résolus.
28 août 2020 – Les utilisateurs gratuits de Wordfence reçoivent la règle de pare-feu.
2 septembre 2020 – Nous faisons un suivi pour voir si l’équipe WPBakery a reçu notre dernier e-mail.
9 septembre 2020 – L’équipe WPBakery confirme avoir reçu notre e-mail et travaille à la publication d’un correctif supplémentaire.
11 septembre 2020 – L’équipe WPBakery publie un correctif supplémentaire qui n’est pas entièrement suffisant.
11 au 23 septembre 2020 – Nous travaillons plus étroitement ensemble pour obtenir un correctif adéquat.
24 septembre 2020 – Patch final suffisant publié en version 6.4.1.

Conclusion

Dans l’article d’aujourd’hui, nous avons détaillé une faille dans le plugin WPBakery qui permettait aux utilisateurs authentifiés d’injecter du JavaScript malveillant dans les publications à l’aide du générateur de pages WPBakery. Parallèlement à cela, nous avons fourni des informations sur la façon dont vous pouvez vous protéger contre les vulnérabilités au niveau des contributeurs et des auteurs. Cette faille a été entièrement corrigée dans la version 6.4.1. Nous recommandons aux utilisateurs de mettre immédiatement à jour vers la dernière version disponible, qui est la version 6.4.1 au moment de cette publication.

Comme WPBakery est un plugin premium souvent inclus en tant que constructeur de page avec de nombreux thèmes premium, vous devrez peut-être vérifier que toutes les mises à jour sont disponibles pour vous avec votre achat de thème. La vérification du numéro de version du plugin dans votre tableau de bord des plugins devrait vous alerter de la version installée sur votre site.

Sites utilisant Wordfence Premium sont protégés contre les attaques tentant d’exploiter cette vulnérabilité depuis le 28 juillet 2020. Les sites utilisant encore la version gratuite de Wordfence ont reçu la même protection le 28 août 2020.

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’une mise à jour de sécurité importante.