What is DVWA?

Damn Vulnerable web app or Damn Vulnerable Web Application (DVWA) is an intentionally designed vulnerable application for pen-testers and security experts in learning and testing web application security in a legal environment. It is developed using PHP/MySQL and can be deployed easily using an Apache server.

DVWA Git Repository

DVWA can be installed in multiple ways, such as using code from GitHub, Vagrant, or a Docker image, etc.

It is recommended to host the vulnerable applications in a host-only environment to prevent compromising other systems on your network by attackers.

You can even view the source code or contribute to the DVWA project. It’s an open-source project.

For simplicity, we will be using our systems and pre-built docker DVWA image, which is publicly available, rather than setting up the whole stuff by ourselves. By running the DVWA docker container, we can save a lot of time and jump-start learning application security and penetration testing directly.

Requirements

1. Docker installed & enabled on your Laptop/Desktop
2. Any Operating System (OS) Linux/Windows/Mac

I am a GNU/Linux user, so most of the commands you will see from here on will be based on Linux (Debian), and similar commands do apply to other Linux flavors like Ubuntu and Mac with minor tweaks.

For Windows users, you can use either PowerShell or git Bash, where similar commands can be executed, or even the Windows Subsystem for Linux can also be used.

Verify Docker Setup

docker --version

Output:

Docker version 20.10.17, build 100c701

If the output is similar to the above, it means the docker is installed on your system and good to start.

For users whose docker is not installed, please visit the Get Docker page for installation.

Manage Docker as Non-Root Users (Linux-based OS Users)

For users who are using docker on Linux-based operating systems, we need to take one more additional step to ensure we can manage the docker image as non-root users.

After installation of docker, create a docker group and add the newly created user to the docker group.

$ sudo groupadd docker

$ sudo usermod -aG docker $USER

Now log out of the user account and log back in again to verify you are now able to manage the docker instances from non-root users.

$ docker run hello-world

Output:

The above output confirms that we can manage Docker with non-root user privileges. More details can be found on the post-installation docker page below.

Benefits of Local DVWA Environment

• Practice any time.
• Ability to test any customized payloads or exploits.
• It can be used to test the effectiveness of Web Vulnerability Scanners or Automated Tools
• It can be used for Teaching.
• Ability to test custom security fixes.

Running DVWA docker

I hope your Docker environment is configured so we can start working. Here, we will use the Docker image, which has already been built and hosted in the Docker Hub.

Damn Vulnerable Web Application Docker Image: https://hub.docker.com/r/vulnerables/web-dvwa/

Command:

docker run --rm -it -p 80:80 vulnerables/web-dvwa

The above command will download the docker image for the first time and will start immediately on port 80 after downloading it. Click here to verify.

If you are using port “80” for some other service in your operating system, you can change the docker container port to some random one (say 8443). Update the -p value with -p 80:8443. Ensure the updated port is used in the URL while accessing the DVWA web application.

To manually view, open a browser and visit “http://localhost/”, you should be able to see the output as shown below:

The image will start displaying the console logs of the operations being performed on the DVWA website for reference.

Stop the running Docker image anytime by typing Ctrl - c in your console.

DVWA Admin Password

Now log into the application using Username admin, Password as password, Navigate to Setup DVWA ⇾ click on Create/Reset Database button.

We can observe that the database has been created with a users’ table. Some sample data is also inserted into the tables for our testing purposes.

Damn Vulnerable Web App Walkthrough:

Log into the DVWA application and observe most of OWASP’s top-known vulnerabilities that have been created so you can get started. They are displayed as shown below.

Our practice lab environment is up and is good to go.

From the above screenshot, you can use the DVWA to practice and get hands-on experience with known vulnerabilities, such as Brute Force, Command Injection, CSRF, XSS, etc.

Click on any vulnerability in the left-side menu, and the application will load the vulnerable page. All pages simulate close-to real-time application behaviors and provide hints to help you narrow down and use the correct type of vulnerable payloads for exploitation.

