Cacti CVE-2023-39361前台SQL注入漏洞原理与复现分析

原创 于 2026-06-17 14:43:37 发布 · 406 阅读 · 5 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#SQL注入 #Cacti #CVE-2023-39361

1. 项目概述与漏洞背景

最近在梳理一些开源网络监控系统的历史漏洞时，Cacti的CVE-2023-39361这个前台SQL注入漏洞引起了我的注意。Cacti作为一个老牌的、基于RRDtool的网络流量监测图形分析工具，在运维圈子里有着相当广泛的应用基础，很多企业的机房监控大屏后面跑的可能就是它。这个漏洞之所以值得拿出来细说，一方面是因为它影响的是无需认证的前台功能，攻击门槛极低；另一方面，其触发点隐藏在正常的业务参数里，利用方式有点“反直觉”，不是那种一眼就能看出来的注入点。复现和分析这类漏洞，对于理解如何在看似正常的业务逻辑中挖掘安全风险，以及如何编写更安全的代码，有很强的实战意义。简单来说，这个漏洞允许远程攻击者无需登录，通过构造特定的HTTP请求参数，在Cacti数据库上执行任意SQL语句，可能导致数据泄露、篡改，甚至服务器被完全控制。接下来，我会带你从环境搭建开始，一步步拆解漏洞原理，并完成手动的漏洞复现，过程中会穿插很多我踩过的坑和调试技巧。

2. 漏洞原理深度解析

2.1 Cacti的 host_id 参数处理机制

要理解CVE-2023-39361，必须先搞清楚Cacti中一个关键的业务参数： host_id 。在Cacti的体系里， host_id 唯一标识一台被监控的设备（主机）。很多前台页面，比如图形展示页面 graph.php ，都需要根据 host_id 来查询并渲染对应设备的监控图表。问题就出在Cacti对传入的 host_id 参数的处理逻辑上。

在受影响版本的Cacti源代码（例如1.2.24版本）中，我们查看 graph.php 文件。当它接收到 host_id 参数后，并没有直接使用 intval() 或类似的强类型转换函数将其转为整数，也没有使用预编译语句（Prepared Statements）。相反，它可能采用了相对宽松的过滤或直接拼接的方式，将 host_id 的值嵌入了SQL查询字符串中。例如，一段可能存在风险的伪代码逻辑是： 

$host_id = $_GET['host_id'];
$sql = "SELECT * FROM graph_local WHERE host_id = " . $host_id;

如果 $host_id 完全由用户控制且未经验证，那么这里就存在典型的数字型SQL注入漏洞。攻击者可以传入 1 OR 1=1 这样的值，从而改变原查询的逻辑。

2.2 漏洞触发点与利用链分析

然而，CVE-2023-39361的利用方式比简单的 1 OR 1=1 要稍微曲折一点。根据公开的漏洞详情，这个注入点位于 graph.php 文件中，与 host_id 参数的处理有关，但可能需要通过一个“开关”参数来激活特定的代码路径，使得有缺陷的SQL拼接逻辑被执行。

一种常见的情况是，代码中可能存在多个分支。例如： 

if (isset($_GET['view_type'])) {
    // 分支A：使用安全的预编译查询
    $stmt = $pdo->prepare("SELECT ... WHERE host_id = ?");
    $stmt->execute([$host_id]);
} else {
    // 分支B：为了兼容老代码或特定功能，采用了不安全的字符串拼接
    $sql = "SELECT * FROM some_table WHERE host_id = " . $host_id;
    $result = db_fetch_row($sql); // 危险函数
}

攻击者通过不提供 view_type 参数（或提供特定值），诱使程序执行到那个存在拼接漏洞的分支B。这就是为什么在复现时，我们不仅需要关注 host_id ，还要注意其他配套参数的正确组合。

这个漏洞的本质是 输入验证不彻底与SQL语句拼接 的共同作用。开发人员可能认为 host_id 来自下拉框选择，必然是数字，但忽略了HTTP请求可以被轻易篡改的事实。此外，在庞大的遗留代码中，可能存在多处类似的、未更新的老旧查询方式，一旦某个条件分支被触发，风险就随之而来。

