GNU/Linux >> Tutoriels Linux >  >> Linux

Testez les connexions WordPress avec Hydra sur Kali Linux

Présentation

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 donnant 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 couvrira 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.

Rappelez-vous, ce guide est destiné à vous aider à protéger votre WordPress ou un autre site Web. L'utilisation sur un site qui ne vous appartient pas ou dont vous n'avez pas l'autorisation écrite de tester est illégale .

Préparation

Avant de faire quoi que ce soit, vous aurez 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 Debian LAMP et Ubuntu LAMP.

Vous pouvez le faire soit sur une installation Linux normale, soit sur une installation Kali Linux. Si vous utilisez Kali, suivez le guide Debian LAMP à partir des sources. Assurez-vous simplement que Hydra et cURL sont installés sur le système que vous choisissez. Ils sont disponibles dans la plupart des référentiels.

Si vous ne voulez vraiment pas utiliser votre installation habituelle, vous pouvez certainement utiliser une autre machine, juste sous l'adresse IP de la cible pour localhost, et assurez-vous que la machine cible est accessible depuis celle qui attaque.

Collecte d'informations

Une fois que vous avez WordPress 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 réussit.

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 pour inspecter le code source. Vous pouvez simplement faire un clic droit 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. C'est le formulaire de connexion réel. À 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. Cela devrait 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 name . Dans ce cas, c'est log .

Ensuite, recherchez l'entrée 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 name qui est pwd .

Vous devez également identifier le bouton de soumission pour 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 name et la value .

Il reste 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 sera soumis. Vous avez besoin du cookie.

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

Encore une fois, notez le name et value .

cURL

Même s'il y avait beaucoup d'informations à acquérir 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 pourrez peut-être exécuter le test avec uniquement les informations que vous avez recueillies. Vous tenteriez simplement de vous connecter avec des informations d'identification incorrectes, d'enregistrer le message d'erreur et d'utiliser ce message comme condition de test d'échec dans Hydra.

Cependant, WordPress est conçu différemment, et il n'y a pas vraiment de bon moyen de tester les tentatives de connexion infructueuses. Pour cette raison, vous devez tester une connexion réussie. Parce que vous pouvez maintenir votre propre installation WordPress et vous 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 pour WordPress.

Il y a une autre ride ici aussi. Vous souvenez-vous du champ de redirection masqué 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 œil à la requête elle-même, et pour cela, il y a cURL.

Afin de 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 identiques au 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 aurez besoin de ce cookie de la requête précédente. Examinez les données HTTP et localisez une ligne qui ressemble à celle ci-dessous.

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

Vous aurez besoin du wordpress_test_cookie=WP+Cookie+check partie.

Très bien, vous allez maintenant avoir besoin des informations que vous avez recueillies à partir du code HTML avec ce cookie pour faire 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

Donc, vous avez la même requête de base qu'avant, mais cette fois, vous utilisez le --data flag et le --cookie flag pour transmettre à cURL les données de formulaire avec lesquelles vous souhaitez interagir et ce cookie, afin que le formulaire soit réellement soumis.

Cette chaîne de données, log=username&pwd=realpassword&wp-submit=Log+In&testcookie=1 correspond directement aux informations que vous avez recueillies à partir du HTML. Il dit de brancher la valeur "nom d'utilisateur" 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 la soumission avec le nom wp-submit et une valeur de Log In pour soumettre les données. À la fin se trouve testcookie avec une valeur de 1 . Cela dit simplement à cURL de soumettre cela avec le reste des données du formulaire.

Lorsque cURL termine la demande, vous ne verrez vraiment aucun HTML, juste beaucoup d'informations sur la demande. Vous souvenez-vous de cette redirection qui a fait que les tests avec « Tableau de bord » ne fonctionnent pas comme condition de test ? Eh bien, maintenant, la redirection elle-même sera la condition de test. Jetez un œil à la ligne ci-dessous.

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

Cette ligne ne figurait pas dans la requête 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 être présent lors d'une connexion WordPress réussie, ce qui en fait la condition de réussite idéale pour tester.

Test 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 Hydra, mais il décomposera la commande utilisée. Si vous voulez en savoir plus sur Hydra, consultez le guide SSH qui va beaucoup plus en détail.

Il n'y a vraiment qu'une seule commande dont vous avez besoin pour qu'Hydra parcoure les noms d'utilisateur et les mots de passe possibles pour tester la sécurité de votre site WordPress. La chose la plus simple à faire est de jeter un œ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, donc c'est évidemment beaucoup à prendre en même temps. Le -L flag indique à Hydra d'utiliser une liste de mots de noms d'utilisateur à lists/usrname.txt . De même, le -P flag indique à Hydra d'utiliser une liste de mots de passe dans lists/pass.txt . localhost indique à Hydra de cibler localhost et -V lui dit de consigner chaque test dans la sortie de la console.

Le reste de la commande traite de 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. Rappelez-vous d'avant 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 qui est 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 le soumet, y compris le cookie. Au lieu de transmettre des valeurs littérales, Hydra utilise en fait des variables. Avis dans log=^USER^ et pwd=^PASS^ . Ce sont des variables séparées par le caractère carotte qui prennent les valeurs des listes de mots et les transmettent dans la requête pour chaque test exécuté par Hydra.

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

Lorsque vous exécutez ceci, 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 traversé 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é adapté à 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 s'assurer qu'ils utilisent des mots de passe forts. Cela peut aider à informer votre politique de mot de passe. Encore une fois, assurez-vous de toujours tester uniquement avec autorisation.


Linux
  1. Utilisez Aircrack-ng pour tester votre mot de passe WiFi sur Kali Linux

  2. Comment mettre à jour Kali Linux avec une seule commande

  3. Installer WordPress sur Linux avec Apache

  4. Version Kali Linux 2022.3 (discorde et laboratoire de test)

  5. Version Kali Linux 1.0.8 avec prise en charge du démarrage EFI

Guide d'examen et d'installation de Kali Linux avec captures d'écran

Tutoriel de commande de test Linux pour les débutants (avec exemples)

Commande Linux make expliquée avec des exemples

Installez WordPress 4.0 avec Nginx 1.6 sur Linux Mint 17

Faire semblant d'utiliser Windows avec le mode d'infiltration de Kali Linux

Connectez-vous avec une clé privée SSH sous Linux et macOS