<span id="7ztzv"></span>
<sub id="7ztzv"></sub>

<span id="7ztzv"></span><form id="7ztzv"></form>

<span id="7ztzv"></span>

        <address id="7ztzv"></address>

            原文地址:http://drops.wooyun.org/tips/1354

            from:http://w00tsec.blogspot.com/2014/03/wilcard-dns-content-poisoning-xss-and.html

            0x00 背景


            今天來討論一下之前幾個月我上報給Google和Facebook的一個有趣的漏洞,我在去年十月份利用一些空閑的時間在幾家懸賞漏洞的公司當中測試,這個bug Google獎勵了我5000美元,Facebook獎勵了我500美元。

            我知道你可能非常關心是如何做到上傳任意文件的,文件包含的payload可能會導致預料之外的行為例如關閉白名單,希望這類bug已經已經被Fyodor修復

            (經/fd提醒:這里其實想要諷刺全披露安全社區關閉的事件事源一個叫尼古拉Lemonias的人提交了一個很無聊的「任意文件上傳漏洞」使約翰·卡特賴特(FD的管理員)無法忍受而關閉服務)

            標題可能會有點混亂,但我將要把這些技術結合起來,將會形成漏洞。

            0x01 Wilcard DNS 和 Content Poisoning


            應用程序從HTTP Host頭與domain name中不驗證產生完整的 URL 會造成主機名中毒。近日,Django框架修復了一些漏洞,與James Kettle發表的host header攻擊相關。

            在測試這個問題時,我發現了一個不一樣的主機頭攻擊方式,可能會繞過瀏覽器的通配符。

            我們快速瀏覽一下關于Hostnames的維基百科條目:

            “互聯網標準(RFC)的協議,授權該組件的主機名稱標簽可能只包含ASCII字母'a '到'z ' (不區分大小寫),數字'0'到'9',而連字符( “ - ” )在RFC 952主機名的原始規范,規定了不能以數字或連字符開始,并且不能以連字符結尾,然而,隨后的規范(RFC 1123)允許以數字開頭的主機名稱。不能有其他符號,點與空格是允許的。 “

            最有趣的部分在這里:從Windows,Linux和Mac OS X當中認為

            -www.plus.google.com
            www-.plus.google.com
            www.-.plus.google.com
            

            是有效的。但是Android不是這么認為的:

            enter image description here

            enter image description here

            舉個例子,下面的URL:

            https://www.example.com.-.www.sites.google.com
            

            如果我們在郵件當中寫如上URL,Gmail會分割他,收到的郵件將含有兩個部分:

            https://www.example.com
            sites.google.com
            

            enter image description here

            Facebook在zero.facebook.com域名下有一個泛解析。為了利用這個漏洞,我們有使用中毒的URL來瀏覽服務,并執行可能需要電子郵件確認動作,檢查Facebook是否會把精心構造URL的電子郵件發送給用戶。

            enter image description here

            我發現這個問題產生的唯一漏洞就是注冊郵件確認流程中,你可能會問一個人如何利用這個來攻擊一個正常的用戶呢?

            假設我想利用[email protected]攻擊Facebook帳戶。

            如果我使用

            https://www.example.com.-.zero.facebook.com
            

            瀏覽Facebook,我所需要做的就是創建兩個賬戶

            [email protected]
            

            [email protected]?后面的字符,會把它轉發到原始的賬戶中。

            在這個例子當中,Facebook發送的所有確認的email有污染過的連接:

            enter image description here

            這也可以用來攻擊密碼重置電子郵件,但Facebook并沒有受到影響。他們很快通過編碼修復了電子郵件確認系統。它也可以(但不推薦)通過相對鏈接,而不是完整的URL (請點擊這里,而不是一個具體的URL www.example.com.-.zero.facebook.com) 。

            0x02 XSS和Wildcard DNS


            在Google上尋找此類問題的時候,我很快就發現了泛解析的域名,如:

            - https://w00t.drive.google.com
            - https://w00t.script.google.com
            - https://w00t.sites.google.com
            

            如果你想知道如何快速地找到這些泛解析的域名,你可以下載scans.io從中尋找。你可以找到有關反向DNS記錄或通過搜索發給通配符域的SSL證書,如

            *.sites.google.com
            

            剛開始測試時,在drive.google.com域內我無法在URL當中使用.-.(得到500錯誤消息)

            我能創造的URL是這樣的:

            https://www.example.com-----www.drive.google.com
            

            當你使用那個URL使用Google Drive時,上傳一個文件到一個文件夾,并嘗試壓縮/下載它,會要求電子郵件確認,電子郵件的確認消息是這樣的:

            enter image description here

            “ready for downloading”鏈接指向

            https://www.example.com-----www.drive.google.com/export-result?archiveId=REDACTED
            

            到目前為止,沒有什么大不了的,我仍然無法偽造該鏈接...釣魚自己也是沒有多大用處= )

            我不停地測試不同的URL ,直到我發現了一個谷歌DNS服務器怪異的行為。當輸入的URL中包含一定數量的“-”之后,解析的IP地址將會是你前面所可控部分域名的IP地址:

            enter image description here

            出于某種原因,他們的DNS服務器有這樣的小問題,更具體地說在剝離了正則表達式“--”的前綴。我不知道他們為什么進行這些檢查,但可能有些事情與國際化域名相關。

            enter image description here

            受此問題影響的一些谷歌的域名( 2013年10月) :

            - docs.google.com
            - docs.sandbox.google.com
            - drive.google.com
            - drive.sandbox.google.com
            - glass.ext.google.com
            - prom-qa.sandbox.google.com
            - prom-test.sandbox.google.com
            - sandbox.google.com
            - script.google.com
            - script.sandbox.google.com
            - sites.google.com
            - sites.sandbox.google.com
            

            現在,我可以冒充谷歌的域名,很可能繞過同源策略,

            濫用代表一個登錄用戶的同源策略和發出請求。 lcamtuf已經告訴我們HTTP cookies, or how not to design protocols

            如果我們控制

            www.example.com
            

            從drive.google.com登錄用戶然后訪問URL

            http://www.example.com---.drive.google.com
            

            會發生什么?

            請求發送到合法的網站:

            enter image description here

            請求轉向到用戶可控的網站中,這個例子當中,我自己的服務器運行著nginx:

            enter image description here

            這可以導致xss,你已經繞過了同源策略,可以偷取cookie,執行腳本了。

            0x03 Certificate Pinning 和 Wildcard DNS


            到目前為止,一切都很好,但如果我們在Google Chrome當中做同樣的測試,它會強制執行證書驗證碼?

            我一開始沒有注意,但我無意中也發現了Chrome瀏覽器的問題:這些非RFC兼容的域他并不能做HSTS檢查。

            網絡堆棧的其他部分進行了處理,并提取從這些“無效”的DNS名稱的結果,但TransportSecurityState否決了,因此HSTS政策并不適用。他們只是刪除了完整性檢查,這使TransportSecurityState的過程更加復雜。

            enter image description here

            enter image description here

            你可以在Chrome V31版本之前容易重現此問題:通過OWASP ZAP代理鉻(接受其證書),請訪問網址

            https://sites.google.com
            

            Chrome會顯示一個“heightened security”的錯誤消息。

            如果你輸入鍵入的URL為:

            https://www-.sites.google.com
            

            https://www-.plus.google.com
            

            Chrome瀏覽器提供了“Proceed anyway”的選項。

            enter image description here

            enter image description here

            值得注意的是,根據 RFC 2818 當你在你的網站上使用通配證書(wildcard certificate)的時候,比如.google.com,通配證書只在單層域名可用,比如如果你把匹配.google.com的證書放到abc.def.google.com上,瀏覽器會提示證書錯誤。

            Chrome瀏覽器中鎖定的證書(pinned certificates)可以在這里找到:

            https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

            在我分析的過程中,我發現在使用SSL的397個域名里的55個都在他們的DNS中有泛解析。一個國家級大黑客,如果獲得了任意一個可信CA簽發的證書都可以用這種方法對存在泛解析的域名使用中間人攻擊, 注入數據包等等,繞過HSTS規則并且偷得cookie。

            Google沒把這個bug發CVE,但是幾周后他們悄悄的修復了。Chrome 32和 33以上的版本不會受此影響。

            在Apple還在為Goto fail的問題糾結的時候,如果你圍觀了Chromium的tracker和內部交流和測試等等,你會發現這個洞就是在那個時候補的。

            0x04 結論


            Google和Facebook的安全團隊處理的都很好。這個bug是非常好玩的,它與OWASP的Top 10的內容都不相同。

            這個bug需要一個新的名詞,有人愿意稱這些攻擊將命名為 Advanced Persistent Cross Site Wildcard Domain Header Poisoning (或簡稱APCSWDHP ) 。

            如果你來自NSA,并希望使用此技術來植入我們的DNS,請使用代號 CRAZY KOALA 這樣斯諾登泄漏你的文件時,我們就可以更好地跟蹤他們了。

            <span id="7ztzv"></span>
            <sub id="7ztzv"></sub>

            <span id="7ztzv"></span><form id="7ztzv"></form>

            <span id="7ztzv"></span>

                  <address id="7ztzv"></address>

                      亚洲欧美在线