|
|
|
0x00 XML簡介
XML可擴(kuò)展標(biāo)記語言，被設(shè)計用來傳輸和存儲數(shù)據(jù)。其形式多樣
例如：
1.文檔格式(OOXML，ODF,PDF,RSS,DOCX...)
2.圖片格式(SVG,EXIF Headers,...)
3.配置文件(自定義名字，一般是.xml)
4.網(wǎng)絡(luò)協(xié)議(WebDAV,CalDAV，XMLRPC,SOAP,REST,XMPP,SAML,XACML,...)
某些在XML中被設(shè)計出來的特性，比如 XML schemas(遵循XML Schemas 規(guī)范)和documents type definitions(DTDs)都是安全問題來源。縱然被公開的討論了上十年，還是有一大批一大批的軟件死在針對XML的攻擊上。
其實(shí)XML實(shí)體機(jī)制很好理解，可以直接用“轉(zhuǎn)義”來理解：%和&foo從原始意義上來說是一樣的，只是后者是由我們自己來定義任意內(nèi)容。
拿DTD來說，DTD中能聲明實(shí)體來定義變量(或是文字類的宏)，以便在接下來的DTD或者XML文檔中使用。一般實(shí)體在DTD中定義，用來訪問內(nèi)部資源，獲取里面的文字并用來替換自己的xml文檔，而外部實(shí)體用來訪問外部資源(也就是說，這些資源能來自本地計算機(jī)，也可以是遠(yuǎn)程主機(jī))。在解析外部實(shí)體的過程中，XML的分析器可能會使用眾多網(wǎng)絡(luò)協(xié)議和服務(wù)(DNS,FTP,HTTP,SMB等等)這取決于URLs里面被指定成什么。外部實(shí)體用來處理那些實(shí)時更新的文檔是很有用的，然而，攻擊也能在解析外部實(shí)體的過程中發(fā)生。攻擊手段包括：
讀取本地文件(可能包含敏感信息 /etc/shadow)
內(nèi)存侵犯
任意代碼執(zhí)行
拒絕服務(wù)
本文將對長期以來出現(xiàn)的xml攻擊方法進(jìn)行一個總結(jié)。
0x01 初識XML外部實(shí)體攻擊
基于外部實(shí)體的文件包含
最早被提出的XML攻擊方法是利用外部實(shí)體的引用功能來實(shí)現(xiàn)任意文件讀取
]> Joe &file; ...
然而這種讀取是有限制的，因為xml的解析器要求被引用的數(shù)據(jù)是完整的，我們使用一個例子來解釋什么是完整。
]> &first;&second;
如上的xml文檔當(dāng)發(fā)送給服務(wù)器時，實(shí)際上是會產(chǎn)生一個錯誤的 其中雖然在組合在一起時是能夠完美閉合的，但是這些實(shí)體由于在第3，4行就被解析一次，此時由于不是完美閉合的，就會拋出一個錯誤。
這種錯誤讓xml攻擊一度變得雞肋起來，因為實(shí)際上很多文件都是“未閉合形式”的，比如在php文件推薦的寫法中就是只有前面一個"
更糟糕的是，當(dāng)你選擇包含的是一個完整的xml文件(比如數(shù)據(jù)庫連接文件)的時候，返回結(jié)果將是
可以看到，在標(biāo)簽中的數(shù)據(jù)庫配置文檔被嵌入時，大部分內(nèi)容都是省略號，只顯示了文檔的結(jié)構(gòu)。這是由xml parser特性決定的。
URL Invocation
XML攻擊中有一塊常常被忽視，那就是利用URL機(jī)制以及他們的一些奇怪的特性來擴(kuò)大攻擊面。
雖然XML規(guī)范并沒有要求支持任何特定的URL機(jī)制，但許多平臺的底層網(wǎng)絡(luò)庫卻支持了幾乎所有URL機(jī)制。
借助URLs，攻擊者可以讓運(yùn)行著XMLparser的主機(jī)向第三方主機(jī)發(fā)起惡意請求.
比如“server-side request forgery”(ssrf).理論上來說，URL Invocation甚至可以用來發(fā)起內(nèi)部網(wǎng)絡(luò)中的洪水攻擊。
大部分人不知道的是，即使外部實(shí)體被禁用了，許多xml parsers還是會去解析那些URL。舉個例子，一些parsers會在文檔定義階段對url發(fā)起請求
這不是實(shí)體攻擊!
除了外部實(shí)體和基于DOCTYPE的SSRF攻擊之外，XML Schema提供了兩個在實(shí)例文檔中使用的特殊屬性，用于指出模式文檔的位置。這兩個屬性是：xsi:schemaLocation和xsi:noNamespaceSchemaLocation，前者用于聲明了目標(biāo)名稱空間的模式文檔，后者用于沒有目標(biāo)名稱空間的模式文檔，它們通常在實(shí)例文檔中使用。
在這個案例中，所有帶有secondaryns:前綴的都會遵循在xmlns:secondaryns中定義的機(jī)制。由于DOCTYPE定義不能出現(xiàn)在文檔的中部，所以當(dāng)我們只對文檔某個部分可控的時候，就能利用schema_Location(http://location/of/remote/schema/primary.xsd)發(fā)起ssrf。(前提是一些設(shè)置需要設(shè)置為on，然而我們并沒有對每個xml parser進(jìn)行充分的測試來研究不同環(huán)境下有什么要求能讓我們進(jìn)行ssrf攻擊，所以這也是一個待研究的方向，有興趣的wooyuner可以交流~)
0x02 引入?yún)?shù)實(shí)體后的攻擊手段
當(dāng)我們的惡意xml被成功解析，這時我們有可能面臨兩個問題：
一，數(shù)據(jù)未閉合導(dǎo)致嵌入失敗(比如只存在
二，服務(wù)器進(jìn)行限制導(dǎo)致數(shù)據(jù)不能返回。
引入?yún)?shù)實(shí)體之后，這兩個問題就能得到解決。
參數(shù)實(shí)體以%開頭 我們使用參數(shù)實(shí)體只需要遵循兩條原則：
參數(shù)實(shí)體只能在DTD聲明中使用。 參數(shù)實(shí)體中不能再引用參數(shù)實(shí)體。
CDATA轉(zhuǎn)義的妙用
CDATA部件;在CDATA部件的所有內(nèi)容都會被XML解析器忽略，即CDATA部件里面的內(nèi)容緊緊這是一個字符串文本的作用。一個 CDATA 部件以""標(biāo)記結(jié)束。那么我們能不能構(gòu)造一個這樣的頁面來返回那些文件呢
%dtd; ]> &all;
combine.dtd如下
前面也提到過，當(dāng)xml parsers會把xml的參數(shù)實(shí)體% start % end馬上解釋，由于沒有閉合 就會拋出錯誤，那么這里的%start為何能正常地解析呢? 這是因為參數(shù)實(shí)體的引用不需要在xml文檔解析的時候保持xml閉合，這樣就繞過了限制。
通過這樣我們就能讀取所有數(shù)據(jù)了(base64編碼也可)
外帶數(shù)據(jù)bypass回顯限制
另一種使用參數(shù)實(shí)體的手段就是外帶數(shù)據(jù)了。
利用參數(shù)實(shí)體，我們能夠把需要讀取的文件通過一些協(xié)議(http ftp等)發(fā)送到我們的服務(wù)器上，那么通過日志查看就能獲取數(shù)據(jù)了 我們可以這么構(gòu)造
%dtd;]> &send;
然后在我們可控的http://example.com/
放置如下DTD
%all;
流程如下
Win10最新版官方下載/Win10安裝圖文教程
XXE的奇門遁甲
基于XInclude的文件包含
XInclude提供了一種較為方便的取回數(shù)據(jù)的思路(再也不用擔(dān)心數(shù)據(jù)不完整而導(dǎo)致parser拋出一個錯誤)而我們能夠通過parse屬性，強(qiáng)制引用文件的類型。
不過Xinclude需要手動開啟，測試發(fā)現(xiàn)所有xml parser都默認(rèn)關(guān)閉這一特性。
拒絕服務(wù)
XXE攻擊也能用來發(fā)起拒絕服務(wù)攻擊
如下的遞歸引用，從下至上以指數(shù)形式增多
]> &lol9;
回憶一下解析過程，當(dāng)XML處理器載入這個文檔的時候，它會包含根元素，而里面定義了實(shí)體&lol9 ，而19實(shí)體擴(kuò)展成了包含了“&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;”這個字符串。
如此遞歸上去，壓入內(nèi)存的東西呈指數(shù)增長，實(shí)驗發(fā)現(xiàn)，一個小于1KB的XML攻擊payload能消耗3GB的內(nèi)存。
特定環(huán)境下的攻擊和限制
Java&Xerces
默認(rèn)的Oracles Java Runtime Environment下的XML parser是Xerces，一個apache的項目。而Xerces和Java提供了一系列的特性，這些特性又能導(dǎo)致一些嚴(yán)重的安全問題。上述的那些攻擊手法(DOCTYPEs for SSRF,文件讀取,參數(shù)實(shí)體的外帶數(shù)據(jù))在java的默認(rèn)配置下能夠運(yùn)用自如,java/Xerces也支持XInclude 但是需要setXIncludeAware(true) 和setNamespaceAware(true)。
java規(guī)范能夠支持如下的URL機(jī)制
http
https
ftp
file
jar
令人吃驚的是Java的file協(xié)議能夠用來列目錄，比如說，在linux下面“file:///”會列出/目錄下所有東西：
bin
boot
dev
etc
home
...
jar協(xié)議jar:http://host/application.jar!/file/within/the/zip會導(dǎo)致服務(wù)器首先取得文件然后解壓這個以jar開頭!結(jié)尾的包 并提取后面的文件。從攻擊者的角度看，完全能夠定制一些高壓縮比的包(比如1000：1)這些ZIP炸彈能用來攻擊反病毒系統(tǒng)，或者用來消耗目標(biāo)機(jī)的硬盤/內(nèi)存資源。注意，jar URLs能在任何接受DOCTYPE定義的JAVA Xerces系統(tǒng)上使用。所以，即使外部實(shí)體關(guān)閉了，還是能夠進(jìn)行攻擊。
php&expect的RCE
很遺憾，這個擴(kuò)展并不是默認(rèn)安裝的，然而安裝了這個擴(kuò)展的XXE漏洞，是能夠執(zhí)行任意命令。
]>
&cmd;
那么就會返回如下
uid=501(Apple) gid=20(staff) groups=20(staff),501(access_bpf),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),
98(_lpadmin),401(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),
398(com.apple.access_screensharing),399(com.apple.access_ssh)
xml注入
這個和xxe攻擊關(guān)系并不大，但是本文討論的是XML安全，所以這個自然也就收錄進(jìn)來
$GLOBALS["HTTP_RAW_POST_DATA"]在php中被設(shè)置成了“不轉(zhuǎn)義”，一旦程序通過實(shí)體獲取數(shù)據(jù)后，直接帶入了Mysql最后造成注入
案例如下
WooYun: PHPYUN最新版XML注入及SQL注入獲取管理員賬號(無視任何防御)
0x03 總結(jié)
XXE攻擊總在被忽視
開發(fā)者往往說：
攻擊威脅小..
關(guān)閉實(shí)體就能完全避免...
XML實(shí)體攻擊是啥?
然而，xml實(shí)體攻擊再上述的攻擊中已然產(chǎn)生了很多出乎開發(fā)者意料的威脅。
|
|
發(fā)表留言請先登錄！
|