【技术分享】赏金$35000的GitHub漏洞：攻破GitHub私有页面

微信号 anquanbobao 功能介绍打破黑箱客说安全 0x00前言这个漏洞是我和@ginkoid合作发现的，同时也是我在HackerOne上获得的第一笔漏洞赏金（35,000美元），也是迄今为止我从HackerOne获得的最高赏金，我相信也可能是GitHub迄今为止支

Tags:

via Pocket https://ift.tt/2Q2oufY original site

April 13, 2021 at 06:36PM

Comments

from: github-actions[bot] on: 4/13/2021

【技术分享】赏金$35000的GitHub漏洞：攻破GitHub私有页面 by 安全客

2021-04-13

0x00前言

这个漏洞是我和@ ginkoid合作发现的，同时也是我在HackerOne上获得的第一笔漏洞赏金（35,000美元），也是迄今为止我从HackerOne获得的最高赏金，我相信也可能是GitHub迄今为止支付的最高赏金。

由于新冠疫情，高三线上学习课程之余，我将更多精力放在漏洞挖掘上。这个漏洞是作为GitHub私有页面的赏金项目中的一部分被提交的，这笔巨额赏金还有包括其他两个CTF奖金：

$10000 : 在无需用户交互的条件下读取 “flag.private-org.github.io “上的flag。如果从private-org之外的账户读取flag，则额外奖励5k美元

$5000 : 在有用户交互的条件下读取flag.private-org.github.io上的flag

在这篇文章中，我将详细说明挖掘思路。

0x01认证流程

由于GitHub 私有页面是单独在域github.io上托管，github.com认证cookie不会被发送到私有页面服务器上。因此，如果不与github.com进行额外的整合，私有页面认证就无法确定用户的身份。因此，GitHub创建了一个自定义的身份验证流程，这期间就可能引入错误。在提交漏洞报告时，GitHub私有页面的认证流程如下：

在访问私有页面时，服务器会检查是否存在__Host-gh_pages_tokencookie，如果该cookie不存在或设置错误，私有页面服务器将重定向到https://github.com/login。这个初始重定向会设置一个“nonce”存储在__Host-gh_pages_session的cookie中。需要注意的是，这个cookie使用了__Host- cookie前缀，作为一种额外的防御措施，理论上可以防止JavaScript对非主机式父域进行设置。

/login将重定向到/pages/auth?nonce=&page_id=&path=。这个端点会生成一个临时的认证cookie，并将其传递给token参数中的https://pages-auth.github.com/redirect，nonce、page_id和path也同样被转发。

/redirect只转发到https://repo.org.github.io/__/auth。最后一个端点设置了repo.org.github.io域的认证cookie、__Host-gh_pages_token和__Host-gh_pages_id，也会根据之前设置的__Host-gh_pages_session验证nonce。

在整个认证流程中，原始请求路径和页面ID等信息分别存储在查询参数path和page_id中，“nonce” 也会通过nonce参数传递。

0x02漏洞挖掘思路

CRLF

第一个漏洞是在https://repo.org.github.io/__/auth的page_id参数中注入CRLF。在对认证流程研究的过程中，我注意到page_id的解析似乎忽略了空格，同时还将参数直接解析到Set-Cookie头中。

举个例子，如果传递page_id=12345%20：

Set-Cookie: __Host-gh_pages_id=13212257 ; Secure; HttpOnly; path=/

伪代码逻辑如下：

page_id = query.page_id

这里，page_id被转换为一个整数，并直接解析到 Set-Cookie头中。问题是我们不能直接解析任何文本。虽然有一个经典的CRLF注入，但放置任何非空格字符都会导致整数解析中断。我们可以通过发送page_id=12345%0d%0a%0d%0a来打破认证流程，但没有任何直接影响，除了以下这个响应：

; Secure; HttpOnly; path=/

因为Location:头被附加在Set-Cookie头之后，响应会将把Location排除到已发送的HTTP头之外。即使是302重定向，也会忽略Location头并解析正文内容。

