简介面向WebLogic运维与安全加固人员这份资料围绕63个CVE编号梳理了WebLogic历史上的漏洞修复情况覆盖反序列化、远程代码执行、信息泄露与拒绝服务等典型风险适合需要排查补丁缺口、评估系统安全状态的中高级运维与安全从业者参考。压缩包共1个docx文档约1.93MB以清单加分类说明的形式组织便于按年份与漏洞类型快速检索。内容按CVE分组展开涉及2011至2017年间的高危漏洞如CVE-2016-0638、CVE-2015-7501等反序列化问题以及CVE-2017-3248、CVE-2017-5638等组件风险并提及10.3.5核心系统已打L5TD补丁的实际场景可帮助读者对照自身环境判断修复优先级。目前已有1355人学习下载适合作为漏洞自查与补丁管理的案头参考。1. 补丁打过了扫描器还是报 CVE-2016-0638WebLogic 漏洞统计最容易踩的坑一台跑着 10.3.5 的核心系统L5T 补丁包已经打上运维在管理控制台里翻来覆去确认过版本号可安全扫描报告一出来CVE-2016-0638、CVE-2016-3416、CVE-2015-7501 这一串反序列化漏洞照样红着。这种「补丁打了、扫描还报」的场面在 WebLogic 漏洞统计和安全修复里太常见了折腾人的地方不在于漏洞本身多难修而在于你根本不知道扫描器到底在测什么、补丁到底覆盖了哪几个 CVE。手里攥着一份 63 条的 CVE 清单从 2011 年的 CVE-2011-1411 一直排到 2017 年的 CVE-2017-10352逐条去查修复状态没有对照表就是纯体力活。这篇笔记面向正在被 WebLogic 漏洞清单卡住的开发和运维把「为什么报了没修掉」「怎么定位根因」「怎么按清单逐条核对」讲透让你拿着这份统计资源就能把账对平。2. 反序列化漏洞反复报CVE-2015-7501 与 CVE-2016-0638 为什么修不干净WebLogic 的 CVE 清单里反序列化类漏洞占了相当大的比重CVE-2015-7501、CVE-2016-0638、CVE-2016-3416、CVE-2017-3248、CVE-2017-3506 都属于这一类。它们的共同特征是攻击者构造一段恶意序列化数据通过 T3、IIOP 或者 HTTP 协议送进服务器服务器在反序列化时触发 gadget 链最终执行任意代码。很多人以为打个补丁就完事结果扫描器换个检测方式又报出来根因往往不在补丁本身而在补丁的覆盖范围和运行态的实际加载情况对不上。2.1 补丁覆盖的是类不是「这个 CVE 已关闭」Oracle 的补丁机制是按组件和类打补丁的一个 CPU 补丁包可能同时修复多个 CVE也可能只修了某个 CVE 的一部分攻击面。以 CVE-2015-7501 为例它本质上是 Commons Collections 反序列化链的问题修复方式是在 WebLogic 的过滤机制里加黑名单而不是把 Commons Collections 整个删掉。所以你在版本号上看到 10.3.5 加 L5T只能说明补丁包装了不能说明运行中的每个受管服务器都加载了新的过滤类。常见做法是先确认补丁在文件系统层面是否真的落地再确认运行态是否加载。下面这段命令用来核对补丁目录和 jar 的时间戳是我排查「补丁打了没生效」时的第一步# 进入 WebLogic 补丁根目录10.3.5 的典型路径 cd /u01/app/oracle/middleware/utils/bsu/cache_dir # 列出已安装补丁清单确认 L5T 及其包含的子补丁 ls -lt *.jar | head -20 # 检查补丁是否解压到 modules 目录重点看过滤相关 jar 的修改时间 ls -l /u01/app/oracle/middleware/wlserver_10.3/server/lib/ | grep -i filter第一段ls -lt按时间倒序列出补丁缓存能看出最近一次打补丁是什么时候、装的是哪个包第二段查server/lib下的过滤相关 jar如果时间戳还是几年前的说明补丁虽然进了 cache_dir但没有真正应用到 wlserver 的类路径里。参数上要注意middleware路径随安装方式不同会变有的环境是/u01/app/oracle/product/先用find / -name bsu -type d定位再操作别照抄路径。2.2 受管服务器没重启补丁等于没打这是血泪经验里最冤的一种。管理服务器重启了受管服务器还在跑旧进程类加载器里持有的还是旧版本的过滤类。扫描器打的是受管服务器端口自然照样报漏洞。判断方法很直接看进程启动时间和补丁安装时间的先后。# 查看所有 WebLogic 进程的启动时间 ps -eo pid,lstart,cmd | grep -i weblogic | grep -v grep # 对比补丁 jar 的修改时间 stat -c %y %n /u01/app/oracle/middleware/wlserver_10.3/server/lib/*filter*.jarps的lstart输出完整启动时间如果进程启动时间早于补丁 jar 的修改时间说明这个进程没吃到补丁。解决方式是按受管服务器逐个重启不要图省事只重启管理节点。重启顺序上先停受管再停管理启动时反过来这是 WebLogic 的老规矩顺序错了会出现节点无法纳管的情况。2.3 T3 协议开着补丁修了也白修CVE-2016-0638 这类漏洞的入口是 T3 协议。补丁修的是反序列化过滤但如果 T3 对外网开放攻击面依然存在扫描器会持续判定为高风险。很多内网系统觉得「反正内网」但漏洞统计报告是按暴露面算分的。收敛方式是在控制台里限制 T3 的连接来源或者通过连接筛选器只放行可信网段。# 在 config.xml 中确认是否配置了连接筛选器 grep -i connection-filter /u01/app/oracle/middleware/user_projects/domains/base_domain/config/config.xml如果这条 grep 没有任何输出说明没配连接筛选器T3 对所有能访问 7001 的来源开放。补全方式是在控制台的「环境 - 服务器 - 协议」里配置连接筛选器或者在config.xml的 server 节点下加connection-filterweblogic.security.net.ConnectionFilterImpl/connection-filter再配config.xml同目录的net.properties规则文件。改完必须重启对应服务器规则才生效。这一步做完扫描器对反序列化类漏洞的评级通常会降下来因为攻击路径被收窄了。3. 版本对不上号CVE-2014-4210 到 CVE-2013-2390 的清单核对方法63 条 CVE 里2013 到 2014 年那批CVE-2013-1504、CVE-2013-2390、CVE-2014-2479、CVE-2014-2480、CVE-2014-4210、CVE-2014-4241、CVE-2014-4253 一直到 CVE-2014-4267最容易在核对时翻车。原因是这批漏洞横跨多个 CPU 季度补丁有的在 10.3.5 的早期补丁里修了有的要等到后续的 L5T 甚至更高补丁级别。手里只有一份 CVE 编号清单没有「哪个补丁修了哪条」的映射核对就变成了猜。3.1 用补丁 README 反查 CVE而不是靠记忆Oracle 每个补丁包解压后都带 README里面列了修复的 bug 号和对应的 CVE。这是最权威的对照来源比任何第三方统计都准。操作方式是把补丁包解开grep CVE 编号。# 解压补丁包到临时目录不要动生产目录 mkdir -p /tmp/patch_check cd /tmp/patch_check unzip -o /u01/app/oracle/middleware/utils/bsu/cache_dir/*L5T*.jar -d ./l5t # 在 README 里反查某个 CVE 是否被这个补丁覆盖 grep -r CVE-2014-4210 ./l5t/README.txt grep -r CVE-2013-2390 ./l5t/README.txtunzip -o的-o是覆盖已存在文件避免交互卡住-d指定解压目录一定要放/tmp这类临时位置别解到 middleware 目录里污染生产环境。grep 命中说明这个补丁的 README 里明确列了该 CVE没命中不代表一定没修可能是 README 只列 bug 号不列 CVE这时要拿 bug 号去反查。我一般会把 63 条 CVE 做成一张表逐条标注「在哪个补丁 README 里命中」命中的打勾没命中的单独列出来重点跟进。3.2 版本号相同不代表补丁级别相同10.3.5 是一个大版本后面跟着不同的补丁级别。两台都显示 10.3.5 的服务器一台打了 L5T一台只打到更早的补丁漏洞状态完全不同。核对时不能只看版本号要看补丁级别。# 查看当前 WebLogic 的补丁级别 cd /u01/app/oracle/middleware/utils/bsu ./bsu.sh -view -statusapplied -prod_dir/u01/app/oracle/middleware/wlserver_10.3-view是查看模式-statusapplied只看已应用的补丁-prod_dir指向 wlserver 安装目录。输出里会列出每个已应用补丁的编号和描述。把这份输出和 CVE 清单对照才能确定「这台机器到底修到哪一步」。如果输出里只有零星几个补丁而清单里有 2017 年的 CVE那基本可以判定这些 2017 年的漏洞CVE-2017-3248、CVE-2017-3506、CVE-2017-10063 等在这台机器上没修需要评估升级或打更高补丁。3.3 清单里混入了非 WebLogic 组件的 CVE63 条里有几条需要特别留意归属。CVE-2017-5638 是 Struts2 的漏洞CVE-2014-3566 是 SSLv3 的 POODLE 问题CVE-2011-5035 涉及哈希碰撞。这些不是 WebLogic 自身代码的漏洞而是 WebLogic 运行环境里依赖的组件或协议配置问题。核对时如果拿 WebLogic 补丁去对这几条永远对不上会误判成「补丁缺失」。处理方式是分类核对WebLogic 自身漏洞走补丁 README 反查依赖组件漏洞如 CVE-2017-5638查应用侧引入的 jar 版本协议配置类如 CVE-2014-3566查config.xml里的 SSL 协议配置确认是否禁用了 SSLv3。分类之后63 条清单才不会变成一锅粥。4. 扫描器报的和你修的不是一回事CVE-2017-3506 与 CVE-2016-5531 的误报排查安全扫描器的工作原理是发探测包、看响应特征它不读你的补丁 README。所以经常出现「补丁确实修了扫描器还报」的误报也出现「扫描器没报实际还开着口子」的漏报。CVE-2017-3506T3 反序列化和 CVE-2016-5531T3 相关这类漏洞扫描器往往只根据端口开放和协议响应就下结论不区分补丁级别。4.1 先确认扫描器测的是哪个端口、哪个协议拿到扫描报告第一件事不是去翻补丁而是看报告里的目标地址和端口。WebLogic 的管理端口常见 7001和受管端口、以及是否开了 T3决定了扫描器的判定逻辑。如果报告指向的是一个已经下线的旧节点或者指向的是负载均衡后面的某个实例修错对象就白忙。# 确认本机监听的 WebLogic 相关端口 netstat -tlnp | grep -E 7001|7002|7003 # 确认 T3 是否在响应用 nc 探测不要用生产凭据 echo | nc -w 3 127.0.0.1 7001 | head -c 200netstat的-tlnp分别表示 TCP、监听、数字端口、进程能看出哪个进程占了哪个端口。nc -w 3是 3 秒超时探测返回内容里如果出现HELLO之类的 T3 握手特征说明 T3 在响应。这一步的目的是把「扫描器说的目标」和「实际在跑的服务」对齐对齐之后再看补丁才不会修错地方。4.2 用官方公告的受影响版本区间做二次判定每条 CVE 在官方公告里都有受影响版本区间。CVE-2017-3506 影响的是特定版本段如果你的 10.3.5 已经打到包含该修复的补丁级别就属于误报。判定方法是把bsu.sh -view的输出和公告的修复版本对照。这一步不需要联网查把公告里的版本信息整理进你的 CVE 对照表即可。我一般会在对照表里加三列受影响版本、修复补丁号、本机是否命中。命中且已打补丁的标「已修」命中但没打补丁的标「待修」不在受影响区间的标「不适用」。63 条走完一遍待修清单通常只剩个位数后续跟进就有了明确目标不用再对着整份清单焦虑。4.3 误报要留证据别只口头说「修了」扫描器误报在合规检查里是要有交代的。做法是把补丁 README 命中记录、bsu.sh -view输出、端口收敛配置截图整理成一个证据包按 CVE 编号归档。下次扫描再报同一条直接拿证据包回应不用重新排查一遍。这个习惯看起来笨但能省下大量重复劳动尤其是季度扫描这种周期性任务。5. 避坑清单WebLogic 漏洞统计里最容易翻车的五个点5.1 只重启管理服务器受管服务器还在跑旧类现象补丁装完管理控制台显示正常扫描器对受管节点照样报反序列化漏洞。原因受管服务器是独立 JVM类加载器不会因为管理节点重启而刷新。解决按节点逐个重启重启后用ps -eo pid,lstart核对进程启动时间晚于补丁时间。5.2 把 CVE-2017-5638 当成 WebLogic 补丁问题现象清单里 CVE-2017-5638 一直标红翻遍 WebLogic 补丁 README 找不到。原因这是 Struts2 的漏洞属于应用依赖组件不在 WebLogic 补丁范围内。解决转到应用侧查WEB-INF/lib下的 struts 相关 jar 版本升级对应依赖别在 WebLogic 补丁上死磕。5.3 补丁包装了但没 apply现象cache_dir里有补丁 jarbsu.sh -view却看不到。原因补丁只是下载到缓存目录没有执行 apply 动作。解决用bsu.sh -install -patchlist补丁号 -prod_dirwlserver路径正式应用应用后再-view确认。5.4 连接筛选器配了但规则文件没生效现象config.xml里加了 connection-filterT3 还是能被外部探测到。原因规则文件net.properties路径或格式不对或者改完没重启。解决确认规则文件与管理服务器同域目录格式为「目标网段 本机网段 允许/拒绝」改完重启对应服务器。5.5 拿版本号当补丁级别用现象两台都是 10.3.5一台安全一台报漏洞核对时懵了。原因10.3.5 是版本号补丁级别是另一套编号如 L5T。解决统一用bsu.sh -view -statusapplied的输出做对照版本号只用来判断大版本兼容性。6. 快速定位拿到一份 CVE 清单后我固定走的四步第一步永远是分类不是逐条查。把 63 条按性质分成三类WebLogic 自身代码漏洞反序列化、T3、IIOP 相关占大多数、依赖组件漏洞CVE-2017-5638 这类、协议配置类CVE-2014-3566 这类。分类之后每一类走不同的核对路径避免用错工具白费力气。第二步是建立对照表字段固定为CVE 编号、受影响版本、修复补丁号、本机补丁级别、是否命中、证据位置。这张表是整件事的核心后面所有判断都基于它。下面是我常用的表结构可以直接照着建CVE 编号类型修复补丁本机是否命中状态CVE-2015-7501反序列化L5T 及后续是已修留 README 证据CVE-2016-0638反序列化L5T 及后续是已修需确认 T3 收敛CVE-2017-3506T3 反序列化更高补丁级别是待评估升级CVE-2017-5638依赖组件非 WebLogic 补丁视应用而定转应用侧核对CVE-2014-3566协议配置配置项是禁用 SSLv3 即可第三步是运行态验证不信任任何静态信息。补丁装了要看进程启动时间配置改了要看端口响应T3 收敛了要用nc探测确认。静态信息版本号、配置文件内容只能作为线索运行态才是结论。第四步是把证据固化下来。每条「已修」的 CVE 都对应一个证据位置README 命中行号、bsu.sh -view输出片段、端口探测结果。下次扫描再报直接调证据不重复排查。这套流程走下来一份 63 条的清单通常两三个小时能对完待修项收敛到个位数。从那以后我每次拿到 WebLogic 漏洞统计清单都强制先分类再建表绝不逐条硬查——逐条查看着勤快实际上是在用体力掩盖方法问题。希望这份整理能帮到你把手里那份清单真正对平。本文还有配套的精品资源点击获取