Remember that all our changes will be lost once you stop the DVWA docker image. You might need to repeat the above steps when you start. This is how the docker is designed, and it also allows us to begin with a fresh environment without worrying about previous changes.

The docker image needs some more tweaks, but we will do them when needed based on the type of attack we are discussing.

DVWA Security Levels

In the DVWA application, there are multiple levels to test any specific vulnerability, ranging from Low to Medium to High and Impossible.

These levels help you build skills by understanding each scenario. First, you learn about the attack itself. Then, you will know how broken fixes are implemented and how they can be bypassed. Lastly, you will learn the best way to secure a particular functionality.

The DVWA security levels are different for older versions. In the old version, high is a good practice for fixing code.

It is recommended that you go step by step. I still use it today to test specific payloads before they are applied to real-time applications as part of security testing.

DVWA View Source and View Help

The DVWA application is mainly designed as a learning platform for application security. It also allows us to view the backend code for knowledge purposes.

Remember, you might not have this option for real-world applications. This is just for educational purposes only.

Navigate to any vulnerability in the menu. Say the “Brute Force” menu item in the sidebar. On the same page, click on the “View Source” button at the bottom.

Similarly, the “View Help” button or “More Information” section can be used if you struck somewhere as initial help.

I hope the above information helps you to get started with a damn vulnerable web app docker.

If you want to learn about some basic web foundations before jumping into web security vulnerabilities, refer to the bookmarks below.

Security Foundations: What is Web Application and How does it work? Discover the fundamentals of what is a web application, URLs, and popular web application architectures. Gain insights into the core concepts that drive the digital world forward. Begin your journey by establishing strong security foundations.

Security Foundations: HTTP Basics Tutorial Uncover the fundamentals of HTTP in this beginner-friendly way. HTTP Basics Tutorials is a guide for those new to information security or diving into web application security.

FAQ’s

How to log into a damn vulnerable web app login?

You can use the credentials like username as admin and password as password.

The following post is part of learning application security with the DVWA application.

Before jumpstart, ensure the docker DVWA application is enabled, configured, and accessible.

What is a Brute Force Attack?

A brute force attack is a trial-and-error method in which every possible combination of commonly used words, usernames, and passwords is tried out, hoping any of them will work.

Brute Force attacks are aimed at guessing commonly known files on the web server, breaking into email accounts, guessing remote services SQL or SSH server credentials (online), cracking password hashes (offline), etc., to gain unauthorized access to sensitive data or compromise security.

It would require a good amount of computing resources and time. #️⃣

The screenshot below from Cloudflare demonstrates how long it can take to crack a password based on the number of characters.

Today’s hardware helps us crack a hashed password of 5 characters or fewer in seconds. The one with 12 characters or more, combining small letters, upper-case letters, special characters, and numerics, takes years to crack. The bigger the password, the more time it takes to crack using a Brute Force attack.

Think wisely, how much time you would like to spend for any brute force attack. A day or two may be good, but years and decades may not be worth enough.

Speaking on behalf of security assessments, we will be spending days or weeks. But attackers do have all the time they want.

How do Brute Force attacks work?

Brute Force attacks are performed using automated tools or software. A massive list of dictionaries containing common passwords, usernames, words, etc., is generated and given to the tool as input.

The tool keeps interacting with the service and tries out the dictionary entries one by one until a valid match is found, at which point it stops.

During this process, the attacker uses large dictionary data sets until the correct combination is discovered and successful access to confidential resources is obtained.

From now on, we will use the “Burp Suite” as an ideal tool for all our brute force attacks and to keep demos focused. If you would like to learn more about the basics and usage of the tool, Check out the following post on BurpSuite Overview.

Next, I will be using a small custom dictionary of usernames and passwords for fast brute-force results, which will be performed later.

admin
administrator
user
john
dvwa
bob
alice
root
superuser
super

admin
admin123
password
password123
user
user123
administrator
passw0rd
r3m3mb3rM3
admin123$

