Le 13 février, notre équipe Threat Intelligence a découvert une vulnérabilité dans wpCentral, un plugin WordPress installé sur plus de 60 000 sites. La faille a permis à quiconque d’élever ses privilèges à ceux d’un administrateur, y compris les utilisateurs de niveau abonné auxquels un enregistrement ouvert a été activé sur un site WordPress avec le plugin vulnérable installé.

La faille permettait également le contrôle à distance du site via le tableau de bord administratif wpCentral. Cela serait considéré comme une vulnérabilité de contrôle d’accès incorrecte qui a conduit à une élévation de privilèges. Nous avons divulgué en privé tous les détails au développeur du plugin le 13 février, et ils ont réagi rapidement en publiant un correctif le lendemain avec quelques améliorations de sécurité supplémentaires.

Il s’agit d’un problème de sécurité très grave qui pourrait avoir un impact grave sur votre site. Nous vous recommandons vivement de mettre immédiatement à jour la dernière version, 1.5.2.

Les clients de Wordfence Premium ont reçu une nouvelle règle de pare-feu le 14 février pour se protéger contre les exploits ciblant cette vulnérabilité. Les utilisateurs de Wordfence gratuits recevront la règle après trente jours, le 15 mars.

Qu’est-ce que wpCentral?

wpCentral est un plugin WordPress qui a été conçu pour être utilisé en tandem avec le tableau de bord de gestion wpCentral pour fournir une connexion entre les sites WordPress et une interface de gestion. Leur logiciel est conçu pour faciliter la gestion du site, avec des fonctionnalités telles que la connexion automatisée en un clic à partir du tableau de bord wpCentral, la possibilité de créer des sauvegardes, de modifier des publications (dans la version premium), et bien plus encore.

Afin de fournir cette connexion entre le site et le tableau de bord de gestion, le plugin génère une clé d’autorisation aléatoire de 128 caractères, stockée en tant que wpcentral_auth_key, également appelée «clé de connexion». Cette clé est utilisée pour ajouter un site au tableau de bord wpCentral, en plus d’être utilisée comme auth_key lors de l’envoi de demandes depuis le tableau de bord wpCentral. Il s’agit d’un élément important du processus d’authentification et d’autorisation et, en raison de ses capacités, il nécessite des protections strictes pour empêcher toute utilisation non autorisée.

La clé de connexion est toujours affichée dans le pied de page d’administration

Malheureusement, nous avons découvert qu’il y avait des contrôles d’accès faibles en place pour protéger la clé de connexion telle qu’elle était affichée dans admin_footer dans une boîte de dialogue modale.

 add_action('admin_footer', 'wpc_modal_dialog');

Le pied de page d’administration vérifie si une page en cours d’accès fait partie de l’interface d’administration et affiche tout ce qui est demandé dans cette zone. Cependant, il ne vérifie pas que l’utilisateur a des capacités «d’administrateur» – une idée fausse courante avec la série de fonctions qui contiennent l’étiquette «admin». Cela signifiait que tout utilisateur connecté, quelles que soient ses capacités, aurait accès à tout contenu dans la boîte de dialogue modale affichée dans le cadre de admin_footer.

La boîte de dialogue modale qui était affichée dans le cadre du pied de page administrateur exposait la clé de connexion ainsi que les étapes pouvant être utilisées pour connecter un site à wpCentral.

