文章总结： 本文详细介绍了RCE漏洞挖掘的黑盒与白盒方法，包括系统命令执行、脚本代码执行、文件相关漏洞、第三方组件漏洞等挖掘技术。黑盒视角关注外部交互与恶意输入构造，白盒视角通过代码审计追踪危险函数。文章提供了各类漏洞的测试方法、工具及注意事项，并强调两种方法的结合使用能提升漏洞挖掘效率，是实用的安全测试指南。
综合评分： 85
文章分类： 渗透测试,漏洞分析,WEB安全,代码审计,实战经验

RCE安全（五）

原创

一个努力的学渣

一个努力的学渣

2025年12月8日 12:00
北京

免责声明

本文只做学术研究使用，不可对真实未授权网站使用，如若非法他用，与平台和本文作者无关，需自行负责！！！

前言

• RCE漏洞挖掘的核心是“找到用户可控输入与代码/命令执行流的交集，且无有效过滤”。
• 黑盒视角以“外部交互”为核心，通过构造恶意输入验证漏洞
• 白盒视角以“代码审计”为核心，通过追踪输入流向危险函数精准定位漏洞。
• 实际挖掘中，需结合目标系统技术栈、业务逻辑，灵活运用两种方法，同时遵守安全测试规范，避免造成不必要的损失。
• 通过持续积累漏洞挖掘经验、关注最新漏洞趋势（如新型组件漏洞、新型反序列化），可不断提升RCE漏洞挖掘能力
• 本文忽略了如何绕过（判断是否存在漏洞之前需进行此步骤），上一篇已经讲过，如遇到问题，请翻看上一篇：RCE安全（四）

黑盒视角挖掘

核心前提：识别潜在攻击面

• 命令执行相关功能：系统命令调用是最直接的RCE场景，如文件备份/恢复、系统信息查询（CPU、内存、磁盘）、日志导出、网络探测（ping、traceroute）、批量操作（批量删除、批量导出）等。这类功能往往需要调用服务器端系统命令（如Windows的cmd命令、Linux的bash命令），若用户输入直接拼接进命令中，极易导致命令执行。
• 脚本/代码解析功能：支持动态脚本解析的功能，如模板引擎渲染（Freemarker、Velocity、Thymeleaf）、代码执行接口（如PHP的eval接口、Python的exec接口）、自定义脚本运行模块等。若用户输入被当作脚本代码片段解析，会直接导致代码执行。
• 文件操作相关功能：文件上传（头像、文档、附件）、文件解压（zip、rar）、文件包含（动态加载配置文件、模板文件）等。文件上传若未限制后缀（如允许上传php、jsp、asp等可执行文件），或解压时存在路径穿越+文件覆盖，可能间接导致RCE；文件包含若使用用户可控路径，且未过滤危险协议（如php://、file://），可能触发远程文件包含（RFI）进而执行代码。
• 第三方组件/插件交互：目标系统依赖的第三方组件（如CMS系统、框架、中间件）存在已知RCE漏洞（如Log4j2的JNDI注入、Struts2的OGNL表达式注入、Fastjson反序列化），通过触发组件漏洞实现RCE。
• 特殊协议/接口交互：支持JNDI、LDAP、RMI、MySQL UDF、Redis命令执行等协议的接口，若用户输入可控，可能通过协议注入触发RCE。

系统命令执行漏洞挖掘

• 核心思路：寻找用户输入拼接进系统命令的功能，通过“命令分隔符”注入恶意命令，观察是否生效。

• 第一步：定位测试点：

• 优先测试需要用户输入“参数”的命令相关功能，如：网络工具：ping功能（输入IP地址）、traceroute功能（输入目标地址）

• 文件操作：文件路径输入（备份路径、导出路径）、文件名输入（批量删除文件名

• 系统管理：定时任务配置（输入执行命令）、服务重启参数（输入服务名+参数）

• 第二步：构造测试用例：

• Linux：

• 分隔符：; 、 & 、 && 、 | 、 ||

• 简单测试：127.0.0.1&&id

• Windows：