Brute Force Attack - Demo

The DVWA application has a Login page functionality that can be used to brute-force and find the right match of user credentials, simulating the attackers to compromise the application.

Let’s go ahead and simulate the steps of an attacker and see if we can break in.

In information security, it’s all about chaining up every piece of information you know, experimenting with it, and confirming if it works. In short, it lies in your creativity when using the information.

At the moment, we do not have any information about the username/password. All we see is a login page.

We will start with the Brute Force attack using the above dictionaries.

Let’s start the BurpSuite tool and use the small custom dictionaries we created above. The tool tests for all possible combinations, and this method is scalable to thousands of combinations.

In the Burp Suite tool, navigate to the “Proxy” tab and click on the “Open Browser” button. A Chromium browser will be launched and will be displayed as shown below.

Log into the DVWA application using “admin/password” and navigate to the “Brute Force” item in the menu.

Let’s try some known username and password combinations.

Say “administrator/admin123”, “admin/admin123”, “user/user123” etc. For all incorrect attempts, we keep getting the “Username and/or password incorrect.” message.

Manually trying out is also known as a simple brute force attack, which is painful and limits the knowledge to oneself. This approach is time-consuming and isn’t scalable.

If you found a valid login match this approach? Excellent. You perfectly guessed it. 👍

In Burp Suite, we need to capture the Login request. I will enable the Intercept option to capture a specific login request so we can perform automated operations using it.

To enable it, navigate to Burp Suite “Proxy” tab ⇾ “Intercept” ⇾ toggle on the “intercept off” button. It immediately turns to “intercept on” as displayed below.

Key in some random data in the username and password file, then click on the “Login” button as shown below.

Once the Burp Suite receives an intercept request, you should be able to see the highlights immediately. Navigate to the “Proxy” tab. ⇾ “Intercept”. You should be able to see a request similar to the one below.

An HTTP GET method is used, remember the GET method doesn’t have a message body. Therefore, all the parameters and values will be sent as a URL.

GET /vulnerabilities/brute/?username=admin&password=testpassword&Login=Login HTTP/1.1

Here, we are trying to access a page called “/vulnerabilities/brute” and passing parameter values “username=admin&password=testpassword&Login=Login” to perform the login action required by the application.

If your credentials are valid, you will be able to log in successfully. Otherwise, you will receive an invalid login error message.

Now, click on the “Action” button and select “Send to Intruder”.

Switch to the “Intruder” tab, and you should be able to see the same request there. Under the “Positions” sub-tab, The tool automatically detects where all the changeable values need to be placed and highlights the five parameter values section for us.

I will clear all the payload locations and select only username and password using the “Clear” and “Add” buttons beside.

Types of Brute Force Attacks

There are four brute-force attack types that are supported by the “Burp Suite” tool.

Cluster Bomb best suits our requirements. Set the attack type to “Cluster Bomb” and switch to the “Payload” sub-tab.

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.

This is for the “Username” values.

Second, select the “Payloads” sub-tab, set “Payload Set 2”, set the payload type as “simple list” and paste all the contents in payload options copied from the passwords.txt list.

This is for the “Password” values.

Observe that the request count is now set to 100. Using the two lists now, we will be trying out 100 possible combinations.

Lastly, click the “brute-force” button at the top right to initiate our brute-force attack.

In the BurpSuite Community edition it prompts with a warning box as some features are limited. Click “Ok” to continue.

An intruder window pops up, and the payload information and request status will be displayed below.

If you take a look, we can see we are getting a 200 status for each request, which means “200 Ok”.

How do we know which payload combination worked and which hasn’t?

One way is to click on each request with a 200 Ok status, select the “Response” sub-tab, and search for the string named “Username and/or password incorrect”. We know this belongs to a failed login attempt.

If the string isn’t present, it means the credentials combination worked, and that would be our match.

BurpSuite Intruder figured out there is one positive match on the bottom right side of the screenshot. This is a time-consuming approach.