注意 ：这里解析的原理是基于常见漏洞模式和对Cacti代码结构的推断。在实际分析时，一定要定位到具体的代码文件、函数和行号。直接搜索代码库中对 $_REQUEST 、 $_GET 、 $_POST 中 host_id 变量的使用，特别是那些周围没有 db_escape_string 或参数化查询函数调用的地方，是定位漏洞的关键。

2.3 与常见SQL注入的异同

这个漏洞属于 数字型SQL注入 。它与字符串型注入（需要闭合引号）的区别在于，注入payload通常不需要考虑单引号。例如，在 WHERE id = $input 中，如果 $input 是字符串且未过滤，攻击者需要输入 1' OR '1'='1 来闭合。而在数字型注入中，输入 1 OR 1=1 即可，因为原查询本身就没有引号。

它的“前台”属性使其危害性大增。相比于需要登录后才能触发的后台注入，前台注入意味着互联网上的任何匿名用户都可能发起攻击。结合Cacti通常部署在内网或运维边界的特点，一旦存在漏洞，很容易成为攻击者从外网渗透到内网的跳板。

3. 复现环境搭建与配置

3.1 靶机环境选择与部署

为了安全且合规地复现漏洞，我们必须在隔离的环境中进行。我强烈推荐使用虚拟机搭建靶场。

方案一：使用预构建的漏洞环境（最快） 网络上存在一些安全研究者打包好的、包含特定漏洞的Cacti虚拟机镜像或Docker镜像。例如，你可以搜索“Cacti CVE-2023-39361 Vulhub”或类似关键词。使用这类环境的好处是开箱即用，省去了安装配置的麻烦，特别适合专注于漏洞利用本身的学习。

  1. 下载OVA或虚拟机镜像文件。
  2. 使用VMware Workstation或VirtualBox导入该虚拟机。
  3. 启动虚拟机，按照说明设置网络（通常为NAT或Host-Only模式），并记录下IP地址和登录凭证。

方案二：手动安装受影响版本的Cacti（最贴近实战） 如果你想更深入地理解Cacti，我建议手动安装。这里以在Ubuntu 22.04上安装Cacti 1.2.24（受漏洞影响的版本之一）为例。

  1. 系统准备 ：新建一个Ubuntu Server虚拟机。配置好网络，确保可以 apt-get update 。
  2. 安装LAMP栈 ： 
    sudo apt update
sudo apt install -y apache2 mariadb-server php php-mysql php-snmp php-ldap php-gd php-xml php-mbstring php-json php-zip rrdtool snmp snmpd
  3. 配置MariaDB ： 
    sudo mysql_secure_installation # 设置root密码，并移除测试数据库、匿名用户等。
sudo mysql -u root -p
    在MySQL命令行中创建Cacti数据库和用户： 
    CREATE DATABASE cacti CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'cactiuser'@'localhost' IDENTIFIED BY 'YourStrongPassword123!';
GRANT ALL PRIVILEGES ON cacti.* TO 'cactiuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;
  4. 下载并安装Cacti ： 
    wget https://github.com/Cacti/cacti/archive/refs/tags/release/1.2.24.tar.gz
tar -zxvf release/1.2.24.tar.gz
sudo mv cacti-release-1.2.24 /var/www/html/cacti
sudo chown -R www-data:www-data /var/www/html/cacti
  5. 导入数据库结构 ： 
    mysql -u cactiuser -p cacti < /var/www/html/cacti/cacti.sql
  6. 配置Cacti ：编辑 /var/www/html/cacti/include/config.php ，设置数据库连接信息。
  7. 配置Apache ：为Cacti创建一个虚拟主机或直接修改默认站点目录。然后重启Apache： sudo systemctl restart apache2 。
  8. 通过Web安装 ：浏览器访问 http://your-vm-ip/cacti ，按照安装向导完成最后步骤。安装过程中会要求输入数据库信息和创建管理员账号。

实操心得 ：手动安装时最容易出错的环节是文件权限和数据库配置。务必确保 /var/www/html/cacti 目录及其子文件对 www-data 用户可读可写（特别是 log 和 rra 目录）。数据库密码复杂度要够，但也要记牢，否则安装向导会卡住。

