Le 12 juin 2020, Wordfence Threat Intelligence a découvert une vulnérabilité XSS (Cross-Site Scripting) stockée non authentifiée dans TC Custom JavaScript, un plugin WordPress avec plus de 10000 installations.

Les clients de Wordfence Premium ont reçu une nouvelle règle de pare-feu pour fournir une protection contre les attaques ciblant cette vulnérabilité le même jour. Les utilisateurs de Wordfence utilisant toujours la version gratuite ont reçu cette règle après 30 jours, le 12 juillet 2020.

Nous avons tenté de contacter le développeur du plugin le même jour, le 12 juin 2020, mais nous n’avons pas reçu de réponse. Après 10 jours sans réponse initiale, nous avons contacté l’équipe des plugins WordPress le 22 juin 2020. Un correctif initial a été publié le lendemain, le 23 juin 2020, et un correctif complet a été publié le 29 juin 2020.

La description: Scripts intersites stockés non authentifiés (XSS)
Plugin concerné: JavaScript personnalisé TC
Plugin Slug: tc-personnalisé-javascript
Versions concernées: <1.2.2
ID CVE: CVE-2020-14063
Score CVSS: 8,3 (élevé)
Vecteur CVSS: CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: L / I: L / A: L
Version entièrement corrigée: 1.2.2

TC Custom JavaScript est un plugin WordPress qui permet aux propriétaires de sites d’ajouter du JavaScript personnalisé à chaque page d’un site et met l’accent sur une approche minimaliste. Bien que ce type de fonctionnalité puisse être incroyablement utile, il peut également être incroyablement dangereux sans contrôles d’accès appropriés.

Ce plugin exécutait le TCCJ_Core_Content::update fonctionner immédiatement au démarrage. C’était inhabituel, car la plupart des plugins WordPress enregistrent des fonctions à exécuter à des points prévisibles dans le processus de chargement de WordPress.

En conséquence, le update fonctionnait avant que les fonctions de contrôle d’accès WordPress, telles que les vérifications de capacités et la vérification nonce, ne puissent être utilisées. Ceci, combiné au manque de contrôles de capacité et de vérification nonce sur la fonction, a permis aux visiteurs non autorisés d’utiliser le update fonction.

le update fonction a utilisé une fonction compagnon, has_update_request, pour vérifier si le tccj-update POST paramètre a été fourni et réglé sur Update. Si cette vérification réussit, alors le update fonction accepterait le contenu du tccj-content POST et ajoutez-le à la base de données.

class TCCJ_Core_Content {
	public static function update() {
		if ( self::has_update_request() ) {
			if ( get_magic_quotes_gpc() )
				$tccj_content = stripslashes( $_POST['tccj-content'] );
			else
				$tccj_content = $_POST['tccj-content'];

			// Sanitizing data before insert to database
			$tccj_content = wp_check_invalid_utf8( $tccj_content, true );
			$tccj_content = htmlentities( $tccj_content );

			if ( ! get_magic_quotes_runtime() )
				$tccj_content = addslashes( $tccj_content );

			update_option( 'tccj_content', $tccj_content );
		}
	}

	private static function has_update_request() {
		if ( isset( $_POST['tccj-update'] ) && ( $_POST['tccj-update'] == 'Update' ) )
			return true;
		else
			return false;
	}
}

Tandis que le update la fonction a fonctionné htmlentities sur le contenu fourni par tccj-content avant de le stocker, cela n’offrait aucune sécurité supplémentaire, car le TCCJ_Core_Frontend::print_script_in_footer fonction utilisée pour afficher le script ajouté non seulement utilisé html_entity_decode sur le contenu stocké mais aussi ajouté '; } } }

En tant que tel, un attaquant pourrait envoyer un POST demande à n'importe quel endroit sur un site vulnérable avec le tccj-update paramètre défini sur Update et le tccj-content paramètre défini sur JavaScript malveillant, et ce JavaScript s'afficherait dans le pied de page de chaque page du site.

Un code JavaScript malveillant de ce type peut être utilisé pour rediriger les visiteurs vers des sites de publicité malveillante ou pour voler des informations de paiement. Pire encore, il peut détecter lorsqu'un administrateur visite le site et envoie une demande en son nom pour infecter des fichiers avec une porte dérobée ou éventuellement créer un nouveau compte utilisateur administrateur malveillant conduisant à la prise de contrôle de l'ensemble du site.

Chronologie

12 juin 2020 - Wordfence Threat Intelligence découvre une vulnérabilité dans TC Custom JavaScript. Nous publions une règle de pare-feu disponible pour les utilisateurs de Wordfence Premium et tentons de prendre contact avec le développeur du plugin.
22 juin 2020 - Après avoir échoué à prendre contact avec le développeur du plugin, nous contactons l'équipe WordPress Plugins pour l'informer de la vulnérabilité.
23 juin 2020 - Le développeur du plugin publie un correctif initial qui est toujours vulnérable aux attaques CSRF.
29 juin 2020 - Une version entièrement corrigée du plugin est publiée.
12 juillet 2020 - La règle de pare-feu devient disponible pour les utilisateurs gratuits de Wordfence.

Conclusion

Dans l’article d’aujourd’hui, nous avons examiné une vulnérabilité XSS (Cross-Site Scripting) non authentifiée dans le plug-in JavaScript personnalisé TC. Cette faille a été entièrement corrigée dans la version 1.2.2 et nous vous recommandons fortement de mettre à jour cette version dès que possible. Sites en cours d'exécution Wordfence Premium sont protégés contre ces vulnérabilités depuis le 12 juin 2020, tandis que les sites utilisant encore la version gratuite de Wordfence ont reçu la règle de pare-feu le 12 juillet 2020.

Un merci spécial à Matt Rusnak, responsable de l'assurance qualité de Wordfence, qui a initialement découvert la vulnérabilité.


Source link