Focus on the size of the length as shown below. For all incorrect attempts, the response message length is the same “4666”. Check one of a different length, i.e., 4704.

Observe whether the username/password combination “admin/password” worked. Navigate to the response sub-tab, We can see the “welcome to the password protected area of admin” message.

Hurray!! we found the right password match! 👏

Password Match Verification

It is always good practice to re-verify the security bug before we report it.

Make sure all the Intercepts in the proxy tab are toggled to off. Then, let’s return to the brute force page and verify our match to confirm our results.

Yep, our newly found password combination worked.

Excellent! We found a security bug using a Brute-Force attack, i.e., a guessable username and password.

You were able to learn a quick way to Perform a Brute-Force attack using DVWA.

I have used a short custom-built word list for demo purposes, Give a try with other lists. Search for “Brute-Force attack” or “Brute force wordlist”, and you will find many resources.

Here are some lists from Github.

Impact of Brute Force Attacks

The impact of a successful brute force attack can be severe.

• Unauthorized access to sensitive information.
• Financial loss
• Loss of organization’s reputation
• Leading to potential legal and financial repercussions for the affected individuals or organizations.
• Loss of customer trust, etc.

Preventing Brute Force Attacks

Security Researchers and web application developers need to be familiar with mitigation techniques. These skills can help them defend web applications from malicious actors.

So, let’s talk about some ways to detect it and then mitigate it.

Patterns of Brute Force Attack

Some of the common patterns can help to detect brute-force attacks on our webserver.

• Too many requests originate from a single IP address within a minute or hour.
• Multiple logins of a single user account from a different IP address and province.
• Excessive usage of the server resources and bandwidth.
• Increased number of failed login attempts of various usernames and passwords.
• Logged into multiple user accounts from a single IP address. (i.e., guessable default password) etc.

The above is a small list targeting user credentials, but the patterns vary for other resources.

Defending Brute Force Attacks

Brute force attacks are difficult to stop, but with good measures, we can limit the attack surface.

Avoid Using Default/Guessable Passwords

One of the most commonly exploited techniques says some application servers come with pre-defined default passwords for the initially created accounts. (Say “admin/password”)

Default Password Database - cirt.net

Some companies follow an initial password with the company name followed by a number sequence. Say “ABCCompany123” or the special character “ABCCompany123$”, some with established year appending at the end with a prefix of the usernames “Username2022” etc.

These are all unknown until someone figures them out. Once figured out, they are easy to try out with all the user accounts to which the user account has access.

Additionally, prevent users from using passwords such as “password”, “admin123”, “12345” etc.

Limit Login Attempts

One good practice is to limit the number of failed login attempts the user is allowed to make. Beyond 7 failed login attempts, the account is locked for a temporary time period. Like banks, beyond three failed attempts, the user account will be locked out for 24 hours. Or

👥The challenge with this type is that unauthorized users keep trying with valid user accounts and lock out genuine users.

Enforce a Strong Password Policy

A best-designed password policy like the use of a combination of small case letters, upper case letter, numerics, special characters will make it hard to crack for attackers.

• Use of password managers wherever applicable.
• Avoid re-using the same password.
• The length of passwords is to be 8 or above.
• Prevent the use of common dictionary words or guessable sequences.
• Use of certificates for authentication rather than passwords.
• Educate users about using a different password for all accounts.

Progressive Delay

This is also the best technique where the wait time keeps on multiplying with each failed login attempt.

Say, initially start with “60 Seconds” wait time at the first attempt, then 15 minutes of wait time for the second attempt, 60 minutes for the third attempt, and so on it goes.

Generally, some applications multiply wait seconds by 60 for each failed attempt.

Using Captcha

Captchas are used to filter automated bots or programs and prevent them from abusing the services.

🤖This is a bit of an inconvenience, but solving a captcha will help verify that it’s human and not automation.

Multi-Factor Authentication

