DVWA

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.

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.
  

• 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”.
  

• /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.
  

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.

Examples

The example is also based on 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.
  

• 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.

• 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.

• 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.

• 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:

• 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:

• 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 #:

• 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:

• 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.