DVWA

All posts tagged DVWA

The assumption is that you are here because you are either trying to learn about web app pen testing or you are stuck on one of the challenges. Everyone has their own way that they like to approach web applications. This is mine. We will end up at the same place so don’t get too hung up on style, focus on content.

All of the posts here are spoilers

To setup for all of the different challenges in DVWA you need to set the security level. This is relatively simple, just click the DVWA Security button and set the level through the interface.

Set Security Level

Set Security Level

XSS Reflected – Low

I have security set to low and I have clicked on the XSS Reflected button. Nice test box huh? Well now what are you doing to do? I like to jump right in and start stuffing things in there. No foreplay or anything.

HTML Injection Test

HTML Injection Test

Why didn’t I go right for an alert(‘XSS’)? I like to see if HTML injection is possible at the same time. Feel free to skip that step and go straight to <script>alert(“XSS”)</script>. Look at that! HTML injection is possible. Let us go back and see if we can get a script to run.

HTML Injection Sucess

HTML Injection Sucess

XSS Script Success

XSS Script Success

TL;DR <script>alert(“XSS”)</script>

XSS Reflected – Medium

Set the DVWA Security to Medium and throw that script back in there.

Medium XSS Failure

Medium XSS Failure

Why didn’t that work? Time to dig into the page source. If you read the PHP by clicking on the View Source button the fumction checks for a null string. Then replaces the string <script> with ‘’ if it is found. That is super effective tools or testers that only use the exact string <script>. If you change it up a bit by adding capitalization <SCRipT> or <ScriPt> it doesn’t match and str_replace just passes it through. The PHP function is case sensitive but HTML is not.

PHP Function

PHP Function

TL;DR <SCRipt>alert(“XSS”)</scrIPT>

XSS Reflected – High

The High challenge uses the PHP function htmlspecialchars function to escape special characters. I have tried to encode the string in multiple ways and have not figured out a way to run a script. This is the correct way to handle user inputs and might be breakable but I haven’t found a way around it yet.

Normally, I use Burp Suite to do everything because it does everything. That is because I have the pro version. If you have the community version you know that some of the attacks are throttled and the vulnerability scanner just doesn’t exist. If you don’t have the pro version of Burp or just want to try a different toolset this tutorial will take you through attacking the initial login page of the Damn Vulnerable Web App (DVWA site, DVWA ISO).

Once the application is up and running you will be presented with the initial page.

DVWA Login Page

Home page for DVWA

Now what? You can either skip to the bottom and find it or we can brute-force the password and learn something. First thing we need to do is figure out what to attack. The easiest way is to look at the source code for the page.

Souce Review

Souce Review

 

A second way is to capture a request to the page using a proxy, in keeping with the spirit of not using Burp, I grabbed this one using OWASP Zap.

Zap Proxy Request Capture

Zap Proxy Request Capture

The three fields are username, password, and Login. The next crucial piece is knowing what a bad login displays. This gives Hydra a way of discriminating between valid and bad login attempts.

Failed DVWA Login

Failed DVWA Login

I’m going to use xHydra but will give the command to run Hydra from a shell if that is the only access that you have on a system. Launch Hydra, on Kali Linux it is under the /usr/bin directory. The following images show all of the options being set.

OWASP Target Setup

OWASP Target Setup

Set the IP of the DVWA server and the protocol in use, for this we are attacking the web form so http-post-form. To attack a login of any type you need two other things, a username and a password. The rockyou word list exists at /usr/share/wordlists. I created a short list of usernames to use also.

User List

User List

User Name and Password for Hydra

User Name and Password for Hydra

The next step is to tune the brute force attack. I can use 32 threads and a 1 second timeout because both of the virtual machines, a Kali Linux attacker and the DVWA target, are on the same local LAN segment and there is no concern of causing a denial of service. Also, piping the attack through the Zap proxy is optional and not necessary.

Hydra Tuning

Hydra Tuning

The next tab is where all of the heavy lifting happens. The http / https url field contains the ‘:’ separated string /login.php:username=^USER^&password=^PASS^&Login=Login:Login failed. Breaking out the string the /login.php is the login page. The username and passwords fields are linked to the ^USER^ amd ^PASS^ variables; these are the options set in the Passwords tab. The Login field is not linked to a variable but is used in the login string that we found in image 3. The last string Login failed is what we determined indicated a bad attempt.

Hydra HTTP Setup

Hydra HTTP Setup

Once you are all set to go just click Start on the last tab and watch it go. If you look really closely at password setup you’ll see that I cheated a bit and just ran a single password. I started running the rockyou wordlist and then realized that it would take a significant amount of time to complete.

Brute Force Success

Brute Force Success

To run this from a shell instead of the GUI use:

hydra –L UserNameFile –P PasswordFile –e ns –t 32 –u –f –m /login.php:username=^USER^&password=^PASS^&Login=Login <IP> http-post-form

-e ns checks for passwords that are the same as the username (s) and null (n)

-f exits after the first pair is found

-u is supposed to make the attack faster according to their readme but it doesn’t really say how. I think that it is a unique switch but I don’t have any proof.

Stay tuned for more DVWA updates on the challenges you now have access to since you brute forced this password.