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.

Overtime, old security becomes a joke.

& Happy Holidays!