【PoC】平板锅（Palo Alto）Expedition应用安全漏洞深度剖析：从 N-day到全面接管

2024 年 7 月 10 日，Palo Alto 发布了针对CVE-2024-5910的安全公告，该漏洞允许攻击者远程重置 Expedition 应用程序管理员凭据。虽然我们以前从未听说过Expedition应用程序，但它的宣传是：

此工具旨在帮助减少将配置从受支持的供应商迁移到 Palo Alto Networks 所需的时间和精力。通过使用 Expedition，每个人都可以将配置从 Checkpoint、Cisco 或任何其他供应商转换为 PAN-OS，让您有更多时间改进结果。

进一步阅读文档后，很明显该应用程序可能比最初预期的更具攻击价值。Expedition 应用程序部署在 Ubuntu 服务器上，通过 Web 服务进行交互，用户通过添加每个系统的凭据远程集成供应商设备。

图 1. 将设备与凭证集成

本博客详细介绍了发现 CVE-2024-5910 的过程，以及我们如何发现另外 3 个漏洞并向 Palo Alto 报告：

1. CVE-2024-9464：经过身份验证的命令注入

2. CVE-2024-9465：未经身份验证的 SQL 注入

3. CVE-2024-9466：日志中的明文凭证

CVE-2024-5910：无需逆向

根据漏洞的描述，听起来好像存在一些允许重置管理员凭据的内置函数。

Palo Alto Networks Expedition 中关键功能的身份验证缺失，可能导致具有 Expedition 网络访问权限的攻击者接管 Expedition 管理员帐户。

谷歌搜索“palo alto expedition 重置管理员密码”，结果最靠前的是这个论坛帖子。

图 2. 描述重置 php 文件的论坛帖子

我立即看到用户在本地执行的这个 PHP 文件托管在文件夹中/var/www/html/，这看起来很有趣！经过几个小时，在旧的受支持的 Ubuntu 20.04 服务器上部署 Expedition 应用程序失败了三次后，我们终于将应用程序部署到测试中。我们发现，通过 Web 服务向该确切端点发出简单请求即可重置管理员密码。

图 3. 重置管理员密码

退一步，退一步

虽然我们现在拥有 Expedition 应用程序的管理访问权限，但这并不意味着我们可以读取整个系统存储的所有凭据。我们将注意力转向尝试将此管理访问权限转变为服务器上的远程代码执行。

Expedition Web 服务器通过 Apache2 Web 服务托管，正如我们之前所见，/var/www/html 目录用作 Web 根目录。大量文件通过 Web 根目录提供，其中许多文件看似没有必要，并通过 Web 服务公开。Expedition Web 服务使用 php 作为其代码库的主要内容。将攻击面缩小到感兴趣的文件，我们寻找包含单词“exec”的 php 文件 - 如果不加以检查，则可能成为命令注入的途径。

图 4. 大量机会

我们偶然发现了该文件/var/www/html/bin/CronJobs.php，因为它既包含对“exec”的调用，又从传递的请求参数中获取用户输入。任何角色用户的任何有效会话 ID 都将允许用户与此端点交互。

图5. CronJobs.php解析请求参数

当用户更新现有 cronjob 时，对 exec 的调用出现在第 332 行，并从本地 MySQL 数据库中存储的相应 cronjob 条目的数据构建要执行的命令。重要的是，传递的 cronjob 条目cron_id必须存在于cronjobs数据库表中。

图 6. 在 CronJobs.php 中调用 exec()

检查这些数据库条目是如何创建的，我们发现其中还有CronJobs.php一个 create cronjob 函数。当请求参数指定actionis时add，它将在数据库中创建一个空的 cronjob 条目。

图 7. 向数据库添加 cronjob 条目

现在，我们已经用 cronjob 条目填充了 cronjob 表。

图 8. 我们的请求的数据库条目

数据库中存在有效的 cronjob 条目后，现在我们必须找到一种方法来插入恶意命令，以便可以通过我们之前找到的 exec 调用来检索和执行该命令。回顾set发生 exec 调用的 update 或 action = set，我们发现命令值根据传递的请求参数以多种方式构造。

图 9. 使用我们的输入构造“命令”的逻辑

查看第 278 行，当重复次数为 时Daily，命令使用 3 个变量构造，其中 2 个由用户控制。cron_id看起来像是尝试注入命令的良好候选者，但仔细检查用于将恶意命令插入数据库的 SQL 语句需要有效的cron_id插入。

图 10. cron_id 必须有效才能更新

将注意力转向另一个变量，time_today我们发现它是通过获取请求参数start_time并在分号字符上拆分来构造的。但从未验证时间是否有效。

图 11. 根据用户输入格式化的 time_today

我们精心设计请求，使得start_time[0]变成要执行的恶意命令。

start_time="; touch /tmp/hacked ; :

最终的 curl 请求如下所示：

curl -ik 'https://10.0.40.64/bin/CronJobs.php' -H 'Cookie: PHPSESSID=rpagjtqkqkf5269be9ro5597r7' -d “action=set&type=cron_jobs&project=pandb&name=test&recurrence=Daily&start_time=”; touch /tmp/hacked ; :&cron_id=1″

图 12. 使用恶意请求更新后得到的数据库条目

此漏洞的编号为 CVE-2024-9466。我们的概念验证可在此处找到。

图 13. www-data 反向 shell

后期开发