• & 、 && 、 | 、 || 、 ;（部分场景支持）

• 127.0.0.1&whoami

• 第三步：判断漏洞是否存在

• 需要先绕过，至于如何绕过看上篇文章

• 有回显：页面直接输出命令结果

• 无回显：

• PS：建议优先查看网页源代码，经常挖洞的应该很清楚，有的时候结果可能会藏在网页源代码中

• 写文件，然后访问文件是否存在，如果文件可以访问，代表存在RCE漏洞

• Dnslog：若Dnslog接收到数据，代表存在RCE漏洞

• 时间延迟：若页面响应时间明显增加（如延迟10秒），则说明命令已执行

• Linux：127.0.0.1; sleep 10

• Windows：127.0.0.1&ping -n 10 127.0.0.1

• 反向连接：

• 可使用网站生成：https://forum.ywhack.com/shell.php

• 可使用插件生成：hack-Tools

脚本代码执行漏洞挖掘

• 核心思路：寻找用户输入被当作脚本代码片段解析的场景，注入对应脚本语言的“代码执行语句”，观察反馈

• 每种脚本语言执行方法不一样，这里不细说，前几篇文章应该有写

• 判断漏洞是否存在：

• 有回显：页面会直接反馈结果

• 无回显：

• PS：建议优先查看网页源代码，经常挖洞的应该很清楚，有的时候结果可能会藏在网页源代码中

• Dnslog：若Dnslog接收到数据，代表存在RCE漏洞

• 写文件：

• PHP：file_put_contents(‘test.txt’,’rce’)

• Java：new java.io.FileWriter(“test.txt”).write(“rce”)）

• 反向连接：

• 可使用网站生成：https://forum.ywhack.com/shell.php

• 可使用插件生成：hack-Tools

文件相关RCE漏洞挖掘

• 核心思路：通过文件操作间接触发代码执行，重点关注“文件上传/解压”和“文件包含”两个场景

• 文件上传RCE：

• 基础测试：上传文件，观察文件是否可以上传成功（一般都不会上传成功，需要绕过）

• 进阶测试：上传文件，一般都会移动文件(如临时目录)，如果过滤不严谨，可造成RCE漏洞，参考链接：RCE安全（三）

• 文件上传漏洞可参考：文件上传漏洞

• 大概可分为后缀绕过(检测后缀)、内容绕过(检测文件内容)、路径控制(若上传路径可控制，尝试“路径穿越”，如上传时将文件名改为../../test.php)

• 验证：若上传的文件能执行代码/命令，代表存在RCE漏洞

• 文件包含RCE：

• 测试场景：动态加载文件的功能（如加载配置文件、模板文件、插件文件），输入点通常为“文件路径参数”（如http://目标地址/index.php?file=config.php）

• 分类：本地文件包含、远程文件包含

• 绕过：伪协议绕过

• 参考文章：文件包含漏洞

• 验证：如能正常包含文件，代表存在文件包含RCE

• 文件解压RCE：

• 测试思路：目标系统支持解压zip/rar等压缩包时，构造包含“恶意文件+路径穿越”的压缩包，解压后覆盖服务器上的可执行文件或在指定路径生成恶意文件。

• 测试方法：

• 构造压缩包：将恶意文件（如test.php）的文件名改为../../test.php（路径穿越，视情况而定），压缩为test.zip

• 上传解压：上传test.zip并触发解压功能

• 验证：访问http://目标地址/test.php，观察是否执行代码

第三方组件RCE漏洞挖掘

• 核心思路：目标系统依赖的第三方组件（框架、CMS、中间件、插件）存在已知RCE漏洞，通过“版本识别+漏洞利用”实现RCE
• 第一步：组件版本识别，如Wappalyzer插件
• 第二步：查找对应漏洞，直接百度/github/漏洞库搜索
• 第三步：验证漏洞，集成工具/组件漏洞专用工具

黑盒挖掘常见工具

