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

环境

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

具体如下：

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

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

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

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

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

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

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

这样，我们可以很容易将其解密：

代码分析

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

代码是用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行

这里使用到的是内置的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函数。

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

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

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