冰蠍3.0簡要分析

    冰蠍3.0 Beta 2今天發佈，和v2.1相比，最重要的變化就是「去除動態密鑰協商機制，採用預共享密鑰，全程無明文交互，密鑰格式爲md5("admin")[0:16]；」。

    沒有了祕鑰交換過程，在冰蠍v2.1中的明顯的流量特徵「返回內容一定是16位的密鑰」（返回包檢測規則：^[a-fA-F0-9]{16}$）消失，給流量檢測帶來了更大的困難。

    以php版本的shell爲例，默認的祕鑰爲「e45e329feb5d925b」，經過md5("rebeyond")[0:16]獲得，其中「rebeyond」是冰蠍3.0的默認密碼。

    抓包分析冰蠍3.0流量，鏈接後門的第一個post包已是加密流量：

    第一個包主要做用是進行祕鑰key的驗證，根據AES加密算法和預共享key，對抓到的加密請求進行解密：

  

    再對AES解密後的base64編碼內容進行解碼，得到解密後的post數據：

    

    若是服務端返回$content變量"93b5ca86-1a0a-48a6-8929-00528b33cedf"通過加密後的值，則認爲key驗證經過，進行後續流程，以後的通訊全程加密。

    因爲key是攻擊者預置，沒法像2.0版本那樣經過返回包獲取，因此對加密流量沒法解密，須要定位到冰蠍webshell後門才能得到。而冰蠍v3.0版本的webshell免殺也作了增強，webdir和d盾對冰蠍3.0自帶的5個webshell後門的檢出率都只有20%：

    從流量側進行檢測的難度很大，網上有大佬仍是可以根據包的長度特徵、content-type、ua等方式找出一些特徵，但在真實的業務環境中的檢測效果還有待檢測。

    換個思路，流量層的檢測能力也是有上限的，特別是對於加密的流量，單靠流量層的安全設備是不夠的，按照縱深防護的理念，能夠嘗試從應用層、系統層的角度進行檢測。以RASP應用層檢測方案爲例，目前OpenRASP技術仍然能夠很好的檢測到冰蠍3.0的攻擊行爲，防守方能夠嘗試。

    

    

    祝大夥好運。

本文分享自微信公衆號 - 湛盧工做室（xuehao_studio）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。