• 信息收集工具：Wappalyzer（浏览器插件，识别组件版本）、WhatWeb（命令行组件识别）、Nmap（端口扫描+组件版本探测）、Nikto（Web服务器漏洞扫描）
• 漏洞扫描工具：AWVS（Acunetix）、Burp Suite（拦截请求，构造恶意输入）、Nessus（综合漏洞扫描）、Metasploit（包含大量RCE漏洞POC/EXP，可直接验证和利用）
• 代码执行辅助工具：中国蚁剑、冰蝎（连接WebShell，管理已获取的RCE权限）、NC（Netcat，监听反向连接）、Python/PHP脚本（编写自定义POC）
• 组件漏洞专用工具：Log4j2漏洞扫描工具（如log4j-scan）、Struts2漏洞扫描工具（如struts2-scan）、Fastjson漏洞检测工具（如fastjson-scan）

黑盒挖掘注意事项

• 优先使用“无破坏性”测试用例（如whoami、id、phpinfo、时间延迟），避免直接执行删除、修改文件等危险命令
• 若目标系统无直接输出，优先使用“Dnslog”或“写入文件”的方式验证，避免遗漏漏洞
• 注意过滤机制：如何绕过？
• F12–>页面源代码可能藏有关键信息，不要放过
• 遵守授权测试原则：仅对拥有合法测试授权的系统进行挖掘，避免触犯法律

白盒视角挖掘

• 白盒测试的核心是“代码审计”，通过阅读目标系统源代码，直接寻找“用户可控输入未被安全过滤，进而注入到代码/命令执行流”的逻辑缺陷。相比黑盒测试，白盒测试更精准，可发现黑盒难以覆盖的“隐藏漏洞”（如未对外开放的接口、逻辑复杂的代码执行点）
• 代码审计：当然得会代码了，或者尝试使用AI进行代码审计

各语言常见危险函数/API

| | | |
| — | — | — |
| 语言 | 系统命令执行函数 | 代码执行函数 |
| PHP | system()、exec()、shell_exec()、passthru()、popen()、proc_open()、反引号、pcntl_exec() | eval()、assert()、call_user_func()、call_user_func_array()、create_function()、preg_replace()、array_map()、array_filter()、uasort() |
| JAVA | Runtime.getRuntime().exec()、ProcessBuilder.start()、ProcessImpl.start() | OGNL表达式解析、SpEL表达式解析、Freemarker模板解析、JavaScript引擎解析（ScriptEngine.eval()）、反射（Class.forName()）、反序列化（readObject()） |
| Python | os.system()、os.popen()、subprocess()、commands | eval()、exec()、execfile()、compile()、__import__()（动态导入模块执行） |
| ASP.NET | Process.Start()、Shell()、WScript.Shell.Exec() | CodeDom.CompileAssemblyFromSource()（动态编译代码）、Eval()、Execute()、ViewState反序列化 |

白盒挖掘核心方法：追踪用户输入流向危险函数

• 白盒挖掘的核心逻辑是“找到危险函数/功能点 → 追踪危险函数的参数来源 → 判断参数是否用户可控且未被安全过滤”

• 第一步：定位危险函数调用点/功能点

• 功能点：根据功能点来找代码(如有路由，需看懂路由)

• 定位危险函数调用点：

• 通过代码搜索工具（如IDE的全局搜索），在源代码中搜索上述危险函数，定位所有可能的风险点

• 危险函数上面已经大概整理，不一定全

• 重点关注“参数为变量”的调用场景（如system($cmd)、exec(command)），而非固定参数（如system(“ls -l”)、exec(“ping 127.0.0.1”)）——固定参数通常无风险，变量参数才可能存在用户可控的情况

• 第二步：追踪变量参数的来源（输入追踪）

• 对于危险函数的变量参数（如$cmd、command），向上追踪其赋值过程，判断变量是否来源于“用户可控输入”。用户可控输入的常见来源包括：

• HTTP请求参数：GET参数（$_GET[‘param’]）、POST参数（$_POST[‘param’]）、Cookie参数（$_COOKIE[‘param’]）、HTTP头参数（如User-Agent、Referer、X-Forwarded-For）

• 外部存储数据：数据库查询结果、Redis缓存数据、消息队列数据、文件内容（如读取用户上传的文件内容赋值给变量）