function wpc_modal_dialog(){
    
	$mdialog = '
	';

Cela signifiait qu’un attaquant disposant d’autorisations minimales au niveau de l’abonné aurait la possibilité d’ajouter un site vulnérable à son tableau de bord wpCentral et de prendre le contrôle à distance du site. Ils pourraient faire des choses comme créer une sauvegarde, puis voler les informations du fichier wp-config.php pour accéder à la base de données ou accéder à des informations sensibles.

Capacités de connexion automatique non protégées

La pire chose qu’un attaquant pourrait faire s’il était en mesure d’accéder à la clé auth était la connexion automatique, une fonctionnalité commune aux tableaux de bord de gestion WordPress.

 add_action('wp_ajax_nopriv_my_wpc_signon', 'my_wpc_signon');

Cette fonctionnalité était destinée à être utilisée dans le cadre du tableau de bord wpCentral où un utilisateur clique simplement sur le bouton pour s’authentifier, mais il a simplement envoyé une demande qui pouvait être répliquée par n’importe quel utilisateur. L’autorisation vérifie simplement si le auth_key était le même qui est stocké dans le tableau d’options comme wpcentral_auth_key. Cette clé est persistante, donc si elle est compromise, elle autoriserait n’importe quel utilisateur à envoyer des demandes au nom d’un administrateur de site.

/**
 * Check for the authorization of the request using the auth key
 *
 * @returns		bool
 * @since		1.0
 */
function wpc_authorize(){
    global $l, $error;
	
	$return = array(); 
    
    $auth_key = wpc_optREQ('auth_key');
	if(empty($auth_key)){
		$return['error'] = 'Unauthorized Access!!';
		echo json_encode($return);
		die();
	}
	
	$verify_authkey = wpc_get_option('wpcentral_auth_key');
	if($auth_key != $verify_authkey){
		$return['error'] = $l['invalid_auth_key'];
		echo json_encode($return);
		die();
	}
}

Lorsqu’une demande correctement formatée était envoyée avec la clé d’autorisation appropriée, un utilisateur était automatiquement connecté en tant qu’utilisateur 1 dans la base de données. Il s’agit du premier compte utilisateur créé sur un site et est généralement l’un des principaux utilisateurs administratifs. Une fois connecté, un attaquant aurait libre cours et pourrait injecter des portes dérobées, détruire le site, et bien plus encore.

/**
 * Provides access to the website's admin panel
 *
 * @returns		bool
 * @since		1.0
 */
function my_wpc_signon(){
    global $l, $error;
	
	//Authorize
	wpc_authorize();
	
	$user_info = get_userdata(1);
		
	// Automatic login //
	$username = $user_info->user_login;
	$user = get_user_by('login', $username );
	
	// Redirect URL //
	if (!is_wp_error($user)){
		wp_clear_auth_cookie();
		wp_set_current_user($user->ID);
		wp_set_auth_cookie($user->ID);

		$redirect_to = user_admin_url();
		wp_safe_redirect($redirect_to);

		exit();
	}
}

Heureusement, dans la dernière version de wpCentral, le développeur a implémenté une vérification qui garantit que les demandes sont envoyées à partir de l’adresse IP du serveur wpCentral. Cela garantit que si une clé de connexion est compromise, l’exploitation de masse serait beaucoup plus difficile à mener car les demandes doivent provenir du tableau de bord wpCentral plutôt que d’une simple requête. En outre, la fonctionnalité de connexion automatique semble avoir été désactivée pour le moment.

Démonstration de la preuve de concept

Très important de mettre à jour immédiatement

En raison de la nature unique de cette vulnérabilité, il était difficile de créer une règle de pare-feu offrant une protection complète, car nous ne voulions pas bloquer la fonctionnalité de plug-in légitime. Bien que nous ayons une règle de pare-feu pour protéger votre site, elle ne peut pas fournir une protection complète. Notez que, dans le cadre de la mise à jour du plugin, votre clé wpCentral sera réinitialisée, empêchant les attaquants de maintenir un accès non autorisé à votre site étant donné que la clé de connexion peut avoir été précédemment compromise. Pour ces raisons, nous vous recommandons vivement de mettre à jour la dernière version dès que possible pour garantir la sécurité de votre site.

Calendrier de divulgation

13 février 2020 – Vulnérabilité initialement découverte et analysée. Ouverture initiale au développeur.
14 février 2020 – Le développeur répond et tous les détails sont envoyés. Règle de pare-feu publiée pour les utilisateurs de Wordfence Premium.
14 février 2020 – Patch publié.
15 mars 2020 – Les utilisateurs gratuits de Wordfence reçoivent une règle de pare-feu.

Conclusion

Dans le post d’aujourd’hui, nous détaillons une faille d’élévation de privilèges dans le wpCentral brancher. Cette faille a été corrigée dans la version 1.5.2 et nous recommandons aux utilisateurs de mettre à jour vers la dernière version disponible immédiatement. Sites en cours d’exécution Wordfence Premium sont protégés des attaques contre cette vulnérabilité depuis le 14 février 2020. Les sites exécutant la version gratuite de Wordfence recevront la mise à jour des règles de pare-feu le 15 mars 2020.


Source link