Adding additional layers of verification makes brute force attack very tough. Using the OTP - One-time passcode, verification of token through email, or Security Questions before logging in makes it more difficult for attackers.

The attacker needs to compromise multiple sources to gain access to your user accounts which is very tough but not impenetrable.

Storing Salted Password Hashes

Even though our application is secured in all possible ways, some third-party plugins or disgruntled employees may lead to compromise of the application and say the attacker was able to gain access to all the passwords in the database.

When a user enters the password say “admin123” it is not a good practice to store it as plain text. It must be hashed and stored.

hash(admin123) = GX8N365FMeK9hsRkW9Dl2S/ikcQ

Now add salt to the above hash. Where salt does not need to be a secret text but a random text. ( say “5MU63YzoOm7ig”)

The Hash + Salt will be displayed as shown below

hash(admin123 + 5MU63YzoOm7ig ) = LL/0NIJmT2JcfCXkfOln62pj8Hw

The salted hashes make it much more difficult for attackers to crack the passwords offline.

Even though the attackers have salted hashes, it would be tough for them to crack and re-use them. Meanwhile, requesting the user to reset the passwords in case of compromise makes it more secure.

Whitelisting

Whitelisting or Allowing a list is an approach of letting only what you trust and blocking all the rest from accessing.

Let’s say for high privileged admin user accounts, employ a way to whitelist the login’s from known IP addresses or authorized VPNs and restrict all others from accessing admin features.

This reduces a huge attack surface.

Using Web application firewalls

Configuring and using Web Application Firewalls (WAFs) protects web applications from a wide range of attacks, such as brute force attacks, denial of service attacks, and malicious input filtering, etc. Examples: AWS WAF, Cloudflare WAF, etc.

More information on blocking brute force attacks can be found on the Blocking Brute Force Attacks OWASP site.

Conclusion

Understanding the basics of brute-force attacks and their potential impacts is crucial for safeguarding against cyber threats. By implementing robust security measures, such as strong password policies, multifactor authentication, and network monitoring, individuals and organizations can mitigate the risk of falling victim to a brute-force attack.

Using of captcha’s can be inconvinient feature, but use it cautiously to prevent automated bots or from automated attacks. Hope by this you are familiar with what a brute force attack is and how it can be exploited.

Keep Learning!! 😄

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 Attack and Prevention Explained

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

admin
administrator
user
john
dvwa
bob
alice
root
superuser
super

passwords.txt

admin
admin123
password
password123
user
user123
administrator
passw0rd
r3m3mb3rM3
admin123$

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.

Required Tool Set

1. A working DVWA docker image will be needed.
2. BurpSuite Community Edition tool.
3. Wordlists (username.txt and password.txt)

If you are unable to follow any of the sections, refer back to the earlier posts.

DVWA - Brute Force Attack and Prevention Explained This detailed guide explains Brute Force Attacks, how they work, and ways to prevent them.

DVWA Brute Force Attack - Medium This detailed post explains Brute-Force Attacks’ Medium severity using DVWA and how partial security fixes can be bypassed.

DVWA Brute Force Vulnerability - Demo

Log into your DVWA environment, and click on the “Security level” menu on the left sidebar.

Select “High” and click on the submit button, as shown below, to ensure the Security Level is updated.

Re-testing Scenario

Imagine the development team returning again and informing you that the vulnerability is fixed and needs re-verification.

Let’s go ahead and repeat all the steps.

1. Launch the BurpSuite Community Tool.
2. Navigate to the “Proxy” tab -> “Intercept” sub-tab and click on the “Open Browser”
3. Once the Chromium browser is launched, login to the DVWA application using admin credentials.
4. Visit the “Brute Force” link in the menu.
5. Switch to the Burp Suite “Proxy” tab, select the “Intercept” sub-tab, and toggle “Intercept is Off” to enable it.
6. Enter the random values in the username and password fields, then click on “Login”.
7. The “Intercept” captured login request will be displayed below.

