3771

0x00 背景

前幾天Blackhat上,有一個有意思的議題,《Reflected File Download,A New Web Attack Vector》,瞬間覺得高大上,就拿來膜拜了一下,經過膜拜發現不知道是我不能完全理解還是什么原因,總是覺得這種攻擊方式略微雞肋.我簡單的把膜拜的過程記錄下發出來,讓各路基友幫忙看看,到底該用什么姿勢去膜拜才是正確的.

Reflected-File-Download-Attack,我覺得可以翻譯成"反射型文件下載",感覺跟反射型Xss類似,在Hafif的PPT里是這樣描述的: “用戶點擊一個來自google.com的鏈接，會下載一個惡意的文件，一旦用戶點了這個文件，這個文件就立即運行，windows的計算器就彈出來了（PPT第17頁）”“Uploadless Downloads!(P18)”

由于那個漏洞google.com修復了，這里我找了一個百度的有類似風險的鏈接，來膜(實)拜(驗)。

0x01 細節

首先看實驗，然后在詳細說原理：如果你的瀏覽器是chrome，那么使用這個鏈接：

http://suggestion.baidu.com/su;/1.bat;?wd=&cb=calc||&sid=1440_2031_1945_1788&t=1362056239875

如果你的瀏覽器不是chrome，那么使用這個鏈接：

http://suggestion.baidu.com/su;/1.bat?wd=&cb=calc||&sid=1440_2031_1945_1788&t=1362056239875

當你點擊了這個鏈接，你的瀏覽器會提示下載:

enter image description here

細心的童鞋在url中就已經發現了，內容都寫在url里了，很顯然如果你運行了，就會彈出計算器：

enter image description here

當然，肯定會有童鞋說，你以為我是SB嗎，我才不會去點他呢。。（遇到這問題我竟無言以對，確實雞肋）

這個議題的演講人在PPT里面有一段大概這樣意思的描述：我們是如何去相信我們的下載呢？(P20)

我覺得這個漏洞的最大價值也就在于普通用戶去分辨是否惡意下載是靠各種瀏覽器地址框的綠色證書標識，是靠HOST,注意這里說的是普！通！用！戶！

在這個例子里，如果我們不對url進行任何修改，打開后會下載會一個文件，名字是su：

http://suggestion.baidu.com/su?wd=&cb=window.bdsug.sugPreRequest&sid=1466&t=1362316450913

enter image description here

從圖中我們可以看出兩個對我們有用的地方：

1.紅框處，下載的文件名字跟url后面跟的su一樣，這里我們可以試試能不能通過修改這里使下載的文件名變成我們想要的。 2.綠框處，cb字段輸入的內容在返回中出現了，這里我們可以試試能不能通過修改這里使文件的內容變成我們所需的。

通過實驗，得到下面這個能夠執行命令的url：

http://suggestion.baidu.com/su;/1.bat;?wd=&cb=calc||&sid=1440_2031_1945_1788&t=1362056239875

這里我們打開這個.bat：

enter image description here

這段字符串用被管道符隔成了兩段命令，第一段是彈計算器，第二段是無效命令。這個例子沒有Hafif的PPT里的那個例子好，如果在我們能控制的輸入位前面還有一些字符串,我們仍然可以使用管道符分隔開兩段字符串。例如:

{"results":["q", "rfd\"|| calc|| ","I loverfd"]}

我們再來看一下數據包，如果我們想要下載一個文件，遵循正常http協議，那么他的http頭中要包含 Content-Disposition字段，并且參數為attachment，這個字段還有個字段是filename，也就是說如果想要使用下載功能這個字段的標準寫法是這樣的：

Content-Disposition:attachment;filename:1.txt

但是google產生漏洞的這個位置并沒有加filename參數。按理來說百度這個地方的安全風險也應該是這樣產生的，但是在實際測試中我們發現，并不是這樣的。先看一下百度的返回包：

enter image description here

雖然沒有那個強制下載的字段Content-Disposition，但是我們仍然成功下載了，這里就產生了一個問題。。。

在后面的測試中我們發現，是因為content-type字段的內容造成的，按照http協議，content-type的json返回包的正常寫法是這樣的：

Content-Type: application/json;

為了驗證是哪里的問題，我們繼續嘗試：

http://weibo.com/aj/top/topnavthird?_t=1&_v=WBWidget.cssVersionCallback

這個微博地址返回的是json的數據，并沒有下載行為，他的返回包是這樣的：

enter image description here

現在我把修改返回里的content-type字段為baiduApp/jason:

enter image description here

發現頁面文件發生了下載行為！

enter image description here

經過接下來的嘗試我們發現，如果content-type不符合http協議，也就是說不是標準的application/json寫法，而是baiduAPP/json或者xxxx/json,甚至Fuck/json，都會使頁面產生下載行為！

(我也不能完全確定是不是不符合HTTP協議，各路基友求證實)

這樣這個漏洞形成的原因就很簡明了，要符合幾個條件：

1.在返回中能看到我們的輸入并且content-type的類型不是普通類型，json或者jsonp等等。。。

2.url沒有過濾或轉義‘/’‘;’

3.是下載類型。使用不完整的Content-Disposition:attachment或者是不符合http協議的content-type。

原理上基本就這樣了，至于利用上這的確是有一定的雞肋，不過類似反射型XSS，如果在社交網絡中使用，效果還是很不錯的，例子我就不舉了，這里貼個Hafif在PPT中的例子。效果好壞完全看你的忽悠能力了！！

enter image description here

PPT里面還有關于如何修復，這里我就不說了，感興趣的童鞋可以去看看，附上PPT下載地址：http://dakrsn0w.sectree.cn/RFD.pdf

97av