之前,我从没参加过 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 适用于商业用途和大型开源项目。
在 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 说明文档中找到了以下解释。
在对集成类 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 官方安全团队作了上报,当然我也在报告中作了备注,希望之后能有更多深入发现。 提权测试 第二天,我想是否能再深入对这个漏洞进行一些利用,由此,在创建安装了 GitHub 集成类 app 之后,我发现可以发起的请求权限非常敏感,特别是允许所有组织成员(Member)和团队(Team)的写权限。按照 Github 说明文档的规定,如果我能对某个我自己的可管理库(Repository)具备安装某些集成类 app 的权限,那么我的身份顶多也就是一个库管理成员(Member),当然也不能对组织内其它成员授予写权限咯,但真实情况是,我可以的!因为 Github 的预期设计是只有组织所有者才能安装集成类 app,在这种最高权限下,默认组织所有者具备授权权限。像以下安装 app 时,会默认具备多种权限: 接下来,我要看看内置相应的 API 是否能够正常预期工作而不会发生任何权限错误,最终,我可以互相利用一些服务端,在某个角色参数帮助下添加或更新组织成员身份,在此场景下,我还能邀请其它用户以账户所有者身份加入该组织分组。像下图中,我可用不具备权限的“OrgMember” 账户去安装集成类 app,也能通过 API 以所有者身份邀请 “NewMember”账户加入当前组织。 总结 该漏洞可能会被某些组织内的库管理员利用,但经过调查分析,我发现,所有允许成员创建库的组织(Organization)都会存在该漏洞,因为这样一来,创建库的成员可以通过创建虚拟库的方式来安装 app,该功能在 Github 中是默认的,通常来说,由于 GitHub 支持模型不再与库绑定,所以大多数组织内的该功能也是启用的。 另外,该漏洞的利用主体除了组织内成员,还可能是其他入侵掌握了组织成员的恶意攻击者。假设某组织分组包含 300 名成员,那么对攻击者来说,他的攻击面就非常之大了。 漏洞上报进程
*参考来源:medium,clouds 编译,转载请注明来自 FreeBuf.COM |