As in the case of SQLi and others, command injection vulnerabilities are due to a poor input validation mechanism and the use of user-provided data to form strings that will later be used as commands to the operating system. If we look at the source code of the page we just attacked (there is a button in the bottom right-hand corner on every DVWA's page), it will look just like this:

<?php
if( isset( $_POST[ 'submit' ] ) ) 
{
    $target = $_REQUEST[ 'ip' ];
    // Determine OS and execute the ping command.
    if (stristr(php_uname('s'), 'Windows NT')) 
    {
        $cmd = shell_exec( 'ping ' . $target );
        echo '<pre>'.$cmd.'</pre>';
    } 
    else 
    {
        $cmd = shell_exec( 'ping -c 3 ' .$target );
        echo '<pre>'.$cmd.'</pre>';
    }
}
?>

We can see it directly appends the user's input to the ping command. All we did was to add a semicolon, which the system's shell interpreted as a command separator, and next to it, the command we wanted to execute.

After having a successful command execution, the next step was to verify whether the server had NetCat, which is a tool that has the ability to establish network connections and, in some versions, to execute a command when a new connection is established. We saw that the server's system had two different versions of NetCat and executed the one we know supports the feature we require.

We then set our attacking system to listen for a connection on TCP port 1691 (it could have been any other available TCP port), and after that, we instructed the server to connect to our machine through that port and to execute /bin/bash (a system shell) when the connection establishes. Anything we send through that connection will be received as input by the shell in the server. The use of & at the end of the command is to execute it in the background and prevent the PHP script's executions from stopping because it's waiting for a response from the command.