In line number 1, the test values are placed in the username and password fields. In line 16, the security level parameter is set to high.

Additionally, a new “user_token” is being passed in the URL parameter compared to the previous requests.

A copy of the previous request is provided below.

1. Click on the “Action” button or right-click and select “Send to the Intruder”.

2. In payload positions, “Clear” all the selected payload placeholders and then select the “Username” value field and the “Password” value field by clicking the “Add” button for placing custom payloads.

Choose the attack type to “Cluster bomb”

The same word list of common usernames and passwords can be used for the current scenario. Save the text files onto your system or use copy-paste to load the information in the payloads tab.

usernames.txt

admin
administrator
user
john
dvwa
bob
alice
root
superuser
super

passwords.txt

admin
admin123
password
password123
user
user123
administrator
passw0rd
r3m3mb3rM3
admin123$

In the “Payloads” sub-tab, select “Payload Set 1”, set the payload type as “simple list”, and paste all the contents in payload options copied from the usernames.txt list.

Second, select the “Payloads” sub-tab, set “Payload Set 2”, set the payload type as “simple list” and paste all the contents in payload options copied from the passwords.txt list.

Switch to the “Options” sub-tab and enable the “Grep - Match” with the “incorrect” string. so we can understand which requests have failed.

Lastly, click on “Start Attack” and monitor the results.

Failed Intruder Attack Results

Only in one response was the “username and/or password incorrect” string found.

For all other requests, we are getting “302” status codes instead of “200 OK”, which means something is not working and our brute force attack is failing.

Now, shall we assume that the “Vulnerability is fixed” and close the security flaw?

Well, we can close it. But this is a strange scenario in which we don’t see errors or warnings.

Let’s analyze more thoroughly and see what exactly is happening here. and why we are getting “302 Found” redirects.

Remember, you can automate only if application behaviour is consistent.

Re-submit the username and password with new random values on the Brute Force login page and intercept the login request.

Analyzing with the BurpSuite Tool without going to the browser gives us more control over the HTTP messages. Therefore, I want to view the HTTP response messages in the Burp Suite itself.

Let’s enable the option to Intercept and view the “Response” messages received from the server before sending them to the Browser.

Visit the “Proxy” tab -> Select “Options” sub-tab, scroll down to “Intercept Server Responses” and enable “Intercept responses based on the following rules” as displayed below.

Switch to the “Intercept” sub-tab under the “Proxy” tab and click on the “Forward” button.

The “Forward” button will send the request to the server and now start “Intercept” immediate HTTP “Response” received from the server and display it as shown below.

By clicking on the “Forward” button again, the response is now sent to the browser.

Toggle the proxy “Intercept is on” to disable it.

Use the BurpSuite “Chromium browser” session, manually try for random username/passwords say “administrator/admin123”, “admin/admin123”, “user/user123” etc.. with 4 or 5 incorrect credentials.

For all incorrect attempts, we keep getting the “Username and/or password incorrect.” message.

This confirms that the “Brute Force” attack still does exist, which means the Vulnerability remains Open. Yay!!. :)

Now the question is, why is our Intruder tool unable to pick it up?

Let’s review all the previous HTTP messages and see if we can find any patterns.

The Burp Suite HTTP message history can be found under the “Proxy” tab -> “HTTP history” sub-tab.

Observing the HTTP GET requests that we have manually tried, the username and password values are being passed, but one parameter value keeps on changing in the “URL” section.

Remember a new parameter is being passed on the Login request? Yes, “user_token”.

The “user_token” keeps updating for each request. Therefore, we cannot use the same “user_token” for all HTTP requests.

This is the reason our tool fails. If we perform brute force manually, it works!

Finding the origin of “user_token”

Let’s find out from where the “user_token” is being set and updated.

In the case of HTTP, it can be set in Headers, Response Bodies, or Cookies. Let’s review the HTTP responses received one by one.

After a thorough review Of one of the requests from HTTP history, I was able to find out it is being set in “HTTP Response Body”