3.2 网络与工具准备

  1. 攻击机 ：我使用另一台Kali Linux虚拟机作为攻击机。确保攻击机和靶机在同一网络段（例如都使用VMware的NAT或同一自定义网络），能够互相ping通。
  2. 必备工具 ：
    • 浏览器 ：用于正常访问和观察Cacti界面。Chrome或Firefox均可，建议安装开发者工具插件（如HackBar）方便手动构造请求，但这并非必需。
    • Burp Suite ：这是我们的核心工具。用于拦截、修改和重放HTTP请求。Community版就足够用于复现。
    • SQLMap ：自动化SQL注入工具。用于验证漏洞存在性和进行进一步的数据探测。在Kali中通常已预装。
    • 文本编辑器/IDE ：用于查看Cacti的PHP源码，理解漏洞上下文。VS Code或Sublime Text都不错。

环境检查清单 ：

  • [ ] 靶机Cacti可正常访问，能看到登录页面或监控图形。
  • [ ] 攻击机可以访问靶机的Cacti Web服务（ http://靶机IP/cacti ）。
  • [ ] Burp Suite代理已配置好，并且浏览器流量能通过Burp代理。
  • [ ] SQLMap在攻击机上可以正常运行。

4. 漏洞手动复现与利用过程

4.1 信息收集与潜在注入点探测

首先，我们需要以正常用户身份浏览Cacti，找到接收 host_id 参数的功能点。

  1. 访问Cacti ：在浏览器中打开靶机的Cacti地址。由于是前台漏洞，我们不需要登录。尝试访问一些公开页面，如 graph.php 、 index.php 等。
  2. 观察URL参数 ：点击不同的图表或导航，观察浏览器地址栏URL的变化。重点关注包含 host_id 、 id 、 graph_id 等看起来是数据库键值的参数。例如，你可能会看到类似 http://target/cacti/graph.php?host_id=3 的链接。
  3. 使用Burp Suite抓包 ：
    • 启动Burp Suite，配置浏览器代理（通常是 127.0.0.1:8080 ）。
    • 在浏览器中刷新Cacti页面，或点击一个包含 host_id 的图表链接。
    • 在Burp的Proxy -> HTTP history中，你应该能看到捕获到的 GET /cacti/graph.php?host_id=3 这样的请求。

4.2 构造并发送注入Payload

这是最关键的步骤。我们假设 graph.php 的 host_id 参数存在数字型注入。

  1. 初步测试 ：在Burp Suite中，找到那条 GET /cacti/graph.php?host_id=3 的请求，右键发送到 Repeater 模块。Repeater允许我们手动修改并重复发送请求，观察响应。
  2. 基础逻辑测试 ：修改 host_id 参数的值，测试其是否对SQL语句敏感。
    • 发送原始值： host_id=3 。记录响应内容（如页面标题、图表是否正常显示）。
    • 发送真条件： host_id=3 OR 1=1 。如果存在注入且 1=1 为真，查询可能返回所有主机（或第一条主机）的图形数据，导致页面显示异常（如显示默认图、错误、或第一个主机的图）。
    • 发送假条件： host_id=3 AND 1=2 。如果 1=2 为假，查询可能没有结果，页面可能显示“无图形数据”、空白区域或与 host_id=99999 （不存在的ID）类似的效果。
    • 对比响应 ：仔细对比 host_id=3 、 host_id=3 OR 1=1 、 host_id=3 AND 1=2 这三个请求的HTTP响应。关注：
      • HTTP状态码（是否都是200？）
      • 响应体长度（Burp Repeater下方会显示长度，显著差异是重要标志）。
      • 响应内容的关键词（如是否从显示具体主机名变成了“Default”，或出现了数据库错误信息）。
  3. 利用漏洞进行数据探测 ：如果上一步确认存在注入，我们可以尝试获取一些基本信息。例如，获取数据库版本：
    • Payload: host_id=3 UNION SELECT 1,@@version,3,4,5...
    • 难点 ： UNION 注入需要前后查询的列数一致。我们需要先猜解原查询的列数。通常使用 ORDER BY 子句来探测。
    • 猜解列数 ：发送 host_id=3 ORDER BY 10 。如果10超过了实际列数，数据库会报错（页面可能显示SQL错误或空白）。然后尝试 ORDER BY 9 、 ORDER BY 8 ...直到页面正常返回。假设 ORDER BY 5 正常而 ORDER BY 6 错误，那么原查询就是5列。
    • 构造UNION查询 ：知道了是5列，我们就可以构造： host_id=-3 UNION SELECT 1,@@version,3,4,5 。注意把原 host_id 值设为一个不存在的负值（如-3），以确保原查询部分不返回结果，这样页面显示的就全是我们 UNION SELECT 的内容。数据库版本信息可能会出现在页面的某个位置（如标题、图表名称、注释等）。

