Message-ID: <bbdf9b020512200024x2ba50524m2afdc54cf36fbd75@mail.gmail.com>
Date: Tue, 20 Dec 2005 16:24:53 +0800
From: Gerry Chng <gerry.chng@...il.com>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Vulnerability in Metadot portal server allows
	users to gain administrative privileges


Title
---------------------------------------------------------------------------------------
Vulnerability in Metadot portal server allows users to gain
administrative privileges

Vendor
---------------------------------------------------------------------------------------
Metadot Corporation (http://www.metadot.com)

Summary
---------------------------------------------------------------------------------------
Any logged in user can be added into any group, including the SITE_MGR
group, effectively gaining a subset of the administrative privileges.

Description
--------------------------------------------------------------------------------------
Metadot is an open-source portal software used for creating websites
and portals. It provides users with a quick interface to start
building their web portals.  Features available in Metadot's portal
server include discussion forums, polls, calendars, FAQs etc.

Vulnerability
---------------------------------------------------------------------------------------
During a penetration test, it was discovered that an authenticated
user can access and manage groups which they are not owners or members
of.  This includes the Metadot default site manager (SITE_MGR) group. 
As a result, users can manage any group and add or remove accounts
from that group.

Hence, to gain administrative privileges on a Metadot portal, an
attacker can simply add himself into SITE_MGR group.  Site managers
are allowed to perform many administrative tasks and have the ability
to modify site content.  This exploit to gain administrative
privileges can be carried out as long as the attacker knows the group
identification number of SITE_MGR group as well as the correct fields
to alter in the URL.

The vulnerability is caused by stale global variables ($IS_OWNER,
$IS_MANAGER, $IS_ADMIN) which have not been reset appropriately in
Metadot's "Group.pm" Perl module.  In the case that a previous
operation has set the parameters to 1, a subsequent call does not
reset it.  This vulnerability is seen in the
set_group_permission_variables() function call as illustrated in the
code snippet below.

Code snippet from Group.pm
---------------------------------

sub set_group_permission_variables {
    my $self = shift;
    my $grp_id = $self->{grp_id};
    my $owner_uid = $USER->{uid};

    if (DBAccess->sqlSelect ("group_name", "grp", "grp_id = $grp_id
and userid = '$owner_uid'")) {
        $IS_OWNER = 1;
    } elsif ( $ACCESS_BROKER->is_allowed_to_do('manage_registrations') ) {
        $IS_ADMIN = 1;
    } elsif (DBAccess->sqlSelect ("is_manager", "grpmembers", "grp_id
= $grp_id and userid = '$owner_uid' and is_manager = 1")) {
        $IS_MANAGER = 1;
    }
}

It can be seen from the codes that the variables $IS_OWNER, $IS_ADMIN,
and $IS_MANAGER are only set to '1' if privileges are correct.  In the
event that the privileges are incorrect, the values are not set and
the global variables retain its previous values as set from other
operations.  Thus, this vulnerability can be exploited by performing
operations that first set this variable to '1', then access the
SITE_MGR group.

Affected versions
---------------------------------------------------------------------------------------
The vulnerability affects Metadot version 6.4.4 as well as earlier versions.

Solution
---------------------------------------------------------------------------------------
Metadot has since addressed this bug in its latest download (version
6.4.5) available at http://www.metadot.com/

Alternatively, to fix the problem, reset the global variables in
"Group.pm" by adding the 5th line ($IS_OWNER=$IS_ADMIN=$IS_MANAGER=0)
in set_group_permission_variables method:

sub set_group_permission_variables {
my $self = shift;
my $grp_id = $self->{grp_id};
my $owner_uid = $USER->{uid};

$IS_OWNER = $IS_ADMIN = $IS_MANAGER = 0;

if (DBAccess->sqlSelect ("group_name", "grp", "grp_id = $grp_id and
userid = '$owner_uid'")) {
	$IS_OWNER = 1;}
elsif ( $ACCESS_BROKER->is_allowed_to_do('manage_registrations') ) {
	$IS_ADMIN = 1;}
elsif (DBAccess->sqlSelect ("is_manager", "grpmembers", "grp_id =
$grp_id and userid =          '$owner_uid' and is_manager = 1")) {
	$IS_MANAGER = 1;}
}

History
---------------------------------------------------------------------------------------
Discovery: 29 November 2005
Vendor notified: 29 November 2005
Patch released: 18 December 2005
Public disclosure: 20 December 2005

Authors
---------------------------------------------------------------------------------------
Gerry Chng
Claudean Zheng

Gerry and Claudean are part of the Attack & Penetration team in Ernst
& Young Labs for Internet and Security (EYLIS)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists