DVWA Command Injection Walkthrough

Command injection is one of the most severe vulnerabilities that can exist in a web application. It allows an attacker to execute arbitrary operating system commands on the server hosting the application. If exploited successfully, it can lead to full system compromise, privilege escalation, and even lateral movement into internal network infrastructure.

In this walkthrough, we will analyze the Command Injection module in Damn Vulnerable Web Application (DVWA) across different security levels.

The objective is to understand how command injection vulnerabilities arise and how attackers can exploit weak input handling to execute commands on the server.

Low Security Level

OS command injection occurs when an application passes unsanitized user input directly into a system command.

Before attempting exploitation, it is always important to understand how the application behaves under normal conditions.

In this case, the application provides a simple interface that allows the user to ping a device by entering an IP address.

To test the functionality, we can enter a valid IP address such as Google’s DNS server:

8.8.8.8

You may also test with other IP addresses such as Cloudflare’s DNS or any reachable host.

The application successfully sends four packets and receives responses, confirming that the ping functionality works as expected.

Now that we understand the expected behavior, we can start testing whether the application is vulnerable.

During testing, it is important to remember that vulnerabilities rarely reveal themselves immediately.

Attackers often try different types of injections such as SQL injection, SSTI, command injection and more when interacting with input fields.

To test for command injection, we append additional commands to the input.

The general structure is:

• Terminate the original command using a command separator
• Insert the command we want executed
• Optionally add another terminator to prevent breaking the command chain

Common command separators include:

• ;
• &&
• ||

There are many others, and the behavior can depend on the operating system and shell environment.

For testing, we will attempt to run the pwd command.

First, we try:

1.1.1.1||pwd

The application pings the IP address, but the additional command does not execute.

Next, we try different terminators such as:

• 1.1.1&&pwd
• 1.1.1.1;pwd

This time the application pings the IP address and executes our injected command, confirming the vulnerability.

To further confirm the vulnerability, we can run another command such as ifconfig.

This command reveals network interface information from the server hosting the application.

Other separators such as the single pipe character ( | ) can also be used.

Each command separator has slightly different behavior depending on how commands are chained together. The list of possible separators is not exhaustive.

Reviewing the Application Code

After reviewing the application code, we can identify the root cause of the vulnerability.

The code:

• Retrieves user input (ip) using $_REQUEST.
• Detects the server operating system using php_uname('s').
• Uses different ping commands depending on whether the OS is Windows or Linux.
• Executes the command using shell_exec().
• Directly inserts user input into the system command without sanitization.

Because the user input is passed directly into the shell command, attackers can easily append additional commands.

Medium Security Level

As always, begin by testing the normal functionality of the application.

The ping feature still behaves the same when a valid IP address is entered.

Next, we attempt the same injection techniques used previously.

However, when trying separators such as ; or && the commands no longer execute.

There is no additional output from the injected commands.

Similarly, using:

1.1.1.1||ifconfig

results only in the IP being pinged, and the command does not execute.

This behavior is unusual and suggests that some characters may be blocked or filtered by the application.

To investigate further, we attempt using a single pipe character instead of two.

1.1.1.1|ifconfig

After submitting the request, the application executes our command.

However, instead of pinging the IP address, it directly runs the injected command and displays the network information of the server.

To verify the vulnerability again, we can run another command such as pwd .

This confirms that command injection is still possible.

From these observations, it appears that certain special characters are being filtered, but the filtering is incomplete.

Brute Forcing Command Separators

To identify which separators are allowed, we can brute-force possible characters using Burp Suite.

Intercept the request and send it to Intruder.

We will use the command ifconfig since a successful execution will produce a longer response, making it easier to detect.

Place the payload position between the IP address and the command.

Use a Simple List payload containing different command separators.

Start the attack.

After the attack completes, sort the results by response length.

You will notice that three payloads produce longer responses:
-
- &

We have already tested | and ||.

If we inspect the response for the payload &, we can see that the injected command executes before the ping command.

Reviewing the Source Code

Examining the application code reveals the reason behind this behavior.

The application attempts to block command injection by replacing:

• &&
• ;

with a space.

Although this may prevent some injections, the approach is flawed because it relies on blacklisting specific characters rather than properly sanitizing input.

Attackers can simply use other separators that were not filtered.

Tip for Payloads with Spaces

When injecting commands that require spaces, you can bypass restrictions using techniques such as:

• URL encoding spaces as %20.
• Using + instead of spaces in URL parameters.
• Using ${ IFS } in shell environments. (don’t add space within {})

Example:

8.8.8.8|cat${ IFS }/etc/passwd

High Security Level

At the high security level, the application attempts to implement stronger filtering.

Testing the functionality again shows that most command separators no longer work.

However, the single pipe character ( | ) still successfully executes commands.

Running the brute-force attack again confirms this behavior.

When filtering the results by response length, only the request using the pipe character produces a longer response.

This strongly suggests that most command separators have been blacklisted.

Reviewing the Source Code

Looking at the source code, we see that the application attempts to block many command separators by replacing them with spaces.

Interestingly, the pipe character ( | ) appears in the blacklist.

However, a closer look reveals that the character listed in the filter actually includes a space after the pipe, meaning it does not match the actual | character used in our attack.

Because of this subtle mistake, the filter fails to block the pipe separator.

This demonstrates why blacklist-based filtering is unreliable.

Recommendations

To prevent command injection vulnerabilities, the following practices should be implemented:

• Avoid executing system commands using user-supplied input.
• Use secure APIs or system libraries instead of shell commands whenever possible.
• Implement strict input validation and allowlists rather than blacklists.
• Escape user input using secure escaping functions such as escapeshellarg() or escapeshellcmd().
• Run applications with least privilege to reduce the impact of exploitation.
• Use web application firewalls to detect malicious payloads.
• Implement logging and monitoring to detect suspicious command execution attempts.

Properly validating input and avoiding direct shell command execution are critical steps toward protecting applications from command injection attacks.