之前，我从没参加过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链接对应的页面：
https://github.com/apps/:app_name/installations/new/permissions?target_id=:id
其间，看到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官方安全团队作了上报，当然我也在陈述中作了补白，期望之后能有更多深化发现。

[1] [2]  黑客接单网