由追蹤溯源發現的不安全解壓縮GetShell實例分析

最近我們幫助某客戶追蹤溯源一例入侵事件時，發現駭客在取得伺服器權限之前利用網站的「ZIP 解壓縮功能」上傳了 Webshel​​l。由於這次的漏送利用方式在「攻擊載荷的構造」與「實際解壓路徑」方面較有代表性，業界對「不安全解壓」漏洞的關注度仍不夠。因此我們編寫了這篇報告，在報告中講解了入侵溯源與漏洞發現的過程，並從安全開發和安全狗產品防護方案兩個維度提出了一些安全建議，希望對行業有所補益。

值得注意的是，雖然該 CMS 已經做了相關防禦配置，若在 CMS 的根目錄下直接寫入 JSP 檔案是無法執行的，會報 403 錯誤。攻擊者利用了 war 套件會自動部署的特點，透過「目錄穿越」的思維使 war 套件跳出該 CMS 的根目錄。

一、入侵溯源

某公司維運人員在深夜值班時發現系統有一定異常，為了盡**查問題，客戶聯絡了我司，海青實驗室隨後介入，進行溯源和分析，並提供後續的處置方案。

透過查看Tomcat 的日誌檔案/logs/localhost_access_log.yyyy-MM-dd.txt可以發現，查看日誌可以發現，攻擊者曾經對網站的登入介面實施了爆破（對「POST /cmscp/ login.do”介面的存取頻率很高），如圖所示。

附註：爆破成功時的 HTTP 狀態碼是 302，而爆破失敗時的 HTTP 狀態碼是 303。

為了判斷攻擊者是否上傳網站木馬，使用網站安全狗的Webshel​​l AI 偵測引擎對Tomcat 的webapps 目錄進行掃描，可發現名為「/admin/login.jsp」的檔案被辨識為Webshel​​l （駭客對這Webshel​​l 的命名具有一定的迷惑性），如圖所示。

經過進一步手動確認，可判斷該 jsp 檔案確為 Webshel​​l。並且它與 admin.war 這一文件的自動部署有關，如圖所示。

那麼這 war 套件是如何被上傳到伺服器的呢？繼續對日誌檔案進行分析，在分析的時候專注於「可能為檔案上傳功能的介面」。可以初步判斷，駭客曾在使用該 Webshel​​l 之前使用ZIP 上傳和ZIP 解壓縮功能，如圖所示。

找到伺服器上被文件解壓縮介面呼叫的test5.zip 文件，對之進行分析可以發現admin.war 所處的路徑是「test5.zip\.. \..\..」。因而，該 ZIP 檔案是駭客精心建構的惡意文件，它將使得該 war 套件的解壓縮路徑不再是預設的「/uploads/1」目錄，而是 Tomcat 的「webapps」目錄，如圖所示。

註：本文的惡意zip 檔案的產生方式

#（1）執行下列python 腳本，產生test5.zip：

import zipfile if __name__ == "__main__": try:binary = b'<script>alert("helloworld")</script>'zipFile = zipfile.ZipFile("test5.zip", "a", zipfile.ZIP_DEFLATED) info = zipfile.ZipInfo("test5.zip")zipFile.writestr("../../../safedog.html", binary)zipFile.close()except IOError as e: raise e

（2）將包含有Webshel​​l 的war 套件拖曳到“test5.zip”，如圖所示。

二、程式碼審計

經過前面的入侵溯源分析可以初步斷定，這次攻擊與該CMS 的「ZIP解壓縮介面」（GET /cmscp/core/web_file_2/unzip.do?ids={ids}&parentId={parentId}）密切相關。此介面對應了 WebFileUploadsController.java 的 unzip 方法，如圖所示。

對 unzip 方法進行跟進，發現它的具體實作在 WebFileControllerAbstractor.java 中。可以發現，在對 zip 檔案進行解壓縮的時候，呼叫了 AntZipUtil 類別的 unzip 方法，如圖所示。

對AntZipUtil 類別的unzip 方法進行跟進，可發現該方法未對ZIP 壓縮套件裡的檔案名稱進行參數校驗 #，就進行檔案的寫入。這樣的程式碼寫法會引發目錄穿越漏洞，如圖所示。

目前，海青實驗室已將漏洞提交 CNVD，並通知廠商進行修復。

三、總結

透過這則實例可以發現，解壓縮功能的安全性可能對網站安全性造成較大危害（以Spring Integration Zip 開發元件為例，它也曾被爆出CVE-2018-1261 這一「不安全解壓縮漏洞」）。若網站的業務涉及了解壓功能，建議更加重視安全開發的維度，除此以外安全狗也提供了相應的產品防禦方案。

在安全開發方面，建議研發人員在實現解壓縮演算法時，從以下幾個方面進行自查與限制：

（1）是否限制壓縮包內文件的副檔名

例如：.war、.jsp、jspx、.jsp::$DATA（只影響Windows 主機）

（2）是否限制壓縮套件內檔案的實際解壓縮路徑

（3）是否限制壓縮套件內檔案的總大小（以防壓縮套件**引發的拒絕服務攻擊）

（4）是否賦予Web 應用程式目錄合理的權限

此外，我們也建議用戶選擇可靠專業的安全產品，例如安裝了安全狗產品的用戶，一旦發生安全事件，將會自動收到系統發出的告警短信，以盡快介入處置，避免產生更大的損失。

在「安全狗產品防禦」方面，建議使用者使用「網站安全狗」和「雲禦」的網站後台防護以及伺服器狗的檔案目錄守護功能，雲禦和網站安全狗的網頁後台路徑保護功能可以實現對網站後台暴破行為的防護。

雲禦後台防護功能如圖所示:

網站安全狗後台防護功能如圖所示：

#伺服器資料夾目錄守護功能：

#  

以上是由追蹤溯源發現的不安全解壓縮GetShell實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！