Flash 0day特征帶來的攻擊思路雜談

平時工作過于忙碌，技術(shù)的敏感度稍顯滯后，好在隱隱感覺黑哥與小熊在群里提到的Flash 0day特性（CVE-2014-4671）具備非常大的價值，于是保存了筆記，晚上抽空斷斷續(xù)續(xù)研究了下，才意識到這個0day的價值。

原文鏈接：
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/

烏云昨天出了個翻譯：
http://drops.wooyun.org/tips/2554

    大家可以先對照著讀讀，理解這個0day需要一些背景知識：
    1. 了解Flash在前端安全的地位，關(guān)于這點(diǎn)毫不避諱地推薦閱讀我們這本書《Web前端黑客技術(shù)揭秘》第二章關(guān)于Flash安全的描述，內(nèi)容很全面清晰；
    2. 了解CSRF攻擊的本質(zhì)，同樣我們的書也提了；
    3. 了解JSONP，隨便百度下你就知道；

這次Flash 0day特性實(shí)際上是對Flash文件格式的一次Hack（CWS壓縮，采用的是zlib里的DEFLATE壓縮算法），這種Hack的具體實(shí)現(xiàn)我沒仔細(xì)理解，Hack之后的結(jié)果是Flash文件可以用ASCII碼來完全表示（且是純字母數(shù)字），這個會導(dǎo)致什么后果呢？

我慢慢道來：

1.

曾經(jīng)我們玩瀏覽器解析Hack時都明白一個道理，如何讓瀏覽器錯誤識別文件格式，即MIME類型，比如根據(jù)文件名后綴、Content-Type響應(yīng)頭、文件內(nèi)容等。

題外話：這種判斷規(guī)則在不同瀏覽器的實(shí)現(xiàn)還存在一些差異，這種差異導(dǎo)致有的瀏覽器可以被攻擊成功，而有的不行。

曾經(jīng)著名的UTF-7 XSS就是瀏覽器根據(jù)文件內(nèi)容的頭幾個字符來判斷目標(biāo)文件的編碼方式，比如開頭是：

    +/v8
    +/v9
    +/v+
    +/v/

這個簡單的缺陷導(dǎo)致全球重要網(wǎng)站紛紛中招。

2.

通過這個Flash 0day特性，結(jié)合JSONP接口，就可以把Flash文件內(nèi)容（純字母數(shù)字）附加到JSONP的返回結(jié)果中（通過給JSONP的callback參數(shù)賦值），為了按照Flash格式正常解析，文件頭必須是嚴(yán)格的Flash文件內(nèi)容。如果沒這個Flash 0day特性，傳給JSONP的內(nèi)容就很可能包含各種特殊字符，就很可能會被JSONP的防御機(jī)制給過濾掉，就好像2012年這位大牛給出的POC：

    http://50.56.33.56/blog/?p=242

當(dāng)時是沒利用這個Flash 0day特性的，當(dāng)然如果JSONP沒什么防御，不要這個特性也行�？上У氖钦�是因?yàn)檫@個特性的利用，Google、Facebook等都淪陷了……因?yàn)樗鼈兊腏SONP防御機(jī)制允許純字母數(shù)字的字符串出現(xiàn)。

通過這兩點(diǎn)的說明，大家明白了嗎？

防御方式可以好幾種，最Nice的是：

    在JSONP callback回來的內(nèi)容之前強(qiáng)制加上/**/，這是JavaScript注釋符，應(yīng)該不會影響正常是JSON格式的解析執(zhí)行，同時又可以避免根據(jù)文件頭幾個字符來決定目標(biāo)文件MIME類型的解析機(jī)制。

曾經(jīng)UTF-7 XSS漏洞也采用了類似的防御機(jī)制，在返回的內(nèi)容前面強(qiáng)制加上個空格，這個道理是一樣的：）

可惜Flash修補(bǔ)了這個0day特性，否則這種攻擊很快會流行起來。這是一種非常經(jīng)典的跨域攻擊，我沒來得及Demo，誰有結(jié)果可以告知我一聲。

本雜談比較亂，要想理解透徹，靠大家自己啃了。

最后，為什么說是0day特性，而不說是漏洞，這又是個很長的話題了……