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
[pastacode lang=”php” manual=”if%20(%20isset(%20%24request%5B’query’%5D%20)%20%26%26%20strpos(%20%24request%5B’query’%5D%2C%20’action%3Dconfirmaction’%20)%20!%3D%3D%20false%20)%20%7B%0A%0A%C2%A0%20%C2%A0%20%40require_once%20ABSPATH%20.%20’wp-login.php’%3B%0A%0A%7D” message=”” highlight=”” provider=”manual”/]
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
[pastacode lang=”php” manual=”if%20(%20is_admin()%20%26%26%20!%20is_user_logged_in()%20%26%26%20!%20defined(%20’DOING_AJAX’%20)%20%26%26%20%24pagenow%20!%3D%3D%20’admin-post.php’%20%26%26%20(%20isset(%20%24_GET%20)%20%26%26%20empty(%20%24_GET%5B’adminhash’%5D%20)%20%26%26%20%24request%5B’path’%5D%20!%3D%3D%20’%2Fwp-admin%2Foptions.php’%20)%20)%20%7B%0A%0Awp_safe_redirect(%20%24this-%3Enew_redirect_url()%20)%3B%0A%0Adie()%3B%0A%0A%7D” message=”” highlight=”” provider=”manual”/]
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
[pastacode lang=”php” manual=”if%20(%20!%20empty(%20%24_GET%20)%20%26%26%20isset(%20%24_GET%5B’action’%5D%20)%20%26%26%20’rp’%20%3D%3D%3D%20%24_GET%5B’action’%5D%20%26%26%20isset(%20%24_GET%5B’key’%5D%20)%20%26%26%20isset(%20%24_GET%5B’login’%5D%20)%20)%20%7B%0A%0Awp_redirect(%20%24this-%3Enew_login_url()%20)%3B%0A%0Aexit()%3B%0A%0A%7D” message=”” highlight=”” provider=”manual”/]
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 :
[pastacode lang=”php” manual=”if%20(%20!%20array_key_exists(%20’post_password’%2C%20%24_POST%20)%20)%20%7B%0A%0Awp_safe_redirect(%20wp_get_referer()%20)%3B%0A%0Aexit()%3B%0A%0A%7D” message=”” highlight=”” provider=”manual”/]
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