<input type='hidden' name='user_token' value='90f9f7a06213b032dbe9e5d1d4717ce0' />

The code is a simple HTML tag that is hidden in the background of the “Login” page and passed every time when the user submits “username” and “password” credentials.

Based on the above request, the HTML input tag is dynamically generated on the fly with an updated “user_token”.

We found the source! Can you automate it with Burp Intruder? Yes

One more important point to discuss before we proceed.

Choosing the Intruder Attack Type

Guess what the attack type could be here?

Cluster Bomb? NO

Remember what the “Cluster bomb” does? It tries out all possible permutations and combinations by varying the first “Payload 1” and keeping the “Payload 2” standard, then jumps to the next permutation.

A big challenge here is, you cannot keep the “user_token” same for multiple requests.

Therefore, the “cluster bomb” doesn’t meet our requirements.

What about “Pitchfork”?

Yes, the “Pitchfork” option helps in the current scenario. Takes the first payload from “Payload set 1” and the first payload from “Payload set 2” and then iterates through.

Overall, our current wordlist of usernames and passwords generates only 10 possible payload requests, as shown below.

We could definitely miss our valid combination match. i.e., “admin/password”.

So, to brute force from here on, we need to use the username, which definitely exists on the server. (say “admin”)

The DVWA dev team gave us a good challenge. Let’s put in additional efforts to perform the Brute Force attack.

Fine-tuning the Intruder Payload

Repeat all the steps from step 1 to step 7 mentioned above, from the launching of the BurpSuite to sending the new log-in request to the intruder.

Use a completely new intercepted Login request, else intruder is bound to fail.

Choose the “Pitchfork” attack type and select two payload positions. i.e. password value field and user_token value field as displayed above.

This time for payloads, the first position will be of the password value field and the second position will be of the user_token value field.

Select the “Payloads” sub-tab, set “Payload Set 1”, payload type as “simple list” and paste the passwords.txt list contents into payload options.

Second, select the “Payloads” sub-tab, set “Payload Set 2”, and payload type as “recursive grep” from the list. This is for the “user_token” field.

The “recursive grep” is used when you want to extract specific data from the previous response and use it in the request as a payload.

The “Grep - Extract” feature is used to find specific strings based on the pattern or use regular expressions to get useful information from the HTTP response.

Next, go to the “Intruder” tab -> “Options” sub-tab, scroll down to “Grep Extract” and click on the “Add” button.

A new window named “Define extract grep item” is loaded.

In the “Define extract grep item” window, click on the “Fetch Response” button on the right side.

The “Fetch response” will take the currently configured request in the “fetch” tab and fetch, the server response for it.

Once the HTTP response is loaded, Using the mouse select the user_token value then select only the value string highlighted as shown below.

The “Start after expression” and “End at delimiter” values will be auto-populated. Just click on the “OK” button to proceed.

Use “Ctrl - c” to copy the token value “1802dab0e42ee4ef48e71d491981abb1” will be used for updating initial payload.

Switch back to the Intruder Payloads section. Observe the “Grep Extract” pattern updated and displayed in “Payload Options”.

Now, set the “initial payload for first request” value as the one we copied earlier, the latest token “1802dab0e42ee4ef48e71d491981abb1”.

All set, but there is one more thing to do.

Remember, a new user_user token can be fetched only when you send each request one by one after updating. If thrown multiple concurrent requests at once than we can’t get correct user token in sequence.

In the “Intruder” tab “Resource Pool” is a place where we can fine-tune the number of threads to use or delay between requests etc.

Navigate to the “Intruder” tab and select the “Resource Pool” sub-tab. Select “Create new resource pool” named “Brute Force Attack - High”.

Set the “Maximum concurrent requests” to 1.

Done, we have configured our intruder and now click to “Start attack” button.

Wow!! finally accomplished. 😄

The intruder configuration works, and we no longer see the “302 Found” redirect status codes being displayed.

