Reflected File Download Attack

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

當你點選了這個連結，你的瀏覽器會提示下載:

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

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

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

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

在這個例子裡，如果我們不對url進行任何修改，開啟後會下載會一個檔案，名字是su：

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

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

1.紅框處，下載的檔名字跟url後面跟的su一樣，這裡我們可以試試能不能透過修改這裡使下載的檔名變成我們想要的。 2.綠框處，cb欄位輸入的內容在返回中出現了，這裡我們可以試試能不能透過修改這裡使檔案的內容變成我們所需的。

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

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

這裡我們開啟這個.bat：

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

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

我們再來看一下資料包，如果我們想要下載一個檔案，遵循正常http協議，那麼他的http頭中要包含 Content-Disposition欄位，並且引數為attachment，這個欄位還有個欄位是filename，也就是說如果想要使用下載功能這個欄位的標準寫法是這樣的：

Content-Disposition:attachment;filename:1.txt

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

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

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

Content-Type: application/json;

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

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

這個微博地址返回的是json的資料，並沒有下載行為，他的返回包是這樣的：

現在我把修改返回裡的content-type欄位為baiduApp/jason:

發現頁面檔案發生了下載行為！

經過接下來的嘗試我們發現，如果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中的例子。效果好壞完全看你的忽悠能力了！！

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