github-bounty.png

之前,我从没参加过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会跳出一个权限请求提示,然后需要组织所有者批准该请求,成员才能访问任何组织分组内的数据。01.png

接下来,我要来分析的是一些集成功能(Integration)的app应用,这种集成类app与OAuth app功能类似,只是它们的操作代表的是组织分组,而非像 OAuth app 的用户。我的想法是去检查 “第三方访问策略” 是否也适用于这种集成应用上,或者是就根本没有这种访问策略设置。我来到GitHub 开发工具市场 Marketplace 页面,分析了一些简单应用(app)的安装过程。结果明显的是,作为组织成员,只能将集成类app安装到自己所属的帐户中,或者安装到你拥有的组织分组中。我后来在Github 说明文档中找到了以下解释。

Organization members can’t request a GitHub App installation.

组织分组成员不能请求安装GitHub应用程序。

02.png

在对集成类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已经安装成功!03.png

做完这波测试,此时已是凌晨3点了,这种间接绕过 “第三方访问策略” 限制的方式肯定会是一个有效漏洞,我一鼓作气马上向Github官方安全团队作了上报,当然我也在报告中作了备注,希望之后能有更多深入发现。

提权测试

第二天,我想是否能再深入对这个漏洞进行一些利用,由此,在创建安装了GitHub集成类app之后,我发现可以发起的请求权限非常敏感,特别是允许所有组织成员(Member)和团队(Team)的写权限。按照Github说明文档的规定,如果我能对某个我自己的可管理库(Repository)具备安装某些集成类app的权限,那么我的身份顶多也就是一个库管理成员(Member),当然也不能对组织内其它成员授予写权限咯,但真实情况是,我可以的!因为Github的预期设计是只有组织所有者才能安装集成类app,在这种最高权限下,默认组织所有者具备授权权限。像以下安装app时,会默认具备多种权限:

04.png接下来,我要看看内置相应的API是否能够正常预期工作而不会发生任何权限错误,最终,我可以互相利用一些服务端,在某个角色参数帮助下添加或更新组织成员身份,在此场景下,我还能邀请其它用户以账户所有者身份加入该组织分组。像下图中,我可用不具备权限的“OrgMember” 账户去安装集成类app,也能通过API以所有者身份邀请 “NewMember”账户加入当前组织。05.png

总结

该漏洞可能会被某些组织内的库管理员利用,但经过调查分析,我发现,所有允许成员创建库的组织(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