Message-ID: <20070411152355.18323.qmail@securityfocus.com>
Date: 11 Apr 2007 15:23:55 -0000
From: gmdarkfig@...il.com
To: bugtraq@...urityfocus.com
Subject: PunBB <= 1.2.14 Multiple Vulnerabilities (Advisory)

       Title:    PunBB <= 1.2.14 Multiple Vulnerabilities
      Author:    DarkFig < gmdarkfig (at) gmail (dot) com >
  Written on:    2007/04/08
 Released on:    2007/04/11
  Risk level:    High
         URL:    http://www.acid-root.new.fr/advisories/13070411.txt
     Summary:    SQL Injection, Cross site scripting, Code execution
    Solution:    A new version of PunBB (1.2.15) has been released.



-=[ DESCRIPTION ]

  PunBB is a fast and lightweight PHP-powered discussion board. It is
released under the GNU General Public License. Its primary goals are
to be faster, smaller and less graphically intensive as compared to
other discussion boards. PunBB has fewer features than many other
discussion boards, but is generally faster and outputs smaller,
semantically correct XHTML-compliant pages.



-=[ VULN #1 ]

Risk level: Medium
      Type: SQL Injection
Conditions: PHP <= 4.4.2 or PHP <= 5.1.3
            register_globals=On
            ini_get() problem

  The "search.php" file contains the following php code:

 49| if (isset($_GET['action']) || isset($_GET['search_id']))
   | [...]
 54| if (isset($search_id)) unset($search_id);
 55|
 56| // If a search_id was supplied
 57| if (isset($_GET['search_id']))
 58| {
 59|     $search_id = intval($_GET['search_id']);
 60|     if ($search_id < 1)
 61|         message($lang_common['Bad request']);
 62| }
   | [...]
100| if (isset($search_id))
104| $result = $db->query('SELECT search_data FROM '.$db->prefix
   | .'search_cache WHERE id='.$search_id.' AND ident=\''
   | .$db->escape($ident).'\'') or [...]

  When I did see this code, I thought that there was an SQL Injection with
the Zend_Hash_Del_Key_Or_Index vulnerability and register_globals=On.
But let's see another file, the "include/common.php" file contains
the following code:

39| // Reverse the effect of register_globals
40| if (@ini_get('register_globals'))
41|	unregister_globals();

  If ini_get('register_globals') returns TRUE, the unregister_globals()
function is called. The "@" has been used if an error occured (Warning..),
because on many servers this function is disabled for security reasons.
It's the case on my server, if I remove @, I obtain this :

Warning: ini_get() has been disabled for security reasons in [...]

  In this case, ini_get('register_globals') returns FALSE even if
register_globals=On, so unregister_globals() isn't called. The
unregister_globals() functions contains the following code:

1037| function unregister_globals()
1038| {
1039| 	// Prevent script.php?GLOBALS[foo]=bar
1040| 	if (isset($_REQUEST['GLOBALS']) || isset($_FILES['GLOBALS']))
1041| 		exit('bip bip biiiiiiiip');
1042| 	
1043| 	// Variables that shouldn't be unset
1044| 	$no_unset = array('GLOBALS', '_GET', '_POST', '_COOKIE',
    |   '_REQUEST', '_SERVER', '_ENV', '_FILES');
1045|
1046| 	// Remove elements in $GLOBALS that are present in any of
    |   the superglobals
1047|	$input = array_merge($_GET, $_POST, $_COOKIE, $_SERVER, $_ENV,
    |   $_FILES, isset($_SESSION) && is_array($_SESSION) ? $_SESSION : array());
1048|	foreach ($input as $k => $v)
1049|	{
1050|		if (!in_array($k, $no_unset) && isset($GLOBALS[$k]))
1051|		{
1052|	           unset($GLOBALS[$k]);
1053|		   unset($GLOBALS[$k]); // zend_hash_del_key_or_index protection
1054| 		}
1055| 	}
1056| }

  If register_globals=On and if there is a problem (see [1] / [2] for
example) concerning the ini_get() function, there is an SQL Injection
(with the Zend_Hash_Del_Key_Or_Index vulnerability). The attacker will
forge an HTTP packet which looks like this:

GET /punbb1-2-14/search.php?action=show_new HTTP/1.1\r\n
Host: localhost\r\n
Connection: keep-alive\r\n
Cookie: punbb_cookie=<thecookiehere>\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 55\r\n\r\n
search_id=-1%20OR%201%3D1%23&1986084953=1&-1234899993=1\r\n\r\n

  After getting the password (hashed), you don't need to break it. As
Nms (see [3]) said, it's easy to forge a cookie. Let's see the
check_cookie() function:

39| if (isset($_COOKIE[$cookie_name]))
40| list($cookie['user_id'], $cookie['password_hash']) =
  | @unserialize($_COOKIE[$cookie_name]);
  | [...]
49| if (!isset($pun_user['id']) || md5($cookie_seed.$pun_user['password']) !==
  | $cookie['password_hash'])

  The $cookie_seed value is stored in the "config.php" file, but we
can retrieve it with an SQL request (with the SQL Injection). The hash
stored in the cookie ($cookie['password_hash']) looks like this:

mysql> SELECT MD5(
    -> CONCAT(
    -> SUBSTR(
    -> MD5(
    -> /* $cookie_seed value */
    -> (SELECT registered FROM users WHERE LENGTH(registered)=10
    -> ORDER BY registered LIMIT 1)),-8),
    -> /* The hashed password */
    -> (SELECT password FROM users WHERE id=<user_id>)))
    -> /* Ouput -> f4684bb1418c241992c6b8f9d70a4edb */;

  The solution is quite simple, in "include/common.php", remove the
condition ("if(ini_get...") and even if ini_get('register_globals')
returns FALSE, apply the unregister_globals() function.



-=[ VULN #2 ]

Risk level: Low
      Type: Cross Site Scripting
Conditions: none

  In the "misc.php" file the "Referer" header isn't properly filtered
before being used. The file contains the following code:

128| $redirect_url = (isset($_SERVER['HTTP_REFERER']) &&
   | preg_match('#^'.preg_quote($pun_config['o_base_url']).'/(.*?)\.php#i',
   | $_SERVER['HTTP_REFERER'])) ? $_SERVER['HTTP_REFERER'] : 'index.php';
   | [...]
146| <input type="hidden" name="redirect_url" value="
   | <?php echo $redirect_url ?>" />

  This can lead to cross site scripting attacks, for example send this
HTTP packet (with a valid email id):

GET http://localhost/punbb1-2-14/misc.php?email=3 HTTP/1.1\r\n
Host: localhost\r\n
Referer: http://localhost/punbb1-2-14/misc.php?email=3"><script>alert(1)</script>\r\n
Connection: keep-alive\r\n
Cookie: punbb_cookie=<thecookie>\r\n\r\n

  If the attacker knows how to use Ajax, it's quite easy to exploit (with
setRequestHeader). But let's see how this can be used...



-=[ VULN #3 ]

Risk level: High
      Type: Code execution
Conditions: none

    With punBB an XSS can lead to ... php code execution ! We can
use the 'Referer' XSS to lead this attack. There is also another XSS
in the admin pannel . When we add a category (admin_categories.php)
like '<script>alert(1)</script>', the code is executed when we wanna
remove the created category. Now, serious things begin ... The script
"footer.php" contains the following code:

136| $tpl_temp = trim(ob_get_contents());
137| $tpl_main = str_replace('<pun_footer>', $tpl_temp, $tpl_main);
138| ob_end_clean();
   | [...]
143| while (preg_match('#<pun_include "([^/\\\\]*?)">#', $tpl_main, $cur_include))
144| {
145| 	if (!file_exists(PUN_ROOT.'include/user/'.$cur_include[1]))
146| 	    error('[...]');
147| 	
148| 	ob_start();
149| 	include PUN_ROOT.'include/user/'.$cur_include[1];
150| 	$tpl_temp = ob_get_contents();
151| 	$tpl_main = str_replace($cur_include[0], $tpl_temp, $tpl_main);
152|     ob_end_clean();
153| }

  So if the content of the page contains '<pun_include "file.php"', if
the file is situated in 'include/user/', the file will be include. We
can't use \\ or /, but it's not enough protected. With the
"admin_options.php" file, we can change the avatars directory. Let's
change this parameter to "include/user". By now when a user will upload a
file, the file will be uploaded in "include/user". If the user uploads a
fake JPG file (which contains php code) , the file will be situated in
"include/user". Now the attacker have to include the uploaded file. He
will execute the php code with the XSS (<pun_include "my_id.jpg">). An
exploit has been released [4].



-=[ LINKS ]

[1] Warning: ini_get() has been disabled for security reasons
  http://www.google.fr/search?q=warning%3A+ini_get+has+been

[2] ini_get returns values from other vservers
  http://bugs.php.net/bug.php?id=21874

[3] PunBB <= 1.2.13 Multiple Vulnerabilities
  http://wargan.org/index.php/2006/10/29/4-punbb-1213-multiple-vulnerabilities

[4] PunBB <= 1.2.14 Remote Code Execution Exploit
  http://www.acid-root.new.fr/poc/29070411.txt

[5] Related fixes
  http://dev.punbb.org/changeset/933
  http://dev.punbb.org/changeset/934
  http://dev.punbb.org/changeset/937
  http://dev.punbb.org/changeset/938


// Greetz: ddx39, lorenzo, sparah, romano

Powered by blists - more mailing lists