lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <43FF36D7.5050908@gulftech.org>
Date: Fri, 24 Feb 2006 10:39:51 -0600
From: GulfTech Security Research <security@...ftech.org>
To: Secunia Research <vuln@...unia.com>, moderators@...db.org,
	bugtraq@...urityfocus.com
Subject: Mambo Multiple Vulnerabilities


##########################################################
# GulfTech Security Research            February 24, 2006
##########################################################
# Vendor : Miro International Pty Ltd
# URL : http://www.mamboserver.com/
# Version : Mambo <= 4.5.3h
# Risk : Multiple Vulnerabilities
##########################################################



Description:
Mambo is a popular Open Source Content Management System
released under the GNU General Public license (GNU GPL).
There are a number of security issues in Mambo which allows
for SQL Injection, Authentication Bypass, and possible remote
code execution via local file inclusion. There has been an
updated version of Mambo released and all users are advised
to upgrade as soon as possible. Also, please note that these
vulnerabilities are NOT related to any worms currently taking
advantage of vulnerable Mambo installations.



SQL Injection:
There are several SQL Injection issues in Mambo Open Source.
The easiest to exploit of the issues allows an attacker to
login as any user. The only info the attacker has to have is
the target username (if no user is specified, the first user
from the users table will be selected instead).


function login( $username=null,$passwd=null ) {
global $acl;

$usercookie = mosGetParam( $_COOKIE, 'usercookie', '' );
$sessioncookie = mosGetParam( $_COOKIE, 'sessioncookie', '' );
if (!$username || !$passwd) {
	$username = trim( mosGetParam( $_POST, 'username', '' ) );
	$passwd = trim( mosGetParam( $_POST, 'passwd', '' ) );
	$passwd = md5( $passwd );
	$bypost = 1;
}
$remember = trim( mosGetParam( $_POST, 'remember', '' ) );

if (!$username || !$passwd) {
	echo "<script> alert(\""._LOGIN_INCOMPLETE."\"); window.
	history.go(-1); </script>\n";
	exit();
} else {
	$this->_db->setQuery( "SELECT id, gid, block, usertype"
	. "\nFROM #__users"
	. "\nWHERE username='$username' AND password='$passwd'"
	);
	$row = null;
	if ($this->_db->loadObject( $row )) {
		if ($row->block == 1) {
			echo "<script>alert(\""._LOGIN_BLOCKED."\"); window.
			history.go(-1); </script>\n";
			exit();
		}
		// fudge the group stuff
		$grp = $acl->getAroGroup( $row->id );
		$row->gid = 1;

		if ($acl->is_group_child_of( $grp->name, 'Registered', 'ARO' ) ||
		$acl->is_group_child_of( $grp->name, 'Public Backend', 'ARO' )) {
			// fudge Authors, Editors, Publishers and Super Administrators
			into the Special Group
			$row->gid = 2;
		}
			

The above code is from mosMainFrame class (/includes/mambo.php)
and is the source of the previously mentioned problem. The
function mosGetParam() for the most part just imports GPC
variables, and has no real effective filtering or the like, so
several variables shown above contain unsanitized data. These
variables include $username, which is shortly thereafter passed
to the query, thus allowing a user to bypass a login by supplying
a username of "user'/*" and any password. This is a very serious
issue, but should prove easy to fix by either adding better
filtering in the mosGetParam() or sanitizing the data within the
login() function, or both. If a malicious user is able to use this
vulnerability to gain admin privileges then it is pretty much
game over as an attacker could then upload, and install a malicious
module and execute any php code of their choice on the server.

Another issue with Mambo Open Source is data passed to the
mosMenuCheck() function is usually unsanitized in regards to the
$task parameter.

function mosMenuCheck( $Itemid, $menu_option, $task, $gid ) {
global $database;
$dblink="index.php?option=$menu_option";
if ($Itemid!="" && $Itemid!=0) {
	$database->setQuery( "SELECT access FROM #__menu WHERE id='$Itemid'" );
} else {
	if ($task!="") {
		$dblink.="&task=$task";
	}
	$database->setQuery( "SELECT access FROM #__menu WHERE link like 
'$dblink%'" );
}
$results = $database->loadObjectList();
$access = 0;
//echo "<pre>"; print_r($results); echo "</pre>";
foreach ($results as $result) {
	$access = max( $access, $result->access );
}
return ($access <= $gid);
}

As seen in the above code the unsanitized $task variable will be
used in the query as long as $Itemid is empty.

http://mambo/index2.php?option=com_content&task=-99'%20UNION%20SELECT%201%20FROM%20
mos_users%20WHERE%20username='admin'%20AND%20MID(password,1,1)='2'/*&id=24&Itemid=0

If the first character from the password hash belonging to the
user "admin" is two as specified above then Mambo displays the
error "You need to login". This is an easy issue to exploit,
and unfortunately mosMenuCheck() is called in the same unsafe
manner from other files as well. Last but not least there is an
SQL Injection issue in the "com_content" component, particularly
the showCategory() function.

// get the total number of published items in the category
// filter functionality
$filter = trim( mosGetParam( $_POST, 'filter', '' ) );
$filter = strtolower( $filter );
$and = '';
if ( $filter ) {
	if ( $params->get( 'filter' ) ) {
		switch ( $params->get( 'filter_type' ) ) {
			case 'title':
				$and = "\n AND LOWER( a.title ) LIKE '%". $filter ."%'";
				break;
			case 'author':
				$and = "\n AND ( ( LOWER( u.name ) LIKE '%". $filter ."%' ) OR
				( LOWER( a.created_by_alias ) LIKE '%". $filter ."%' ) )";
				break;
			case 'hits':
				$and = "\n AND a.hits LIKE '%". $filter ."%'";
				break;
		}
	}

}

As you can see from the above code, the $filter variable is passed
to the query completely unsanitized, and allows for easy to exploit
SQL Injection. This is very dangerous.

filter=' UNION SELECT 
1,2,3,4,CONCAT(username,CHAR(58),password),6,7,8,9,1 FROM mos_users
WHERE 
1/*&order=rdate&limit=10&id=0&sectionid=&task=category&option=com_content

The above data sent in a post request to the vulnerable script will
effectively dump every single username and password hash in the
database to the attacker. It should be noted that the above attacks are
only effective in the default php enviornment of magic_quotes_gpc off



Arbitrary File Inclusion:
It is possible to include arbitrary local files, and ultimately execute
code within the vulnerable Mambo Open Source installation. The problem
lies in the _setTemplate() function not properly sanitizing GPC data.

// TemplateChooser Start
$mos_user_template = mosGetParam( $_COOKIE, 'mos_user_template', '' );
$mos_change_template = mosGetParam( $_REQUEST, 'mos_change_template', 
$mos_user_template );
if ($mos_change_template) {
	// check that template exists in case it was deleted
	if (file_exists( 
"$mosConfig_absolute_path/templates/$mos_change_template/index.php" )) {
		$lifetime = 60*10;
		$cur_template = $mos_change_template;
		setcookie( "mos_user_template", "$mos_change_template", time()+$lifetime);
	} else {
		setcookie( "mos_user_template", "", time()-3600 );
	}
}

As seen in the above code, there are several unsanitized variables
introduced into the function, and $mos_change_template in particular
is ultimately set as the current template and used through out the
application. There are never any effective traversal checks, so we
can include arbitrary locations on the local machine, and in some
cases execute arbitrary code as long as the file is named index.php
(i.e. /tmp/index.php) The reason for the restrictions are because
of the strip_tags call in mosGetParam, but some older versions of php
do not use a binary safe strip_tags (CAN-2004-0595) which allows for
null characters. So, in those cases the file inclusion is much more
dangerous and easy to exploit.



Solution:
There has been a new version of the Mambo software released to fix
the previously mentioned vulnerabilities.

http://mamboxchange.com/frs/?group_id=5

The above link contains all of the relative patches as well as the
secured full releases. Users are encouraged to upgrade their Mambo
installations as soon as possible.



Credits:
James Bercegay of the GulfTech Security Research Team



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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