iThemes Security < 7.9.1 – Hide Backend ByPass

iThemes Security est une extension bien connue dans la communauté WordPress depuis des années. Il y a 2 semaines, j’ai découvert une faille de sécurité dans leur module “Hide Backend”, divulguant la page de connexion.

Cette vulnérabilité ByPass a été corrigée en 7.9.1, tenez vous à jour si vous l’utilisez.

ITS (iThemes Security) < 7.9.1 souffre d’un bug de lecture de GET/POST/REQUEST pouvant mener à la page wp-login de WordPress. Le but de ce module est donc cassé.

La vulnérabilité n’ouvrira pas de porte sur votre site, pas plus que la fonctionnalité native ne le fait. Donc ce n’est pas un grand danger mais quand on active un module qui nous dit qu’il va protéger le backend, on s’attend à ce que le module… protège le backend.

Timing du Report :

• 05 Avril 21 : Report de la vulnérabilité
• 06 Avril 21 : Vulnérabilité confirmée avec un patch
• 07 Avril 21: Le patch ne fonctionne pas, nouveau patch reçu
• 08 Avril 21 : Patch valide et confirmé.
• 14 Avril 21 : Versions mises à jour
• 20 Avril 21 : Récompense Bounty

Vulnérabilité expliquée

La requête Postman

• La méthode de requête HTTP est POST
• L’URL pointe sur wp-login.php
• Le paramètre dans l’URL est “action=postpass” (donc c’est un param GET)
• Le paramètre dans BODY est “action=login” (donc c’est param POST)

L’extension va lire le GET et laissera passer puisque c’est autorisé (voir ci-dessous), mais WordPress va gérer le param POST et affichera alors le formulaire de connexion.

Code de ITS 7.9.0

Ce sont mes commentaires et je ne montre que les lignes utiles à l’explication.

/* https://plugins.svn.wordpress.org/better-wp-security/tags/7.9.0/core/modules/hide-backend/class-itsec-hide-backend.php */

// Line#24 On ITS init, handle the page request
add_action( 'itsec_initialized', array( $this, 'handle_specific_page_requests' ), 1000 );

// Line#95 Handle the requested path
$this->handle_request_path( $path );

// Line#107-109 Since we are requesting 'wp-login.php' page, we trigger this condition
} elseif ( in_array( $request_path, array( 'wp-login', 'wp-login.php' ) ) ) {
$this->handle_canonical_login_page();
}

// Line#137 If $_GET['action'] is equal to 'postpass', do nothing.
private function handle_canonical_login_page() {
$action = isset( $_GET['action'] ) ? $_GET['action'] : '';

if ( 'postpass' === $action ) {
return;
}

Vous comprenez peut-être mieux maintenant, le action=postpass est le bypass. Voilà pourquoi vous en devez pas utiliser 2 méthodes de lectures des paramètres.

WordPress fait ça :

// /wp-login.php#367
$action = isset( $_REQUEST['action'] ) ? $_REQUEST['action'] : 'login';

Donc si $_REQUEST est lu, vous devez le lire aussi.

Maintenant, rappelons-nous ce qu’est $_REQUEST. C’est un tableau global qui contient à la fois les valeurs de $_GET et $_POST. L’ordre par défaut du mélange est configuré par le serveur et est 90% du temps GP, signifiant “GET + POST”. Mais vous pouvez tomber sur des configurations en PG.

Patchs

Le premier patch remplaçait $_GET['action'] par $_REQUEST['action'] ce qui semble bon à première vue mais pas vraiment si le serveur est configuré en PG, la faille est toujours là, WordPress chargera la page de connexion, encore.

Saviez-vous que WordPress va forcer que configuration en GP ? Maintenant vous savez, c’est fait avec wp_magic_quotes() , cool non ? Mais cela ne va pas aider ITS car le plugin lit les valeurs avant son usage qui est fait avant setup_theme, donc ITS a fait un second patch juste pour changer le hook sur setup_theme.

C’est maintenant patché en 7.9.1, mettez à jour.

Il reste une chose à savoir…

Ce module a été développé pour empêcher les bots et scripts d’entrer ou de brute-forcer la page de connexion de WordPress. Il n’a pas été fait pour qu’un humain ne la trouve pas, donc, en tant qu’humain, vous pouvez trouver un moyen d’obtenir le jeton secret de la page protégée par ITS avec… Google.

Quand vous connaissez le nom de la nouvelle page de connexion, vous êtes redirigé vers la page de connexion avec le nouveau paramètre agissant tel un jeton secret, il s’agit de itsec-hb-token. Puisque ce paramètre est en GET, Google peut l’indexer, voilà pourquoi vous pouvez trouver ces jetons sur les moteurs de recherche.

Disons que je suis un humain (en vrai j’en suis un…) et que je cible example.com. Je vais chercher “site:example.com inurl:itsec-hb-token” et je peux trouver des choses avec le jeton dedans. Cliquez simplement dessus et s’il est encore valide et que ITS est activé, vous obtiendrez le cookie itsec-hb-token. Visitez maintenant la page wp-login.php, vous êtes autorisé.

Ceci ne sera pas corrigé par ITS car cela signifie un redéveloppement complet du module, et comme il a été dit, il a été fait pour bloquer les bots et scripts seulement.

À 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.