更进一步

翻看了一下GitHub企业版源码（提供了访问源码的权限），我怀疑私有页面服务器为openresty nginx，可能它存在空字节的问题？

当我们附加一个空字节，就会导致整数解析结束。换句话说，我们可以使用这样的有效payload：

"?page_id=" + encodeURIComponent("\r\n\r\n\x00<script>alert(origin)</script>")

这里，我们获得一个XSS漏洞：

这里需要注意的是，如果头中有一个空字节，响应就会被拒绝，因此，空字节必须出现在正文的开头，这意味着我们不能进行请求头注入攻击。

至此，我们已经实现了在私有页面域上执行任意的JavaScript，但还需要一种绕过nonce的方法。虽然page_id和path参数已知，但“nonce”阻止我们用污染的page_id向受害者发送认证流程。

绕过Nonce

通过观察发现，同一组织中的同级私有页面可以互相设置cookie，这是因为*.github.io不在公共后缀列表中。因此，在private-org.github.io上设置的cookie会传到private-page.private-org.github.io上。因此，如果我们绕过__Host-前缀保护，就能获得”nonce”绕过，因为另一个同级页面中设置一个假的“nonce”，会被传递下去。幸运的是，这个前缀并不是在所有的浏览器上都被强制执行：

从上图可以看出只有 IE会受到这种绕过的影响，这显然威胁程度不够高。那攻击“nonce”本身呢? 它似乎是安全生成的，而密码学并不是我的强项，也没有办法绕过加密。

于是我调整思路，通过阅读RFCs，我发现了一个有趣的想法——Cookie进行标准化？具体来说，应该如何处理cookie的大写，__HOST-和__Host-一样吗？在浏览器上，很容易确认它们的处理方式是不同的。

document.cookie = "__HOST-Test=1"; // works

可见，GitHub私有页面服务器在解析Cookie时忽略了大写，这样前缀绕过得以实现! 于是，可以使用一个简单的POC来达成完整的XSS!

<script>

这个漏洞就足以获得 $5000 的奖金，但我还想更深一步挖掘。

缓存中毒

/__/auth?端点上的响应仅缓存已解析的整数page_id，这本身在技术上是无害的，因为该端点设置的令牌仅限于私人页面，没有其他权限，但如果以后包含其他权限的token，这就可能引发潜在的安全问题。

这种缓存行为升级攻击的威胁提供了一个途径。因为缓存已解析的整数值，一个带有XSS的缓存中毒可能会影响没有与恶意payload交互的其他用户，演示视频地址：https://robertchen.cc/blog/gh-xss/cache-xss.mp4

如果，攻击者控制了unprivileged.org.github.io，并想获得privileged.org.github.io的访问权，他可以首先污染unprivileged.org.github.io的认证流，使得XSS payload被缓存。当特权用户访问unprivileged.org.github.io时，就会在unprivileged.org.github.io域上遭遇XSS攻击。由于可以在共享的父域org.github.io上设置cookie，攻击者现在可以对privileged.org.github.io进行攻击。这将允许对私有页面拥有读权限的攻击者永久破坏该页面的身份验证流。

0x03公有–私有页面

为了获得15000美元的奖金，我们需要从一个不在组织中的用户账户执行这次攻击。我们可以利用另一个看似不相关的错误配置，进入 “Public-Private 页面”。私有页面中可能存在的错误配置使得公共存储库也有自己的 “私有”页面。这些 “私有”页面虽然经过正常的认证周期，但对每个人都是公开的。如果一个组织有这样的“公有——私有页面”，任何拥有GitHub账户的用户都对其用有 “读权限”。

例如，当一个私有页面存储库被改成公共的时候，这种情况情况就会发生。这种场景是合理的，因为一个组织最初可能会创建一个私有版本库和相应的私有页面。后来，该组织可能会决定对项目进行开源，将存储库状态改为公开。这是一个例子，演示视频地址：https://robertchen.cc/blog/gh-xss/public-private.mp4