WPS Hide Login v1.5.2.2 Multiples Vulnérabilités

WPS Limit Login est édité par WP Serveur, hébergeur WordPress français. L’indice de criticité de cette mise à jour est faible.

Protection ByPass #1

Fichier : /classes/plugins.php

Lignes : 427 

if ( isset( $request['query'] ) && strpos( $request['query'], 'action=confirmaction' ) !== false ) {

    @require_once ABSPATH . 'wp-login.php';

}

Problème : Il suffit que l’URL contienne “action=confirmaction” pour que la page de login soit accessible. 

Démo : https://example.com/wp-login.php?SECUPRESSaction=confirmaction

Protection ByPass #2

Fichier : /classes/plugins.php

Lignes : 477-480

if ( is_admin() && ! is_user_logged_in() && ! defined( 'DOING_AJAX' ) && $pagenow !== 'admin-post.php' && ( isset( $_GET ) && empty( $_GET['adminhash'] ) && $request['path'] !== '/wp-admin/options.php' ) ) {

wp_safe_redirect( $this->new_redirect_url() );

die();

}

Problème : En lisant le code, on s’aperçoit qu’il suffit d’avoir le paramètre “adminhash” présent dans l’URL pour avoir le droit d’afficher la page de login.

Démo : https://exemple.com/wp-admin/?adminhash=1 

Protection ByPass #3

Fichier : /classes/plugin.php

Lignes : 653-656

if ( ! empty( $_GET ) && isset( $_GET['action'] ) && 'rp' === $_GET['action'] && isset( $_GET['key'] ) && isset( $_GET['login'] ) ) {

wp_redirect( $this->new_login_url() );

exit();

}

Problème : Ce code est actif si on a activé WooCommerce (+ de 60% des e-commerce de WP).

Démo : https://example.com?action=rp&key&login 

Protection ByPass #4

Fichier : /classes/plugin.php

Lignes : 563

if ( strpos( $url, 'wp-login.php' ) !== false ) {

Problème : De nouveau on vérifie la présence d’une chaine dans l’URL pour avoir le droit de donner la nouvelle URL à la place de celle recherchée.

Démo : Il faut modifier son header “Referer” et y mettre juste “wp-login.php” ça suffit. Puis il faut envoyer une requête en POST sur “https://example.com/wp-login.php?action=postpass” vide.

Le code de WordPress fait ceci :

if ( ! array_key_exists( 'post_password', $_POST ) ) {

wp_safe_redirect( wp_get_referer() );

exit();

}

Donc il va lire notre referer, puis passer dans le hook du plugin, et puisque “wp-login.php” est présent, il va nous rediriger vers la nouvelle page de login.

Default Parameter Usage

Fichier : /classes/plugin.php

Problème : Une valeur par défaut est utilisée. Si une personne active le plugin, la page de login vient “login”, donc il me suffit déjà de tenter “login” sur un site pour voir si ils l’ont modifiée ou pas. De plus, “login” est déjà une redirection gérée par WordPress, donc les bots/scripts/pirates connaissent cette URL. 

Full Path Disclosure

Fichier : /classes/plugin.php

Lines : 498

&& ( $result = wpmu_activate_signup( $referer['key'] ) )

Problème : Si on utilise le hook disponible “wps_hide_login_signup_enable” et qu’on déclenche la bonne URL, alors on obtient une erreur fatale car la fonction wpmu_activate_signup() n’est pas déclarée, il manque l’inclusion du fichier qui la contient, le plugin devient alors responsable d’afficher une erreur divulugant des informations sur le chemin complet.

Ces failles ont été corrigées dans la v1.5.3

À propos de Julio Potier Tous les articles de Julio Potier

Créateur de SecuPress et de la Formation LearnWPSecurity, Julio est aussi organisateur du WordCamp Lille.
Orateur compulsif, formateur sénior et ingénieur WordPress, il s’est spécialisé dans la sécurité depuis 2002 et contribue à WordPress sous diverses formes.