DVWA – Task 1: Brute force using Hydra & Developer tools with Bonus task unlocked!

Disclaimer: This tool should not be used to attack websites or services where you do not have permission to do so. Use this for legitimate testing purposes only and Reminder to read README on github

#DVWA #Kali VM server #Hydra #Developer tools #Security:Low

Task details: 

  1. Objective: What are we trying to do
  2. Tools: What tools do we need
  3. Intel: What information do we need

Objective: Trying to login to a website form as an existing user by guessing the username and password fields. For this we’ll need an online password iteration tool, using a technique known as Brute forcing. 

Brute Forcing: is the process of iterating different values against an entry point, similar to when you forget your username/password and guess a few times until you are successful. Brute forcing essentially does this on a bigger scale and much faster. Time taken, if successful is dependant on factors like password length, complexity, number of fields i.e. password or both username and password, number of entries in the wordlist being used and processing power are the main considerations

Bonus objective: Most people find only 1 username but did you know there’s actually more! 

Challenge URL: /dvwa/vulnerabilities/brute/

Tools needed (main): DVWA server on a VM and Hydra – Hydra is a parallelized login guesser, which supports numerous protocols to attack. It is very fast and flexible, and new modules are easy to add and Developer tools to pull out info. It is basically a tool to guess valid login/password pairs. 

Alternatives to Hydra: We could also use Potator and Owasp Zap, Burp suite. Using Burp has the benefit of being able to extract information that you would otherwise need from Web browser – Developer tools. 

Disclaimer Repeat: This tool should not be used to attack websites or services where you do not have permission to do so. Use this for legitimate testing purposes only

Step 1: setup infrastructure

  • Start your DVWA web server: sudo service mysql start and then sudo service apache2 start
  • Hydra – will come already installed in Kali but if you need to install then I’ll leave the command in the links section. Note: there was a reported bug in version 9.1 and the current version as of now is 9.2. Check version hydra –version
  • Update your repositories
  • Launch browser and point to your self hosted DVWA website localhost/dvwa
  • Login to the actual DVWA domain – note whilst it is possible to brute force the main login page, the actual task is to brute force the path /dvwa/vulnerabilities/brute i.e. not /dvwa/login.php as I’ve seen people stuck in forums because they’re using a mixing parameters and flags from these 2 different paths which then leads to it not working or causing errors

Step 2: Pre-requisites

  • For web-based forms, you have to know certain information before you can start the iteration process – think of this as specifying and narrowing down a target location. Every web-based form is slightly different, different URLs and parameters, and different responses for success or failure

Step 3: What we need to feed/pass into into Hydra (overview)

  • Hostname/IP: this is effectively the DVWA web server folder name
  • URL Service/Method/Scheme: Protocol to access the resource i.e. Whether it is a HTTPS or HTTP service/protocol and; 
  • Form type: GET or POST (or both)
  • Parameters of the request within double quotes;
  • Path: The relative path to the target location
  • Iteration fields: direct Hydra where to iterate field(s) and with what data
  • Flag: establish the difference in response between Success and Failure and which flag to be used
  • Session cookies: Whether any session cookies are required to be set or maintained
  • Lockout features: What lockout features and thresholds apply to the form
  • Wordlists: To allow iteration of respective fields i.e. username and or password field
  • Port number: Port number used should be automatically established by Hydra when the Method/Scheme section is defined. Port number should only need to be set if using a different port to the officially known port numbers or there is error. We will not be defining port number but it will be port 80 which will be visible when the Hydra executes.  This would change to port 443 if we installed an SSL certificate on our web server.

Step 4: Build command for Hydra (detailed)

  • Parameter information extraction: There are multiple ways to extract the required parameter information but we’ll use the Web browser Developer tools to examine the client-side source code. In Firefox the shortcut is Ctrl + Shift + I and keep the menu open and navigate as follows
  • Click on the Network tab in Dev Tools and then click on the Brute Force menu on the DVWA website. Notice you should see some data flow – click on the top entry which should resemble this;
  • This data tells us that the Status of request (clicking Brute Force) was 200 which is a Successful OK message, hence the web page loaded. The Method is now confirmed as a GET request (used to request data from the resource and POST is used to send data to a server to create/update a resource). Domain confirms the domain name of the website as localhost. Note this may state the IP address if you entered that instead which would be 127.0.0.1 and File shows the relative path to the location

Command section 1:

  • Call Application: Hydra
  • Hostname/IP: localhost (or 127.0.0.1)
  • URL Service/Method/Scheme & Form type: http-form-get
  • Parameters: Open parameters to enter arguments “ “
  • Path – which is closed using a colon: /dvwa/vulnerabilities/brute: 

For the next part of the command, we need to select the relevant elements from the web page to understand the naming conventions i.e. name value field. Open the browser inspector using the shortcut Ctrl + Shift + C. The first element we need is the username so click the section in the web page and the respective element will be highlighted in Developer tools. We do the same for the password element and login button. We should see these values as follows, paying attention to the name= values;

Command section 2:

  • Iteration fields: we can now use the name values and instruct Hydra to iterate the name of the fields and then using Hydra syntax, direct payload points. We separate the fields using an & symbol. We want to automate the processing of effectively clicking the “Login” button for each login attempt/iteration, so we use the name and input type value instead: username=^USER^&password=^PASS^&Login=submit:
  • We can now close this section using a colon

