回归最本质的信息安全

GitHub企业版SQL注入分析

2017年1月10日发布

5,647
1
0

导语:GitHub企业版是GitHub.com的本地版,几乎提供了GitHub的所有功能。通过GitHub的网站可以下到使用45天的VM:链接: enterprise.github.com。

GitHub企业版是GitHub.com的本地版,几乎提供了GitHub的所有功能。通过GitHub的网站可以下到使用45天的VM:链接: enterprise.github.com。开启成功后的界面是这样的:

1483972441248080.png

1483972451766784.png

环境

开始前,我们用nmap意思意思,扫描到端口情况如下:

图片3.png

具体如下:

22/tcp和9418/tcp 这两个端口类似haproxy,会连接到一个后台服务babeld上
80/tcp和443/tcp 是GitHub的服务
122/tcp 是SSH服务
8443/tcp 是GitHub的管理控制台

顺便提下,GitHub的管理控制端需要账号密码登录。有了账号密码,就能通过ssh key登录到VM的122端口

SSH登陆了上虚拟机后。可以看到目录结构如下图:

1483972509700792.png

进入/data/目录,查看源代码,发现代码全被加密了,日:

1483972523686978.png

GitHub使用了一个库来加密源代码,如果你google查找ruby_concealer.so 就能找到一个关键脚本:https://gist.github.com/geoff-codes/02d1e45912253e9ac183

看起来,他只是简单的吧ruby_concealer.so中的rb_f_eval换成rb_f_puts,然后就可以工作了.但是,我们接下来用IDA Pro进一步看看他的原理:

1483972589432402.png

1483972589425932.png

可以看到,他是使用Zlib::Inflate::inflate来对数据进行解压,如果对其进行异或运算,就会出现一下提示:

图片8.png

这样,我们可以很容易将其解密:

图片9.png

代码分析

解码所有的源代码后,我们就可以开始代码审计工作了:

1483972640176416.png

代码是用Ruby写的

/data/github/ 看起来是80和443上跑的web应用,并且看起来是github.com, gist.github.com 和api.github.com 这三个站点的代码
/data/render/ 看起来是render.githubusercontent.com上的代码
/data/enterprise-manage/ 看起来是8443上跑的程序

漏洞

SQL注入是在GitHub企业版的PreReceiveHookTarge模板中找到的。

问题根源是在/data/github/current/app/model/pre_receive_hook_target.rb第45行

图片12.png

这里使用到的是内置的ORM(在Rails中叫做ActiveRecored),尽管Rails有针对SQL注入进行防御,但是,如果大量使用ActiveRecored的话,也可能出现SQL注入。

当然,你可以通过http://rails-sqli.org/网站来学习更多Rails中的SQL注入案例。这里,我们将order参数改成SQL注入的Payload。在/data/github/current/app/api/admin/pre_receive_hooks.rb的61行会调用到了sorted_by函数。

图片13.png

可以看到,params[:sort]被传入到scope.sorted_by中,因此,我们可以在params[:sort]中注入恶意代码。在测试前,我们需要用admin:pre_receive_hook账号通过API得到一个access_token,如下:

图片14.png

通过这个access_token,我们就能进一步触发漏洞。

1483972748944007.png

本文翻译于orange,如若转载,请注明来源于嘶吼: http://www.4hou.com/technology/2941.html

点赞 0
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

Change

Change

嘶吼编辑

发私信

发表评论

    天海 春香
    天海 春香 2017-01-10 13:37

    github本地?