挖洞經驗 | 一個價值$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美金。