4.3 使用SQLMap进行自动化验证与利用

手动验证成功后，可以用SQLMap进行更深入、自动化的利用，以证明漏洞的严重性。

  1. 基本检测 ：在Kali终端中，运行： 
    sqlmap -u "http://target/cacti/graph.php?host_id=3" --batch
    --batch 参数会让SQLMap自动选择默认选项。SQLMap会尝试各种注入技术（布尔盲注、时间盲注、联合查询等）来确认漏洞。
  2. 获取当前数据库 ：如果检测到注入，可以获取当前数据库名： 
    sqlmap -u "http://target/cacti/graph.php?host_id=3" --current-db --batch
    预期会输出 cacti 。
  3. 列出所有数据库 （需要较高权限）： 
    sqlmap -u "http://target/cacti/graph.php?host_id=3" --dbs --batch
  4. 列出指定数据库的表 ： 
    sqlmap -u "http://target/cacti/graph.php?host_id=3" -D cacti --tables --batch
    你会看到 user_auth 、 host 等关键表。
  5. 脱库示例（获取用户表数据） ： 
    sqlmap -u "http://target/cacti/graph.php?host_id=3" -D cacti -T user_auth --dump --batch
    这将导出 user_auth 表中的所有数据，其中就包含管理员的用户名和密码哈希值。拿到哈希后，可以尝试用工具（如John the Ripper, hashcat）进行破解。

重要警告 ：以上 --dump 操作仅限在自己搭建的、完全隔离的测试环境中进行。在任何其他环境中尝试都是非法且不道德的。我们的目的仅限于学习漏洞原理和防御方法。

5. 漏洞根因分析与修复方案

5.1 代码层面问题定位

通过复现过程，我们可以逆向推断出问题代码的大致位置和模式。真正的修复需要查看官方补丁或更新后的代码。漏洞根因通常集中在以下几点：

  1. 直接字符串拼接 ：如 $sql = "SELECT ... FROM ... WHERE host_id = " . $_GET['host_id']; 。这是最原始的错误。
  2. 过滤函数使用不当或遗漏 ：Cacti有自己的数据库抽象层函数，如 db_fetch_row() 、 db_fetch_assoc() 等。安全的做法是使用 db_escape_string() 对输入进行转义，或者使用参数化查询。如果开发者在某处遗漏了转义，漏洞就产生了。
  3. 类型转换缺失 ：对于明确应该是整数的 host_id ，在进入SQL查询前，没有使用 intval() 或 (int) 进行强制类型转换。即使输入了 1 OR 1=1 ， intval('1 OR 1=1') 的结果也是 1 ，从而避免了注入。

5.2 官方修复方案解读

对于CVE-2023-39361，Cacti官方在后续版本（如1.2.25）中发布了修复。修复方式通常是以下一种或多种组合：

  • 强制类型转换 ：在获取 host_id 参数后，立即使用 $host_id = intval($_GET['host_id']); 。
  • 使用参数化查询 ：改造数据库查询函数，使用PDO或MySQLi的预编译语句。这是最根本的解决方案。
  • 严格输入验证 ：不仅检查类型，还检查 host_id 的值是否在合法的业务范围内（例如，是否存在于 host 表中）。

查看官方Git仓库的提交历史，是学习安全编码的最佳实践之一。你可以对比 graph.php 文件在漏洞版本和修复版本之间的差异。

