尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

SSRF漏洞实战:从pikachu靶场到curl_exec与file_get_contents的深度利用

SSRF漏洞实战:从pikachu靶场到curl_exec与file_get_contents的深度利用 1. SSRF漏洞初探从靶场搭建到漏洞复现第一次接触SSRF漏洞是在一次内部安全测试中当时发现一个看似无害的功能点竟然能读取服务器本地文件。这种从内部攻破的特性让我对SSRF产生了浓厚兴趣。今天我们就用pikachu这个经典的漏洞靶场带大家亲手复现这个危险的漏洞。搭建环境其实比想象中简单。下载pikachu-master.zip后解压到Web服务器目录我习惯用phpstudy_pro的WWW文件夹。修改config.inc.php中的数据库配置时要注意MySQL密码复杂度要足够否则可能被暴力破解。启动服务后遇到404错误别慌这是很多新手都会踩的坑。我花了半小时排查发现是路径问题修改ssrf_curl.php和ssrf_fgc.php中的相对路径为绝对路径就解决了。2. curl_exec漏洞深度解析2.1 漏洞原理与函数特性点击靶场的SSRF(curl)选项那个累了吧来读一首诗吧的界面背后藏着危险。查看源代码会发现关键点前端传递url参数后端用curl_exec执行请求。这个函数就像个万能请求器支持HTTP、FTP甚至FILE等20多种协议。我做过一个实验在WWW目录创建test.txt写入敏感数据然后访问?urlfile:///E:/phpstudy_pro/WWW/test.txt结果直接显示了文件内容这说明curl_exec未做任何协议限制时攻击者可以像用钥匙开锁一样读取服务器任意文件。2.2 内网探测实战技巧更危险的是dict协议的应用。有次渗透测试中我用以下payload探测到内网Redis服务?urldict://192.168.1.100:6379/info返回的Redis版本信息直接暴露了未授权访问漏洞。在pikachu环境中尝试扫描3306端口?urldict://127.0.0.1:3306如果返回MySQL的banner信息说明数据库端口暴露这为后续攻击打开了大门。我曾用这个方法在测试环境发现过暴露的Memcached服务。3. file_get_contents的另类利用3.1 协议处理差异分析转到SSRF(file_get_content)选项背后的file_get_contents函数行为与curl_exec有所不同。虽然也能读取文件但对协议的支持更有限。不过它有个致命特性可以与php://filter组合使用实现文件读取。有次审计代码时发现这样的危险用法$content file_get_contents($_GET[file]);通过构造特殊payload就能读取源码?filephp://filter/readconvert.base64-encode/resourceconfig.php返回的base64编码内容解码后就是配置文件原文数据库密码一览无余。3.2 实际漏洞利用对比在真实漏洞利用中我发现两个函数的区别很明显curl_exec支持更多协议如dict探测端口file_get_contents配合php://filter更适合源码泄露curl_exec默认跟随302跳转可能绕过某些防护去年遇到一个案例某CMS同时使用这两个函数处理不同功能攻击者先用file_get_contents泄露路径再用curl_exec进行内网渗透形成了完整的攻击链。4. 高级利用与防御实践4.1 非常规协议利用技巧除了常见的file、dict协议gopher协议才是SSRF的大杀器。虽然pikachu默认不支持但在真实环境中我曾用gopher协议构造HTTP请求攻击内网Jenkinsgopher://127.0.0.1:8080/_POST%20/job/test/build%20HTTP/1.1这种攻击可以直接触发CI/CD流程危害极大。另外某些环境下ftp协议可以用来测试SSRF的端口开放情况。4.2 企业级防御方案在给客户做安全加固时我总结出几个有效方法协议白名单只允许http和https域名校验禁止IP地址和内部域名输出过滤移除响应中的敏感信息网络隔离关键服务使用独立网络有次应急响应中发现攻击者利用SSRF访问了metadata服务获取云服务器临时凭证。后来我们通过iptables规则阻断了实例元数据访问彻底解决了这类问题。5. 从靶场到实战的思考在真实渗透测试中SSRF往往不是独立存在的。去年某个项目里我先通过XSS获取了管理员cookie然后利用后台的SSRF功能扫描内网最终通过Redis未授权访问拿下了整个集群。这种组合拳攻击现在越来越常见。调试SSRF漏洞时有个小技巧使用Burp Collaborator服务观察带外请求。有次我发现某个看似修复的SSRF点其实只是过滤了http://改用https://就绕过了。这种细微差别在自动化扫描中很容易被忽略。
返回列表