快捷搜索:  网络  后门  CVE  渗透  木马  扫描  黑客  as

挖洞经验 | 看我怎么样发现GitHub提权漏洞获得$10000赏金

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 编译,

您可能还会对下面的文章感兴趣: