加密Webshell“冰蠍” 流量 100%識別

• 0x01 "冰蠍" 獲取密鑰過程
  冰蠍執行流程 (圖片來自紅藍對抗——加密Webshell“冰蠍”攻防)
  
  冰蠍在連接webshell的時,會對webshell進行兩次請求訪問
  
  為什么進行兩次訪問? 我在別的文章沒有看到關於這個問題的答案,於是我去反編譯冰蠍源碼
  
  
  
  通過對代碼閱讀,我發現冰蠍為了實現可以在webshell內添加任意內容 (比如gif89a子類的文件頭或者其它標示字符) 冰蠍在初始化密鑰時會對webshell進行兩次訪問,然后比較兩次頁面返回的差異,把兩次請求都相同的字符記錄一個位置,后續加密會用到這兩個位置(beginIndex,endIndex)
  
  
  
  )
  如圖,根據數據包,beginIndex:8 endIndex:4 (含換行),冰蠍開始從數據流中截取被加密的數據從下標8開始到(數據包總長度-4) Waf可以針對於返回類型為 "text/html" 的數據包中加一些空格或者換行,來擾亂冰蠍的數據包,導致冰蠍無法運行 (為什么要對返回類型為 "text/html" 的擾亂,別的格式不可以嗎? 答案:jsp默認返回類型就是 "text/html" html添加一些空格或者換行,並不會影響網頁的正常運行)

• 0x02 "冰蠍" 解析Cookie流程
  
  
  
  我們可以看到請求協議頭中的Cookie字段,冰蠍在合並處理Cookie的時候沒有考慮到,Cookie的一些屬性 (比如 Path 或者 HttpOnly 之類或者其它的) 冰蠍直接把返回協議頭中的Set-Cookie字段直接添加到下一個請求包的Cookie字段中
  
  正常的請求是不會攜帶Cookie屬性的,這可是識別冰蠍流量最直接的一種辦法

• 0x03 "冰蠍" 動態加載
  
  
  冰蠍動態加載的原理就是每次都發送一個class字節碼(其它語言也一樣) 冰蠍通過asm動態修改class字節碼變量內容,實現攜帶參數動態執行,冰蠍在獲取完密鑰之后(2個請求),第三個請求就是獲取BasicInfo(服務器的一些信息),冰蠍的BasicInfo功能並沒有動態修改參數(一個獲取服務器信息的能有啥參數),這會導致每次獲取BasicInfo的數據包都是固定的大小

• 0x04 總結
  Waf可以對一個ip連續訪問2次的數據包進行截取,比對相同字符,比對之后,截取兩次不同的數據,如果剩下的是16位的key,就可以證明這兩個數據包就是冰蠍發出的,第三個數據包通過 0x02,0x03 中的一些bug,可以100%的匹配到冰蠍流量,不會誤報