CVE-2024-9465：Palo Alto Expedition 未经身份验证的 SQL 注入 POC

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 的发现

CVE-2024-9464：经过身份验证的命令注入CVE-2024-9465：未经身份验证的 SQL 注入CVE-2024-9466：日志中的明文凭证

CVE-2024-5910：无需逆向

鉴于漏洞的描述，听起来好像存在一些允许重置管理员凭据的内置功能。

Palo Alto Networks Expedition 中缺少对关键功能的身份验证可能会导致具有 Expedition 网络访问权限的攻击者接管 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 条目。重要的是，传递的cron_id的 cronjob 条目必须存在于cronjobs数据库表中。

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

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

图 7. 将 cronjob 条目添加到数据库

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

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

有了数据库中有效的 cronjob 条目，现在我们必须找到一种方法来插入恶意命令，以便可以通过调用我们之前发现的 exec 来检索和执行该命令。回顾调用 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”一词的 PHP 文件，但不包含Authentication.php或sessionControl.php身份验证逻辑 - 这可能表明未经身份验证的端点将请求参数作为输入。

图 16. 未经身份验证的公开端点

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

图 17. 端点解析请求参数

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

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

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

图 19. 通过 GET 操作创建表

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

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。我们的概念验证可以在这里找到。

指标

文件/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. 请求日志

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

poc:https://github.com/horizon3ai/CVE-2024-9465.git

原文始发于微信公众号（合规渗透）：CVE-2024-9465：Palo Alto Expedition 未经身份验证的 SQL 注入 POC