DNS泛解析與內容投毒，XSS漏洞以及證書驗證的那些事

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不是這麼認為的：

舉個例子，下面的URL：

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

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

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

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

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

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

如果我使用

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

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

[email protected]

[email protected]後面的字元，會把它轉發到原始的賬戶中。

在這個例子當中，Facebook傳送的所有確認的email有汙染過的連線：

這也可以用來攻擊密碼重置電子郵件，但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時，上傳一個檔案到一個資料夾，並嘗試壓縮/下載它，會要求電子郵件確認，電子郵件的確認訊息是這樣的：

“ready for downloading”連結指向

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

到目前為止，沒有什麼大不了的，我仍然無法偽造該連結...釣魚自己也是沒有多大用處= ）

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

出於某種原因，他們的DNS伺服器有這樣的小問題，更具體地說在剝離了正規表示式“--”的字首。我不知道他們為什麼進行這些檢查，但可能有些事情與國際化域名相關。

受此問題影響的一些谷歌的域名（ 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

會發生什麼？

請求傳送到合法的網站：

請求轉向到使用者可控的網站中，這個例子當中，我自己的伺服器執行著nginx：

這可以導致xss，你已經繞過了同源策略，可以偷取cookie，執行指令碼了。

0x03 Certificate Pinning 和 Wildcard DNS

---

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

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

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

你可以在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”的選項。

值得注意的是,根據 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 這樣斯諾登洩漏你的檔案時，我們就可以更好地跟蹤他們了。