• 第三方接口数据：调用外部API返回的数据，若第三方API数据可控，也可能成为输入来源

举例：// 危险函数调用点system($cmd);// 向上追踪$cmd的赋值$cmd = $_GET['action'] . " --config config.ini";// 结论：$cmd包含GET参数action，属于用户可控输入

• 第三步：检查输入过滤机制（安全验证）

• 若变量参数来源于用户可控输入，需进一步检查代码中是否存在“安全过滤/验证机制”。若未过滤，或过滤机制存在缺陷（如过滤不全面、可绕过），则存在RCE漏洞

• 无过滤机制：直接将用户输入拼接进危险函数，漏洞成立

// 无过滤，直接拼接命令$ip = $_GET['ip'];system("ping " . $ip); // 输入127.0.0.1; whoami即可执行whoami

• 过滤机制存在缺陷：

• 过滤不全面：仅过滤部分危险字符（如只过滤;，未过滤&、|）

• 过滤逻辑错误：如使用str_replace替换危险字符，但未循环替换（如输入;;，替换一次后变为;，仍可触发漏洞）

• 过滤后再次拼接：过滤后的输入被二次拼接进危险函数，导致过滤失效

• 可绕过的验证：如通过正则表达式验证输入格式，但正则存在缺陷（如验证IP的正则可被127.0.0.1;whoami绕过）

// 过滤机制存在缺陷（仅过滤;，未过滤&）$ip = $_GET['ip'];$ip = str_replace(";", "", $ip); // 替换;system("ping " . $ip);// 输入127.0.0.1&whoami，&未被过滤，仍可执行whoami

• 安全的过滤机制：若采用“白名单验证”（仅允许特定字符/格式的输入），或“参数化调用”（避免直接拼接输入），或”参数化固定”，则无漏洞

// 白名单验证（仅允许IP格式的输入）$ip = $_GET['ip'];if (!filter_var($ip, FILTER_VALIDATE_IP)) {    die("非法IP");}system("ping " . $ip); // 输入恶意命令会被拦截，无漏洞

• 第四步：验证漏洞可利用性

• 找到潜在漏洞后，需构造恶意输入验证漏洞是否可实际利用。例如：

• 若危险函数为system(“ping ” . $ip)，构造$ip=127.0.0.1; whoami，验证是否能执行whoami

• 若危险函数为eval($code)，构造$code=system(‘whoami’);，验证是否能执行系统命令

• 若危险函数为include($file)，构造$file=php://input，通过POST提交，验证是否能执行代码

反序列化RCE漏洞挖掘

• 反序列化RCE是白盒挖掘的重点场景，核心是“用户可控的序列化数据被反序列化函数解析，且反序列化类中存在可利用的魔术方法/ gadgets链”

• 挖掘步骤：(按照实际情况来，这里只是大概说下)

• 定位反序列化函数调用点（如Java的readObject()、PHP的unserialize()、Python的pickle.load()）

• 追踪反序列化数据的来源，判断是否用户可控（如从GET/POST参数、Cookie、文件中读取序列化数据）

• 分析反序列化类的代码，寻找可利用的“魔术方法”（如PHP的__wakeup()、__destruct()，Java的readObject()重写方法）或“gadgets链”（多个类的方法调用链，最终触发代码执行）

• 构造恶意序列化数据，验证是否能触发代码执行

PHP反序列化简单示例：// 反序列化函数调用点，$data来自GET参数，用户可控$data = $_GET['data'];unserialize($data);// 反序列化类，存在__wakeup()魔术方法class Test {    private $cmd;    public function __wakeup() {        system($this->cmd); // 执行cmd变量    }}// 构造恶意序列化数据，将cmd设为whoami$test = new Test();$test->cmd = "whoami";echo serialize($test); // 将序列化结果作为data参数传入，即可执行whoami

模板注入RCE漏洞挖掘

• 模板引擎（如Freemarker、Velocity、Jinja2、Smarty）的核心是“将模板与数据结合生成页面”，若用户输入被当作模板代码解析，而非普通数据，会导致模板注入RCE

