之前，我從沒參加過GitHub官方的一些漏洞眾測項目，在HackerOne發起的HackTheWorld比賽中，主辦方宣傳除了賞金以外，還有機會獲得Github提供的終身無限制私有庫(unlimited private repositories)使用權，這激發了我的挖洞興趣。經過努力，我發現了Github Organization的一個高危提權漏洞，可以利用 GitHub 應用，實現從Organization成員(Member)到所有者(Owner)的權限提升。最終我也獲得了GitHub官方 $10000美金獎勵。

背景介紹

首先，我們要來了解一下Github 組織( Organization ) 賬號的角色，我在這里著重講一下組織賬號所有者的功能，以及其最小權限設置問題。

GitHub Organization：除了個人帳戶之外，GitHub 還提供被稱為組織(Organizations)的帳戶，組織帳戶代表了一組共同擁有多個項目的人，同時也提供一些工具用于對成員進行分組管理。GitHub推出了組織這一新的賬號管理模式，以滿足大型開發團隊的需要。組織賬號是非登錄賬號，不能像創建普通登錄賬號那樣直接創建，而是需要以GitHub用戶身份登錄，然后再創建自己的組織，創建者成為組織原有的管理者(Owner)。 GitHub Organization適用于商業用途和大型開源項目。Outside collaborator：外部協作者，從完整性和技術角度上來說，該角色不可以創建庫(repository)，但是只對組織內部特定庫有訪問權限。對一個 organization 分組來說，有Members 和 Outside collaborators兩類成員，但不論 member，還是 outside collaborator，都是 collaborator(協作者)。

Member：成員，組織( Organization )分組內權限最低的角色，按照不同的組織設置，有些Member僅只限于對某些子庫具備查看或寫權限。能對特定庫(Repository)大多數設置進行修改的庫(Repository)管理員具備對Member成員訪問權限的分配指定。

Team：團隊，由若干 Member 組成，參與若干庫Repository，Team 是 Organization 內部的管理內容，不對外公開。Member 在一個 Organization 中可以加入多個 Team。

Owner?：組織所有者，通常做法是先注冊一個 user 賬號，在這個賬號下創建一個 Organization，你就是這個 Organization 分組的 Owner。所有者是組織分組內的最高權限管理角色，和管理員相當，該角色可以查看編輯所有組織和庫數據，當然，更嚴重的是，它能不可逆地刪除整個組織分組的所有數據和代碼信息。

在GitHub應用中，組織分組(Organization)功能被廣泛應用，在其通常的訪問控制策略中，只要設置適當(如不分配所有組織庫的管理權限)，分組成員(Member)權限是不會形成安全威脅的。由于在一個組織分組中可以加入多個團隊( Team)，通常的設置模型是把成員(Member)歸類為不同Teams，以此便于成員對不同庫的訪問權限控制。使用這種模型，因為基于Team的權限控制足以在必要時提供權限擴展，所以組織所有者最終面對的只是一些非常小的用戶限分子集。

深入分析 GitHub 應用程序

在以組織所有者身份(Owner)對組織分組功能深入分析過后，我發現了一個“第三方訪問策略”開關，該設置的目的是通過OAuth app應用方式防止組織成員，向不受信任的第三方授予組織分組內存儲庫(Repository)的訪問權限。啟用該功能后，OAuth會跳出一個權限請求提示，然后需要組織所有者批準該請求，成員才能訪問任何組織分組內的數據。

接下來，我要來分析的是一些集成功能(Integration)的app應用，這種集成類app與OAuth app功能類似，只是它們的操作代表的是組織分組，而非像 OAuth app 的用戶。我的想法是去檢查 “第三方訪問策略” 是否也適用于這種集成應用上，或者是就根本沒有這種訪問策略設置。我來到GitHub 開發工具市場Marketplace 頁面，分析了一些簡單應用(app)的安裝過程。結果明顯的是，作為組織成員，只能將集成類app安裝到自己所屬的帳戶中，或者安裝到你擁有的組織分組中。我后來在Github 說明文檔中找到了以下解釋。Organization members can’t request a GitHub App installation.