5.3 安全开发建议

从这次漏洞中，我们可以总结出几条对开发者至关重要的安全准则：

  1. 永远不要信任用户输入 ：这是安全的第一原则。所有来自HTTP请求（GET, POST, COOKIE）、文件、数据库、网络API的数据都应视为不可信的。
  2. 使用预编译语句（参数化查询） ：这是防止SQL注入的银弹。无论是PHP的PDO/MySQLi，还是其他语言的ORM框架，都应优先使用。 
    // 正确做法（使用PDO）
$stmt = $pdo->prepare("SELECT * FROM graph_local WHERE host_id = :host_id");
$stmt->execute([':host_id' => $_GET['host_id']]);
  3. 如果必须拼接，则严格转义 ：在极少数无法使用预编译语句的遗留代码中，必须使用数据库扩展提供的专用转义函数（如 mysqli_real_escape_string() ），并且要考虑到数据库连接的字符集。
  4. 白名单验证 ：对于像 host_id 这种有明确范围的参数，可以从业务逻辑上验证其有效性。例如，先查询该 host_id 是否存在，再进行后续操作。
  5. 最小权限原则 ：连接Cacti数据库的账号，不应该拥有 DROP , CREATE , FILE 等高级权限，仅授予 SELECT , INSERT , UPDATE , DELETE 等必要权限，以限制漏洞被利用后的影响范围。

6. 防御措施与加固建议

6.1 针对Cacti系统的紧急处置

如果你正在运行受影响版本的Cacti（1.2.24及之前某些版本），应立即采取以下措施：

  1. 升级 ：这是最有效的方法。立即升级到Cacti官方发布的最新稳定版本。升级前请务必做好数据和配置的备份。
  2. 临时缓解 ：如果无法立即升级，可以考虑使用Web应用防火墙（WAF）规则来拦截包含可疑SQL关键词（如 UNION , SELECT , OR , AND , EXEC 等）的对 graph.php 的请求。但这不是长久之计，WAF规则可能被绕过。
  3. 网络隔离 ：确保Cacti系统不直接暴露在公网上。应将其部署在内网，并通过VPN或堡垒机进行访问。严格限制可访问Cacti的源IP地址。

6.2 安全运维常态化建议

  1. 漏洞监控与预警 ：订阅Cacti官方的安全公告邮件列表，或关注国家漏洞库（CNNVD）、NVD等平台，及时获取漏洞信息。
  2. 定期安全评估 ：定期对运维系统（包括Cacti）进行授权下的安全扫描和渗透测试，主动发现潜在风险。
  3. 代码审计习惯 ：对于自行开发或深度定制的功能，在上线前应进行代码安全审计，重点关注用户输入的处理和数据库操作部分。
  4. 纵深防御 ：除了应用本身的安全，还要做好操作系统、数据库、网络层面的安全加固，例如定期更新系统补丁、配置强密码策略、启用数据库日志审计等。

6.3 渗透测试者的反思

从攻击者视角复现漏洞后，更应该从防御者角度思考。这个漏洞的复现过程清晰地展示了一条攻击链：信息收集 -> 参数探测 -> 手工验证 -> 工具利用。对应的，防御体系也应在每个环节设置检测和阻断点：

  • 信息收集阶段 ：通过合理的错误信息处理（不返回详细SQL错误）增加攻击者探测难度。
  • 参数探测阶段 ：严格的输入验证和WAF可以过滤掉大量恶意payload。
  • 漏洞利用阶段 ：完善的日志审计和SIEM告警，可以及时发现异常的SQL查询模式（如大量带 UNION 、 SELECT @@version 的请求）。

手动复现CVE-2023-39361这类漏洞，绝不仅仅是为了“能攻击”，更重要的是理解漏洞产生的每一个环节，从而在开发、运维和防御中建立起更立体的安全意识。每一次成功的复现，都应该是对自身安全技能栈的一次有效加固。在测试环境中，你可以大胆尝试各种payload和工具组合，但务必牢记：技术是把双刃剑，合规与道德是永远不可逾越的底线。

dibisha7239
关注
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值