• 挖掘步骤：(按照实际情况来，这里只是大概说下)

• 定位模板渲染函数调用点（如Freemarker的template.process()、Jinja2的render_template_string()）

• 追踪模板内容或模板参数的来源，判断是否用户可控

• 分析模板引擎的语法，构造模板注入payload，验证是否能执行代码

Jinja2模板注入简单示例：from flask import Flask, requestfrom jinja2 import Templateapp = Flask(__name__)@app.route('/')def index():    # 模板内容来自GET参数name，用户可控    name = request.args.get('name')    template = Template("Hello, " + name) # 直接拼接用户输入为模板    return template.render()if __name__ == '__main__':    app.run()# 构造name参数：?name={{__import__('os').popen('whoami').read()}}# 模板引擎会解析{{}}中的代码，执行whoami并返回结果

框架注入RCE漏洞挖掘

• 若目标系统使用开源框架/组件，除了关注业务代码，还需审计框架/组件的内置代码，寻找未被修复的RCE漏洞
• Struts2框架：审计OGNL表达式解析逻辑，寻找用户输入未被过滤直接注入OGNL表达式的场景
• Spring框架：审计SpEL表达式解析逻辑、JndiTemplate.lookup()调用场景
• CMS系统（如WordPress、Dedecms）：审计插件接口、主题模板渲染逻辑、文件上传处理逻辑

白盒挖掘常用工具

• 代码编辑与搜索工具：PyCharm（Python项目）、IntelliJ IDEA（Java项目）、PhpStorm（PHP项目）、VS Code（多语言支持）——提供全局搜索、变量追踪、代码跳转功能
• 静态代码分析工具：CodeQL（支持多语言，可自定义查询规则挖掘RCE漏洞）、FindSecBugs（Java项目静态分析）、PHP_CodeSniffer（PHP项目代码规范与漏洞检测）、Bandit（Python项目安全分析）
• 反序列化漏洞工具：ysoserial（Java反序列化gadgets生成工具）、PHP反序列化漏洞检测脚本、pickletools（Python pickle反序列化分析）
• 辅助工具：Sublime Text（轻量级代码编辑与搜索）、Git（查看代码提交历史，寻找漏洞修复记录）

白盒挖掘注意事项

• 关注“间接输入”：用户输入可能经过多轮函数传递、数据库存储/读取后才到达危险函数，需完整追踪输入流向，避免遗漏
• 区分“危险函数的安全调用”与“不安全调用”：固定参数的危险函数调用（如system(“ls -l”)）无风险，仅变量参数且用户可控的调用才需关注
• 结合业务逻辑：部分漏洞需特定业务场景触发（如用户登录后才能访问的接口、特定权限下的操作），审计时需结合业务流程
• 参考漏洞修复记录：对于开源项目，可查看历史漏洞修复代码（如GitHub的commit记录），学习漏洞挖掘思路，寻找类似未修复漏洞

黑盒与白盒挖掘的结合策略

• 前提条件：能拿到黑盒对应的代码，至于如何拿到，方法很多，如GitHub、供应商、某些网站上提供等

• 黑盒与白盒挖掘并非孤立，结合使用可大幅提升RCE漏洞挖掘效率：

• 黑盒定位攻击面，白盒深入分析：通过黑盒测试找到潜在RCE漏洞点（如ping功能、文件上传功能），再通过白盒审计对应功能的源代码，精准定位漏洞根源（如输入过滤缺陷、危险函数调用）

• 白盒发现漏洞，黑盒验证利用：通过白盒审计发现隐藏的RCE漏洞（如未对外开放的接口、逻辑复杂的反序列化漏洞），再通过黑盒测试构造输入验证漏洞的可利用性

• 互补覆盖漏洞场景：黑盒擅长发现“对外开放的常规漏洞”（如命令执行、文件上传），白盒擅长发现“隐藏的逻辑漏洞”（如反序列化、模板注入），结合使用可覆盖更多漏洞场景

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：一个努力的学渣 一个努力的学渣《RCE安全（五）》