一旦您通过上述漏洞以 www-data 用户身份访问服务器，就可以轻松从数据库中窃取凭据。

要转储所有 API 密钥和明文凭证，请执行以下 SQL 查询：

mysql -u root -p'paloalto' pandbRBAC -e 'SELECT hostname,key_name,api_key,user_name,user_password FROM device_keys dk, devices d WHERE dk.device_id=d.id'

图 14. 集成设备的凭证

在系统中查找其他凭证时，我们偶然发现了一个名为 的文件/home/userSpace/devices/debug.txt。这个所有人都可以读取的文件包含 Expedition 服务器在设备集成过程中用明文凭证交换 API 密钥时的原始请求日志。Expedition 服务器仅存储 API 密钥，不应保留明文凭证，但此日志文件显示了以明文形式使用的所有凭证。此问题已报告并被分配为 CVE-2024-9466。

图 15. debug.txt 记录明文凭证

未经身份验证的 SQL 注入导致凭证盗窃

我们仍然觉得应用程序中还隐藏着更多漏洞，于是回过头来分析暴露在 Web 根目录中的大量文件。将攻击面缩小到感兴趣的文件，我们寻找包含单词“GET”但不包含Authentication.php或sessionControl.php身份验证逻辑的 PHP 文件——这可能表示未经身份验证的端点将请求参数作为输入。

图 16. 未经身份验证的暴露端点

我们偶然发现了这个文件/var/www/html/bin/configurations/parsers/Checkpoint/CHECKPOINT.php。该文件无需身份验证即可访问，以 HTTP 请求参数作为输入，然后使用该输入构建 SQL 查询。

图 17. 端点解析请求参数

寻找SQL注入的路径，我们首先发现，在第73行，当action=import我们解析我们控制的其他请求参数时，会创建变量routeName和，id并以字符串格式构造查询。

图 18. 通过 routeName 变量进行 SQL 注入

不幸的是，查询中选择的表默认不存在 - 因此即使我们可以构造恶意查询，查询也会失败。幸运的是，代码路径action=get具有在给定数据库中创建此表的逻辑。

图 19. 通过 GET 操作创建表

如下所示的未经身份验证的 curl 请求将policies_to_import_Checkpoint在pandbRBAC数据库中创建表。

curl -ivk 'https://10.0.40.64/bin/configurations/parsers/Checkpoint/CHECKPOINT.php' -d "action=get&type=existing_ruleBases&project=pandbRBAC"

图 20. 根据我们的请求成功创建表

回到逻辑action=import，我们现在可以构造一个不会立即失败的 curl 请求。最简单的 SQL 注入版本以未经身份验证的 curl 请求为例：

curl -ivk 'https://10.0.40.64/bin/configurations/parsers/Checkpoint/CHECKPOINT.php' -d "action=import&type=test&project=pandb&signatureid=1 OR 1=1"

将导致查询像这样命中数据库：

图 21. 成功的 SQL 注入

鉴于我们有未经身份验证的 SQL 注入，通过基于盲 SLEEP 的有效载荷泄露数据的关注表是“用户”和“设备”表，其中包含密码哈希和设备 API 密钥，如上一个后期利用部分所示。

启动 SQLMAP 工具，并向其提供要注入的端点和参数以及要转储的表，它成功转储整个用户表。

python3 sqlmap.py -u "https://10.0.40.64/bin/configurations/parsers/Checkpoint/CHECKPOINT.php?action=im port&type=test&project=pandbRBAC&signatureid=1" -p signatureid -T users --dump

图 22. 通过 BLIND 基于时间的 SQL 负载转储所选的整个表

此漏洞的编号为 CVE-2024-9465。我们的概念验证可在此处找到。

IoC

该文件/var/apache/log/access.log将记录 HTTP 请求，并应检查这些漏洞中滥用的端点。

• /OS/startup/restore/restoreAdmin.php– 重置管理员凭据

• /bin/Auth.php– 使用重置管理员凭据进行身份验证

• /bin/CronJobs.php– 插入恶意 SQL 数据以进行命令注入

• /bin/configurations/parsers/Checkpoint/CHECKPOINT.php – 未经身份验证的 SQL 注入，窃取数据库数据

图 23. 请求日志

暴露情况

在撰写本文时，大约有 23 台 Expedition 服务器暴露在互联网上，这是有道理的，因为就其功能而言，它似乎不是一个需要暴露的应用程序。

图 24. Shodan 曝光

披露时间表

• 2024 年 7 月 11 日– 向 Palo Alto PSIRT 报告经过身份验证的命令注入

• 2024 年 7 月 12 日– 向 Palo Alto PSIRT 报告未经身份验证的 SQL 注入

• 2024 年 7 月 12 日——Palo Alto 确认收到两份问题

• 2024 年 7 月 28 日– 向 Palo Alto PSIRT 报告日志中的明文凭证

• 2024 年 8 月 1 日——Palo Alto 确认收到问题

• 2024 年 10 月 9 日- Palo Alto发布针对 CVE-2024-9464、CVE-2024-9465、CVE-2024-9466 的公告 

• 2024 年 10 月 9 日——本博文

PoC：

https://github.com/horizon3ai/CVE-2024-9464

平板锅的公告：

https://security.paloaltonetworks.com/PAN-SA-2024-0010

原文始发于微信公众号（独眼情报）：【PoC】平板锅（Palo Alto）Expedition应用安全漏洞深度剖析：从 N-day到全面接管