Vulnerability in Metadot portal server allows users to gain administrative privileges

2005.12.22
Risk: Medium
Local: No
Remote: Yes
CWE: CWE-Other


CVSS Base Score: 9/10
Impact Subscore: 10/10
Exploitability Subscore: 8/10
Exploit range: Remote
Attack complexity: Low
Authentication: Single time
Confidentiality impact: Complete
Integrity impact: Complete
Availability impact: Complete

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


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top