Tester les connexions WordPress avec Hydra sur Kali Linux

Introduction

Il existe des formulaires Web partout sur Internet. Même les sites qui ne permettent généralement pas aux utilisateurs réguliers de se connecter ont probablement une zone d’administration. Lors de l’exécution et du déploiement d’un site, il est important de s’assurer que les mots de passe bloquant l’accès aux contrôles sensibles et aux panneaux d’administration sont aussi sécurisés que possible.

Il existe différentes façons d’attaquer une application Web, mais ce guide va couvrir l’utilisation d’Hydra pour effectuer une attaque par force brute sur un formulaire de connexion. La plate-forme cible de choix est WordPress. C’est de loin la plate-forme CMS la plus populaire au monde, et elle est également connue pour être mal gérée.

N’oubliez pas que ce guide est destiné à vous aider à protéger votre WordPress ou tout autre site Web. L’utilisation sur un site que vous ne possédez pas ou que vous n’avez pas l’autorisation écrite de tester est illégale.

Mise en place

Avant de faire quoi que ce soit, vous allez avoir besoin d’un site Web WordPress à cibler. Ce guide suppose également que vous hébergez le site WordPress sur votre propre machine. Si vous avez besoin d’aide pour configurer LAMP sur votre machine, consultez nos guides LAMP Debian et Ubuntu LAMP.

Vous pouvez le faire soit sur une installation Linux normale, soit sur une installation Linux de Kali. Si vous utilisez Kali, suivez le guide Debian LAMP à partir des sources. Assurez-vous simplement qu’Hydra et cURL sont installés sur le système de votre choix. Ils sont disponibles dans la plupart des dépôts.

Si vous ne voulez vraiment pas utiliser votre installation habituelle, vous pouvez certainement utiliser une autre machine, il suffit de sous-inscrire l’adresse IP de la cible pour localhost, et de vous assurer que la machine cible est accessible depuis l’attaquant.

Collecte d’informations

Une fois que WordPress est opérationnel, il est temps de trouver autant d’informations que possible sur l’installation que vous ciblerez. Cela signifie découvrir comment le formulaire de connexion est construit, ce qui se passe lorsque vous le soumettez et éventuellement où il va si la connexion est réussie.

Source HTML

Commencez par accéder à la page de connexion. Vous pouvez le trouver sur localhost/wp-login.php. Utilisez la capacité de votre navigateur à inspecter le code source. Vous pouvez simplement cliquer avec le bouton droit de la souris quelque part sur la page et sélectionner « Afficher la source » ou « Inspecter l’élément ». Dans tous les cas, vous pouvez afficher la source, elle sera simplement affichée de différentes manières.

Cherchez vers le milieu du code. Vous recherchez les balises. Il s’agit du formulaire de connexion proprement dit. À l’intérieur de ce formulaire se trouvent quelques informations dont vous avez besoin.

Avant de collecter les informations, vérifiez si le formulaire envoie une requête GET ou POST. Dans la première ligne du formulaire, il devrait y avoir une option de méthode qui ressemble à ceci : method="post ». Dans le cas de WordPress, il s’agit d’un POST.

Tout d’abord, recherchez l’entrée du nom d’utilisateur. Elle doit ressembler à la ligne ci-dessous.

<input type="text" name="log" id="user_login" class="input" value="" size="20" />

La partie dont vous avez besoin est le nom. Dans ce cas, il s’agit d’un journal.

Ensuite, trouvez la saisie du mot de passe. Cela devrait ressembler.

<input type="password" name="pwd" id="user_pass" class="input" value="" size="20" />

Encore une fois, trouvez le nom qui est pwd.

Vous devez également identifier le bouton d’envoi afin qu’Hydra puisse soumettre le formulaire.

<input type="submit" name="wp-submit" id="wp-submit" class="button button-primary button-large" value="Log In" />

Il est important de consigner à la fois le nom et la valeur.

Il y a un dernier morceau. Si vous ne l’avez pas remarqué, il y a deux champs cachés au bas du formulaire. L’un indique à WordPress de rediriger lorsque le formulaire est soumis et l’autre est un cookie que WordPress recherchera lorsque le formulaire est soumis. Vous avez besoin du cookie.

<input type="hidden" name="testcookie" value="1" />

Encore une fois, notez le nom et la valeur.

friser

Même s’il y avait beaucoup d’informations à obtenir en regardant la source HTML, il y a d’autres choses que vous devez savoir avant de libérer Hydra. Dans la plupart des cas, cependant, vous pouvez être en mesure d’exécuter le test avec uniquement les informations que vous avez recueillies. Il vous suffit d’essayer de vous connecter avec des informations d’identification incorrectes, d’enregistrer le message d’erreur et d’utiliser ce message comme condition d’échec du test dans Hydra.

Cependant, WordPress est conçu différemment, et il n’y a pas vraiment de bon moyen de tester avec des tentatives de connexion infructueuses. Pour cette raison, vous devez tester pour une connexion réussie. Étant donné que vous pouvez maintenir votre propre installation WordPress et vous y connecter, cela ne ferait aucune différence si vous testiez un système pour un client. La condition que vous trouvez localement devrait être universelle à WordPress.

Il y a aussi un autre problème ici. Vous souvenez-vous du champ de redirection caché dans le formulaire ? Eh bien, cette redirection vous empêche d’utiliser une condition telle que la présence du mot « Tableau de bord » pour tester également le succès. Vous allez devoir jeter un coup d’œil à la requête elle-même, et pour cela, il y a cURL.

Pour comparer, vous devez d’abord voir la page de connexion d’origine avec cURL.

curl -v http://localhost/wp-login.php

La majorité des informations sont les mêmes que le code source que vous avez consulté dans le navigateur. En haut, cependant, se trouvent des informations sur la requête HTTP. Prenez note de ces informations. Vous allez devoir le comparer à une connexion réussie.

La prochaine chose que vous devez faire est de vous connecter avec succès avec cURL. Pour ce faire, vous allez avoir besoin du cookie de la demande précédente. Jetez un coup d’œil aux données HTTP et localisez une ligne qui ressemble à celle ci-dessous.

< Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

Vous allez avoir besoin de la partie wordpress_test_cookie=WP+Cookie+check.

Très bien, vous allez maintenant avoir besoin des informations que vous avez recueillies à partir du code HTML avec ce cookie pour effectuer la demande. Voici à quoi cela devrait ressembler.

curl -v --data 'log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1' --cookie 'wordpress_test_cookie=WP+Cookie+check' http://localhost/wp-login.php

Ainsi, vous avez la même requête de base qu’auparavant, mais cette fois, vous utilisez l’indicateur --data et l’indicateur --cookie pour passer cURL les données de formulaire avec lesquelles vous souhaitez interagir et ce cookie, de sorte que le formulaire sera réellement envoyé.

Cette chaîne de données, log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1 correspond directement aux informations que vous avez collectées à partir du HTML. Il s’agit de brancher la valeur « username » dans l’entrée appelée log et la valeur « realpassword » dans l’entrée appelée pwd. Assurez-vous d’utiliser le nom d’utilisateur et le mot de passe réels pour vous connecter. Ensuite, utilisez le submit avec le nom wp-submit et la valeur Log In pour soumettre les données. À la fin se trouve testcookie avec une valeur de 1. Cela revient simplement à dire à cURL de le soumettre avec le reste des données du formulaire.

Lorsque cURL termine la requête, vous ne verrez pas vraiment de HTML, juste beaucoup d’informations sur la requête. Vous vous souvenez de cette redirection qui faisait que les tests avec « Dashboard » ne fonctionnaient pas comme condition de test ? Eh bien, maintenant, la redirection elle-même sera la condition de test. Jetez un coup d’œil à la ligne ci-dessous.

< Location: http://localhost/wp-admin/

Cette ligne ne figurait pas dans la demande précédente. Il ne contient pas non plus d’informations spécifiques relatives à cet utilisateur ou à cette connexion. Cela signifie qu’il sera toujours présent lors d’une connexion WordPress réussie, ce qui en fait la condition de succès parfaite pour tester.

Tester avec Hydra

Enfin, vous avez tout ce dont vous avez besoin pour tester vos mots de passe avec Hydra. Le but de ce guide n’est pas tant de couvrir la syntaxe d’Hydra, mais il va décomposer la commande utilisée. Si vous souhaitez en savoir plus sur Hydra, consultez le guide SSH qui entre beaucoup plus en détail.

Il n’y a vraiment qu’une seule commande dont vous avez besoin pour qu’Hydra exécute les noms d’utilisateur et les mots de passe possibles afin de tester la sécurité de votre site WordPress. La chose la plus simple à faire est de jeter un coup d’œil à la commande et de la décomposer.

hydra -L lists/usrname.txt -P lists/pass.txt localhost -V http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'

D’accord, c’est évidemment beaucoup à assimiler à la fois. L’indicateur -L indique à Hydra d’utiliser une liste de mots de noms d’utilisateur à lists/usrname.txt. De même, l’indicateur -P indique à Hydra d’utiliser une liste de mots de passe à l’adresse lists/pass.txt. localhost dit à Hydra de cibler localhost, et -V lui dit de consigner chaque test dans la sortie de la console.

Le reste de la commande traite la requête HTTP elle-même. http-form-post active le module Hydra pour la gestion des formulaires HTTP avec une méthode POST. N’oubliez pas que le formulaire de connexion WordPress est en face d’un POST de. La chaîne qui suit contient tous les paramètres qu’Hydra utilisera. Vous devriez remarquer qu’il est très similaire à celui utilisé pour se connecter via cURL.

La chaîne se compose de différentes sections séparées par :. La première partie est l’adresse exacte testée, /wp-login.php. La partie suivante est presque exactement comme celle utilisée par cURL. Il transmet des valeurs dans le formulaire et l’envoie, y compris le cookie. Au lieu de passer des valeurs littérales, Hydra utilise en fait des variables. Avis dans log=^USER^ et pwd=^PASS^. Il s’agit de variables séparées par le caractère carotte qui prennent les valeurs des listes de mots et les transmettent dans la demande de chaque test exécuté par Hydra.

Le tout dernier morceau de la corde est la condition de test. S signifie qu’il s’agit d’un test de succès. Si vous vouliez tester l’échec, vous utiliseriez F. Vous définissez cela comme égal au mot ou à la phrase qu’il teste. Pensez-y si c’est presque comme grep.

Lorsque vous exécutez cette opération, vous devriez obtenir un résultat positif, à condition que le nom d’utilisateur et le mot de passe corrects figurent dans les listes de mots que vous avez fournies à Hydra.

Réflexions finales

Tout d’abord, félicitations pour avoir survécu à tout cela. Si vous avez réussi, vous disposez maintenant d’une méthode solide pour tester la force du mot de passe de vos comptes d’utilisateurs WordPress.

Ce guide a été conçu pour WordPress, mais vous pouvez facilement suivre les mêmes étapes pour tester d’autres formulaires Web. Si vous exécutez une application web avec plusieurs utilisateurs, c’est certainement une bonne idée de vous assurer < > qu’ils utilisent des mots de passe forts. Cela peut vous aider à élaborer votre politique en matière de mots de passe. Encore une fois, assurez-vous que vous ne testez toujours qu’avec autorisation.