組織分組成員不能請求安裝GitHub應用程序。

在對集成類app的安裝過程過程中，我注意到，在選擇了 “Billing account”(賬單賬號)之后，會出現一個和以下URL鏈接對應的頁面：

其中，看到target_id，這是不是可以做點文章呢？它可以是 organization_id 或是安裝應用(app)身份的 account_id。理所當然的，我會想到，如果用另外一個組織分組來替換這個組織的安裝過程會是怎樣呢？所以，我以另外一個組織成員(member)的身份，把上述對應URL鏈接中原先組織的 target_id 替換成另外一個組織的 organization_id。由于我在另外組織的成員身份(Member)是庫(Repository)管理員，所以，按照Github說明文檔規定，我只能把集成類app安裝到我自己管理的庫(Repository)中。但當我用當前組織所有者(Organization Owner)身份，查看當前組織內已安裝的Github 應用(Installed GitHub Apps)時，竟然，這個集成類app已經安裝成功！

做完這波測試，此時已是凌晨3點了，這種間接繞過 “第三方訪問策略” 限制的方式肯定會是一個有效漏洞，我一鼓作氣馬上向Github官方安全團隊作了上報，當然我也在報告中作了備注，希望之后能有更多深入發現。

提權測試

第二天，我想是否能再深入對這個漏洞進行一些利用，由此，在創建安裝了GitHub集成類app之后，我發現可以發起的請求權限非常敏感，特別是允許所有組織成員(Member)和團隊(Team)的寫權限。按照Github說明文檔的規定，如果我能對某個我自己的可管理庫(Repository)具備安裝某些集成類app的權限，那么我的身份頂多也就是一個庫管理成員(Member)，當然也不能對組織內其它成員授予寫權限咯，但真實情況是，我可以的！因為Github的預期設計是只有組織所有者才能安裝集成類app，在這種最高權限下，默認組織所有者具備授權權限。像以下安裝app時，會默認具備多種權限：

接下來，我要看看內置相應的API是否能夠正常預期工作而不會發生任何權限錯誤，最終，我可以互相利用一些服務端，在某個角色參數幫助下添加或更新組織成員身份，在此場景下，我還能邀請其它用戶以賬戶所有者身份加入該組織分組。像下圖中，我可用不具備權限的“OrgMember” 賬戶去安裝集成類app，也能通過API以所有者身份邀請 “NewMember”賬戶加入當前組織。

總結

該漏洞可能會被某些組織內的庫管理員利用，但經過調查分析，我發現，所有允許成員創建庫的組織(Organization)都會存在該漏洞，因為這樣一來，創建庫的成員可以通過創建虛擬庫的方式來安裝app，該功能在Github中是默認的，通常來說，由于GitHub支持模型不再與庫綁定，所以大多數組織內的該功能也是啟用的。

另外，該漏洞的利用主體除了組織內成員，還可能是其他入侵掌握了組織成員的惡意攻擊者。假設某組織分組包含300名成員，那么對攻擊者來說，他的攻擊面就非常之大了。

漏洞上報進程2017/11/11?? 凌晨 3:30 漏洞初報

2017/11/11?? 晚上8:30 深入發現提權漏洞

2017/11/13? 早上5:30，GitHub官方分析漏洞

2017/11/14? 下午 1:40，GitHub發放 $10,000 賞金

2017/11/15?? 新版本Github應用中漏洞修復

2017/12/1??? Github徹底修復該漏洞

*參考來源：medium，clouds 編譯，轉載請注明來自 FreeBuf.COM

總結

以上是生活随笔為你收集整理的php挖洞提权,挖洞经验 | 看我如何发现GitHub提权漏洞获得$10000赏金的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。