Chrismas Gift: A better & safer DVWA (to all!)

9:55 AM

Thanks to me, DVWA have been facing some unintended security
abuse, including a very severe & unintended remote command execution. This
one was the most severe of all the unintended bugs I discovered in DVWA. Using
this, just because you have DVWA installed and your server is running, anybody
can execute a command on your box using a CSRF (yeah, I know how weird that
might sound for some of you, long story short it was nasty).

Not yet pulled at github, but for now, it can be downloaded at dropbox!

So I contacted RandomStorm & Ryan Dewhurst (Original
author of DVWA). And, after further review, we concluded that DVWA high level
should no longer be considered safe. Since it is supposed to teach developers the
safest way of basic web app security, and it didn’t (it did at one point). But
within time, security grows and multiple attack vectors rise such as the
Rosetta Flash.

Mainly targeting to fix the RCE by deploying an anti-CSRF
token, I started the project with a colleague. Then we got time, so what the
hell, fixed a bunch of other bugs (only in the high level, since that’s what’s
supposed to be secured), and changed the graphics to a hacker-friendly design. We
fixed a bunch of unintended bugs in the high level and in the site itself,
mostly file manipulation included.

In case you didn’t check out my first post about most of the
issues, I won’t (re?)cover them here. Check them out at here.

In this post I will mention the not-so-popular yet deadly
dangerous bug “Rosetta Flash”. On ‘most’ upload forms,

This vulnerability allows an attacker read the client side
source code of a website from a different origin (say hacker.com) and then look
for potentially sensitive data in those pages for example - CSRF prevention
tokens and then successfully mount a side-wide CSRF attack.

Flash’s weird problem(?) - Attacking

“An attacker
creates a malicious Flash (SWF) file

The attacker
changes the file extension to JPG

The attacker
uploads the file to victim.com

The attacker
embeds the file on attacker.com using an embed tag with type
“application/x-shockwave-flash

The victim visits
attacker.com, loads the file as embedded with the tag

The attacker can
now send and receive arbitrary requests to victim.com using the victims session

The attacker sends
a request to victim.com and extracts the CSRF token from the response or read
messages or perform any action. (regardless of Content-Type)”

We fixed this simply by deploying a
Content-Disposition-header and a confirmation wheater the uploaded file was
really an image and not a flash or any other format by using getimagesize()
& imagecreatefromjpeg() also, an X-Content-Type: nosniff header to not let Internet explorer confuse the file as an invalid data and sniff its contents as text/html (could be abused to create a persistent XSS).

If your upload script looks like the one in DVWA, check out
the new version (more to talk about). The others include giving the uploaded
files random names, or it might result XSS and in some cases file inclusion
when files names like “../../../config.php%0.0shit.jpg” got uploaded.

You Might Also Like

0
comments

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.