Command section 3:

  • Flag: we can find out the message output if we enter incorrect credentials which is the Failure flag. You may know the message for a Successful login if you have an account in the same domain and able to confirm the output. If we enter arbitrary details, we get the following login failure message below. So we can input; F=Username and/or password incorrect.
  • The logic with the Flag parameter is that the Success message is the string value we are explicitly looking for i.e. like the Allow/Whitelisting policy of a firewall. The Failure message is the string value we want to drop, which should then return an anomaly which in theory would be a Success message type instead i.e. “Login successful”. To put it another way, the Success Flag is to look for a string vs the Failure Flag which is looking for the absence of a field. 
  • Tip: Remember that the “failure” or “success” string does not have to be part of the HTML of the page. These strings could be information in the response headers, such as cookies set, or locations of redirects. There are flexible options for dealing with responses as long as there are definitive differences between success and failure messages/outputs.
  • Tip: To paste into Terminal, use Ctrl + Shift + V

Command section 4:

We need to think/act like a computer for a moment, so logout of the DVWA website so you are back on the login page. We have given Hydra the path of /dvwa/vulnerabilities/brute however when you enter this URL, you will be redirected to the login page URL path /dvwa/login.php at least in this particular setup. This would incorrectly instruct Hydra to iterate the /login/php path and therefore run the iteration unauthenticated. The Failure message for that page doesn’t match our intended target, thus Hydra is unable to establish what a valid credential set is using the Failure message given via reverse logic. If you use the rockyou.txt wordlist in Kali, you may end up with 16 ‘valid’ login pairs.

We need to login and provide Hydra the Session cookies so that it can pass/redirect from dvwa/login.php to our desired path of /dvwa/vulnerabilities/brute. If you do not do this, then Hydra will use all the values given and try to iterate on the incorrect path as explained above. 

So, log back into DVWA where you should be on the path /dvwa.index.php. We need to change the security level to low, so we click on DVWA Security in the website menu, select Low and submit.  Now within Developer tools, Network tab, click on the top entry and in the adjacent menu, click on the Headers tab, scroll down to Request headers and change format to Raw using toggle button. Now we can copy the Cookie value in full. We have effectively allowed Hydra to use a valid session, so that it can “see” the actual/intended target location/path.

Note: if you ended up with excessive login successes, then it is likely that you have not added the cookie at all, a valid session cookie, entered it partially or using an incorrect syntax.

  • Session cookies: H=security=low; PHPSESSID=57i460r9ukoqkg7u99klqp1a01”
  • We can now close the parameter after the PHP Session ID as shown above
  • Lockout features: There did not appear to be any lockout features. If there were, we could use a time/delay the iteration attempts using the timer switch: t=1 this example would delay the iteration attempts by 1 second
  • Wordlists: We can create a wordlist or download a lost and provide the path to it. For the sake of time, we will create a short wordlist (the longer the list, the longer the iteration will take). For now, we just need to provide Hydra the name (and path of wordlist was located in a different directory). If we already knew one of the values i.e. that username was admin, then we can simply pass this to Hydra which saves the time to iterate that field. When we know the value of a username field we use the -L switch. When we don’t and wish to use a wordlist, we use smaller case -l. The same logic applies to the password field, we just use -P or -p instead
  • To manually create a quick wordlist, simply open a default terminal session and enter the name of the editor and name you want to call the file followed by format: nano username.txt
  • To enter values/words in the file, we simply add some arbitrary words and then press Ctrl + O to save, Enter to confirm and Ctrl + X to exit out of the nano editor. Create a another wordlist for the password list. Note that we must ensure we include the actual username of admin in the username.txt list and the actual password of password in the password.txt list – otherwise the iteration cannot be successful. Of course this is not e real life scenario, we are understanding how the application works from an educational perspective. We can also automate the creation of a list using Crunch which is a password creation tool. You can also use a ready installed wordlist like rockyou. Kali stores wordlists in the following path; /usr/share/wordlists
  • TIP: to find a file in Kali Linux you can use the locate [filename] command and this will give you the full pathlocate
  • Port number: Port number used should be automatically established by Hydra when the Method/Scheme section is defined. Port number should only need to be set if using a different port to the officially known port numbers or there is error. We will not need to define a port number but it will be port 80 which will be visible when the Hydra executes.  This would change to port 443 if we had installed an SSL certificate on our web server.

Command complete 5:

We have now constructed our command which is ready to be executed in Hydra. You should have the following command ready;

hydra localhost http-form-get "/dvwa/vulnerabilities/brute:username=^USER^&password=^PASS^&Login=submit:F=Username and/or password incorrect.:H=Cookie:security=low; PHPSESSID=vrdt2vuaq0jtakrgj5grg0fqnb" -L username.txt -P password.txt

We can now hit enter to execute the command. Here is the output;

Zoomed in;

Hydra has successfully iterated the values within the wordlists we provided on the right page and in the right fields! It has used the Failure flag to identify the responses header which did not contain the F value we added within the command, essentially reverse logic. 

Now we can confirm our result by trying to login using the credentials provided by Hydra and sure enough, we have now successfully logged into an admin area;

  • TIP: for future attempts, we can use the Success flag as we can now see the response would be “Welcome to the password protected area admin”
  • We can also re-run the command in Verbose mode by inputting the -V switch or -Vv for extra verbose! This allows you to see in real time the iteration attempts
  • If you wanted to save the result in a file you can simply add Output file switch  as follows; -o [filename.format]
  • Bonus objective: as ethical hackers, we need to be highly curious and be interested to explore. See if you can find additional hidden information on this page. It may help to explore using the Developer tools – Inspector we used before using shortcut Ctrl + Shift + C 
  • To preserve the challenge I will post the bonus objective walk through in my video which you can access using the link below. This shows how I stumbled across it which you may find interesting – Good luck!


Hydra tool – https://www.kali.org/tools/hydra/

Terminal install command: sudo apt install hydra

Crunch password generating tool – guide coming soon!