DVWA Brute Force Attack - Medium Severity
This detailed post explains Brute-Force Attacks' Medium severity using DVWA and how partial security fixes can be bypassed. You can also explore a demo to better understand the concept and discover and optimize your attack with the BurpSuite tool.
I hope you are familiar with brute-force attacks by now.
In the current section, we will explore a bit more about the Brute Force attack and options available in the BurpSuite tool for effectively identifying successful brute-force attempts.
If you haven't read the previous article about the Brute Force attack, feel free to refer to the bookmark below.
DVWA Brute Force Vulnerability - Demo
Imagine we found a vulnerability and reported it to the DVWA development team. The team reverted, claiming the security flaw was fixed.
Trust but Verify
It is always a good practice to re-verify and ensure that the vulnerability is mitigated as per best practices. Let's verify.
Log into the DVWA application. In the sidebar, scroll to the bottom of the page and click on "DVWA Security". A page will load as shown below.
Set the security level to "Medium" and click on the Submit button. Ensure it is updated and displayed on the left side at the bottom of the page.
Launch the BurpSuite tool, navigate to the "Proxy" tab, and click on the "Open Browser" button.
Visit the DVWA application, Select the "Brute Force" vulnerability, and then enter any random credentials as discussed in the previous article.
Enable the intercept option and capture the login request displayed, as shown below. Observe that the security parameter value is set to medium in line 16.
Similar to the previous lesson, click on "Action" and select "Send to Intruder". Set the attack type to "Cluster bomb", clear all fields, and add only the username and password value fields for inserting custom payloads.
For the current scenario, we will use the same Word list of common usernames and passwords. Save the text files onto your system or use copy-paste to load the information in the payloads tab.
usernames.txt
passwords.txt
In the "Payloads" sub-tab, select "Payload Set 1", payload type as "simple list", and paste all the contents in payload options copied from the usernames.txt list. (For username values)
Second, select the "Payloads" sub-tab, set "Payload Set 2", and payload type as "simple list", and paste all the contents in payload options copied from the passwords.txt list. (For password field values)
The steps were similar to the previous one.
If you remember, in the previous Intruder attack summary, we needed to go through each request, select the response message, and look out for the message "Username and/or password incorrect".
We earlier used the "Length" size option to drill down and focus on the one with a different size.
The Intruder tool provides us with a better way to do it, called "Grep - Match", which helps us to find a specific string in the HTTP response body using grep and flags it. A more suitable way to view the results.
In the "Intruder" tab, click on the "Options" sub-tab and scroll down to "Grep - Match", then click on the "Clear" button.
If prompts for confirmation, click on "Yes" to clear.
In "Grep-Match", type "incorrect" in a text area and click on the "Add" button. This word is taken from the invalid user credentials error message "Username and/or password incorrect".
Make sure "Flag result items with responses matching these expressions." is enabled and confirm "incorrect" string is added.
Match type "Simple string" suffixed our current requirement.
Finally, click on the "Start attack" button and let us verify whether the brute-force vulnerability is fixed or not.
A new window pops up, and all the Intruder attack summaries will be displayed. Now, an additional row named "incorrect" is added.
You can see that our grep match pattern is working, as we are able to view the match count in the "incorrect" row updated for each request.
If you closely observe, there is one problem. It is slow compared to the previous brute-force attack.
It seems the DVWA development team added a small delay, but it's still not stopping us from performing a Brute Force attack.
It took more time than before, but we found a valid password match again using the brute-force attack.
The one where the "incorrect" count is empty. i.e., admin/password. As displayed in the above screenshot.
Scroll down to check for the response body and observe a message. "Welcome to the password protected area of admin".
Yay!! The vulnerability still remains open. Let's report it back to the DVWA dev team. 😄
DVWA Informational (Optional)
We are testing this in a DVWA, an intentionally vulnerable environment. The application also allows us to view the backend code for knowledge purposes.
Remember you might not have this option in real-world applications.
Navigate to the "Brute Force" menu item in the sidebar. On the same page click on the "View Source" button at the bottom of the page.
A pop-up window will be loaded, and the code will be displayed.
Observe that the application delays 2 seconds before sending the response message back to the client for all failed logins.
In general, the vulnerability can be mitigated in many ways, but industry best practices should be adhered to.
The next section will cover the Brute Force vulnerability of DVWA's high-security level and then look at mitigation techniques.