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

這篇文章將為大家詳細講解有關由追蹤溯源發現的不安全解壓GetShell實例分析，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

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

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

一、入侵溯源

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

通過查看 Tomcat 的日志文件/logs/localhost_access_log.yyyy-MM-dd.txt可以發現，查看日志可以發現，攻擊者曾經對網站的登錄接口實施了爆破（對「POST /cmscp/login.do」接口的訪問頻率很高），如圖所示。

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

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

經過進一步人工確認，可判斷該 jsp 文件確為 Webshell。并且它與 admin.war 這一文件的自動部署有關，如圖所示。

那么這一 war 包是如何被上傳到服務器的呢？繼續對日志文件進行分析，在分析的時候重點關注「可能為文件上傳功能的接口」。可以初步判斷，黑客曾在使用該 Webshell 之前使用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）將包含有 Webshell 的 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實例分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。