挖洞經驗 | 一個價值$3133.7美金的Google漏洞
在對Google的安全研究中，由於其雲服務平臺“cloud.google.com” 具備多種功能，感覺有點意思，所以某天我決定來深入測試一下它。
測試開始
測試一開始，我就在Burp Proxy中發現了以下這個有趣的連結請求：
ofollow,noindex" target="_blank">https://cloudusersettings-pa.clients6.google.com/batch?%24ct=multipart%2Fmixed%3B%20boundary%3Dbatch392541909285510985
該請求的原始響應訊息是一個JSON格式的404 NOT FOUND。但這裡的請求內容引起了我的注意，首先是，和請求的頭訊息一起，GET請求也被包含在了這個POST請求中；另外是，可以通過主請求URL中的值來對content-type進行控制；還有，可以注意到，在POST請求的傳送內容中，包含了一個key值。
思路考慮
我的想法是：
該請求執行過程，伺服器“cloudusersettings-pa.clients6.google.com” 通過POST請求內容，把GET請求中繼轉發給了一箇中間伺服器，這個中間伺服器可以是一個反向代理或負載均衡器，然後，這個中間伺服器會以某種方式來解析這個GET請求，之後再對其進行處理或將其轉發給另一個伺服器。中間伺服器並不關心原始POST請求的header頭資訊，它只解析包含在POST請求中的GET請求header頭資訊。
總結起來可以概括為以下幾點：
1.我可以控制中間伺服器將要處理的header頭資訊；
2.可以通過以下連結中的multipart%2Fmixed%3B%20boundary%3Dbatch392541909285510985來控制響應內容型別：
3.在請求內容中包含了一個key和授權頭值（authorization header value）
各種測試
為了實現我的這種猜測，我進行了一系列的測試驗證，上述第2和第3種情況是行不通的，但我發現其中的訊息是無驗證機制的（validated），只有第1種情況是可以實現。為了實現對POST請求內容中的GET請求進行測試，我大概實驗的方法如下：
1.在HOST主機頭中嘗試做一些虛擬主機名列舉，如dev、localhost、portal等都來一遍，借希望從一些曝露的webserver中發現本地的虛擬主機名配置資訊，以此能得到內容網路環境的些許線索。（嘗試過後，這種方法行不通）
2.通過把我的IP地址用以下方式偽裝，欺騙Google後端伺服器，試圖讓其給出響應。（但最終，這種方法也行不通）
X-Forwarded-For: 127.0.0.1 X-Client-IP: 127.0.0.1 Client-IP: 127.0.0.1
3.促使Google後端伺服器發生錯誤，比如，向其傳送大量的AAAAA等垃圾訊息等，或是把HTTP協議版本1.1更改為其它、向傳送訊息中新增隨意的header資訊、操縱利用現有的content-type型別等。（最終，這種方法還是行不通）
4.看看userAgent值中是否會出現Blind XSS或SQLI漏洞，如果有，那就太好了！（最終，這種方法還是行不通）
5.我也嘗試了對 origin header 頭進行操縱，希望能從中發現CORS跨資源共享的某些錯誤配置資訊，但是人家的origin有著很好的安全驗證。
突出一計
到了這個地步，完全沒有思路了，直到我想到了：為什麼不直接和Google後端伺服器，以一種它可以理解的方式進行“對話”呢？！這些Web伺服器的交流語言就是請求的header頭資訊啊，它們只要看到header頭資訊，就會解析它，再然後處理它！是不是呢？
我想，能和Web伺服器“對話”的一種header頭資訊就是“X-HTTP-Method-Override”了，該頭資訊可以實現一些奇妙的東西，比如，你可以向伺服器端傳送GET請求，然後伺服器會按照你在其中宣告的PUT、POST和DELETE方法來執行相應處理！是的，儘管它是一個GET請求中，但這種方法也行！就像下面這樣的：
GET /test.php HTTP/1.1 Host: google.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 X-HTTP-Method-Override: PUT Accept-Encoding: gzip, deflate Connection: close
一旦伺服器端接收到了上述GET請求之後，會對其進行解析，然後會發現其中包含了一個方法為PUT的X-HTTP-Method-Override屬性，這樣一來，伺服器端會有以下反應：
“這是一個GET請求，但是使用者希望我把它當成PUT命令來執行，我知道了！”，就這樣，這個GET請求就被伺服器當成PUT方法來處理了。
X-HTTP-Method-Override屬性的這種操作存在原因在於，一些中間伺服器在其支援的HTTP方法中受到限制，如只支援GET和POST，但是，開發人員有時間會用到比如“PATCH, DELETE, PUT”的方法，所以，X-HTTP-Method-Override屬性就可以用上了。
哦，我曾經在F5 WAF流量監控環境，在後端伺服器啟用了webdav服務的情況下，通過HTTP PUT方法觸發了某個RCE漏洞，大概思路如下：
我的Burp repeater —-> Web伺服器你好，我希望通過PUT方法來讓你建立一個檔案 —-> F5 WAF說: 這樣的話你得先過了我這關，而且我只支援 GET和POST方法 —-> 沒戲!
我的Burp repeater —-> F5 WAF你好，我知道後端伺服器支援PUT方法，我在發起的GET請求中把X-HTTP-Method-Override屬性更改為了PUT，請你把它傳遞給後端伺服器吧 —-> F5 WAF說: 哦，好吧，聽起來好像是合法的了！ —-> 後端伺服器: 啊, 又來了一個要處理的PUT請求，因為我支援PUT方法，我懂你的需求，所以，你的檔案可以成功建立 —-> 成功了!
測試利用
也就是說，在上述環境中，在後端伺服器啟用了webdav服務的情況下，我通過把X-HTTP-Method-Override屬性更改為PUT方法，由此觸發了一個RCE漏洞執行。那麼，這種方法在這裡可行嗎？？我滿懷喜悅的測試了一把，NO，沒有RCE，但卻有了一些意外的發現！
由於中間伺服器不知道如何解析處理我設定的header資訊，所以它丟擲了一大堆錯誤訊息來，但在這些訊息中卻包含了很多伺服器的內部配置訊息和敏感資料，如：
HTTPOnly 和 Secure cookies；
包括SSL握手互動、IP地址、埠等在內的，中間伺服器與後端伺服器之間的所有交流資訊；
一些授權頭資訊和其它敏感資料。
總結
還記得之前我提到的第2和第3種情況中訊息無驗證機制的話嗎，基於此，可以構造出一種CSRF攻擊來針對Google使用者，進行反射型XSS情況下的資訊竊取。理論上來講，在XSS攻擊場景下，HTTPOnly cookies是相對安全的，但是利用這個漏洞，有可能從被騙點選惡意連結的Google使用者那裡竊取到HTTPOnly cookies。而且，這種攻擊只有在更改X-HTTP-Method-Override屬性方法的前提下來實現。
我把這個漏洞上報給Google之後，其安全團隊把該漏洞分類為重要的P1級別，並迅速著手修復，之後，我也很快地收到了Google官方獎勵的3133.7美金。