Observe the user_token value taken from the previous response field, displayed under the “value” row and updated in the request as the “Payload 2”. The fine-tuning worked!

Let’s check the one with of different length “4792” and Yes, We found our credentials match (admin/password).

The “Grep - Match” flags can also be enabled.

Well done!! 🎉

Thus, the Brute force vulnerability still remains open.

We have covered a lot of ground here to exploit the Brute Force attack. Re-visit the article and keep practicing until you become familiar with it.

Check out the below article to learn more about prevention techniques.

DVWA - Brute Force Attack and Prevention Explained

Firstly, we will go through the standard practices that are generally used for mitigating the command injection vulnerabilities, followed by we will be covering how the vulnerability has been fixed in the DVWA application.

Avoid Calling OS Command Directly

One of the most effective ways is to avoid calling all the system commands directly by taking from the user input.

Using the built-in library functions is a good option, as it performs the tasks intended without tampering.

In our command injection examples, the application takes the domain name, and IP address then followed by we could append the additional system commands. The application doesn’t filter and is directly passed on to the server for execution.

If you were able to view the source code, the “shell_exec()” function in PHP is being used for taking all our user inputs and passing them to the server.

shell_exec( 'ping -c 4' . USER_INPUT );

The escapeshellcmd() or escapeshellarg() can be used instead of “shell_exec()” to prevent command injection. What it does is, it passes everything within a single quote ensuring to run all of one text rather than breaking it into multiple commands.

If you think, in your current scenario you can not avoid it but that’s the only way to go ahead. then there are other ways to mitigate it.

Whitelisting

As we covered whitelisting earlier. Whitelisting is an approach of letting only what you trust and rejecting all the unknown.

• Allowing only the valid characters, like small case letters, upper case letters, and numerics.
• Limiting only the special characters which are supposed to be used. (say, allow period “.” and reject all)
• Only allowing the system command that the user is supposed to use.

In the command injection “high” example, we say the blacklisting is being used to filter a lot of characters, where the ‘|’ OR and SPACE operator are being filtered than of “|” only OR operator.

Blacklisting can be used but is more of an error-prone approach.

Strong Input Validation

Validating the inputs in conjunction with whitelisting provides a strong defense.

Treating every input from the client can be tampered with, verifying the inputs and ensuring it is clean from all types of malicious payloads.

A parameterization is an option where the command and the input data can be segregated using a structured mechanism. This helps in quoting the input data before processing.

Never escape the user input with metacharacters directly as it is more error-prone.

Additionally, the Regular Expressions can also be used for filtering the input before processing.

Least Privilege User Account

Use a user account with minimal privileges to execute the needed system operations on the server rather than one having admin privileges.

Command Injection - Fix (DVWA)

Let’s see how the vulnerability was fixed in the DVWA application.

Log into the DVWA application and set the security level to “Impossible”.

Navigate to the “Command Injection” and click on the “View Source” button at the bottom.

Note, only the partial code is displayed below.

// Split the IP into 4 octects
$octet = explode( ".", $target );

// Check IF each octet is an integer

if( ( is_numeric( $octet[0] ) ) && ( is_numeric( $octet[1] ) ) && ( is_numeric( $octet[2] ) ) && ( is_numeric( $octet[3] ) ) && ( sizeof( $octet ) == 4 ) ) {

    // If all 4 octets are int's put the IP back together.

    $target = $octet[0] . '.' . $octet[1] . '.' . $octet[2] . '.' . $octet[3];
  // Determine OS and execute the ping command.

Code Snippet 1: Command Injection - Mitigation

In the above screenshot, the developer now has removed all types of blacklisting approaches and moved to a whitelist.

At the moment, only numeric IP addresses and a special character of a dot are allowed and reject all the other input.

This reduces the attack surface to a greater extent for exploitation.

More information about the mitigation techniques can be found on the OS Command Injection Defense - OWASP Cheat Sheet.

I Hope, Now you can secure your web applications from the command injection vulnerabilities. Thank you! :)