LFI / RCE vlunerability in Joomla Community Builder Enhenced (CBE) Component

Hello full-disclosure!

Description:
Joomla CBE suffers from a local file inclusion vulnerability. As CBE
also offers file uploading functionality that allows to upload files
that contain php-code, this can be used to execute arbitary
system-commands on the host with the webservers privileges.

Risk:
High

Affected versions:

• CBE v1.4.10
• CBE v1.4.9
• CBE v1.4.8
  (maybe older versions)

Not affaceted:

• CBE v1.4.11 (current)

Vulnerable code:
in cbe.php a file identified by the param "tabname" is included if the
"ajaxdirekt" param is set, without sanatizing the value of "tabname" first:

$ajaxdirekt = JRequest::getVar('ajaxdirekt', null);
$tabname = JRequest::getVar('tabname', null);

 if ($ajaxdirekt) {
     $tabfile = 

JPATH_SITE.DS.'components'.DS.'com_cbe'.DS.'enhanced'.DS.$tabname.DS.$tabname.".php";
if (file_exists($tabfile)) {
include_once($tabfile);
}
return;
}

Exploitation / poc:
index.php?option=com_cbe&task=userProfile&user=23&ajaxdirekt=true&tabname=…/…/…/CREDITS.php%00

will execute the CREDITS.php

Addional attack-vectors:
CBE offers a file-upload function for uploading user profile images. The
uploaded file is not checked for beeing well-formed, it only needs to
have the right mime-type and maybe (depends on profile-picture
configuration) the right size, so we can embed php-code in the
profile-picture. Lets say we have registered an account on the site with
the user-id 23, then we can execute the backdoor by requesting:

index.php?option=com_cbe&task=userProfile&user=23&ajaxdirekt=true&tabname=…/…/…/images/cbe/23.gif%00

As we stay in the documents-root, we dont even have to worry about
safe-mode directory restrictions, and using GIFs will bypass most of
CBE's image pre-processing functions during file upload (except file-
and image-size checks).

Solutions:
a) check if the contents of an uploaded file contains a php open-tag
('<?php') (requires that the php-short-open-tag option is disabled)
b) Joomla offers several functions for accessing POST and GET params, i
guess using getWord() instead of getVar() would be a better choice in
this case.

History:
04.10.2010 - vendor informed
07.10.2010 - vendor released fixed version
08.10.2010 - public disclosure

Cheers
Delf Tonder