HW高危漏洞自查：21个必修漏洞的排查与修复实战指南

简介《2024HW必修高危漏洞集合-v4.0》是斗象情报中心面向企业安全团队与HW攻防演练参与者整理的高危漏洞自查手册聚焦2023年1月至7月攻防演练中红队利用率高、对企业危害较大的漏洞类型涵盖远程代码执行、命令注入、任意文件上传与SQL注入四大类可帮助企业在演练前期完成风险排查、封堵策略配置与漏洞修复。资源为单个PDF文件大小2.92MB内文按漏洞类型统计了远程代码执行11个、命令注入5个、任意文件上传3个、SQL注入2个具体涉及Apache NiFi、ManageEngine、Adobe ColdFusion、瑞友天翼、PowerJob、DedeCMS、大华股份、SugarCRM、Weblogic、禅道、TP-Link、VMware、海康威视等产品每个漏洞均附基础信息、影响版本、检测规则和修复建议目录结构清晰便于按资产情况快速定位。目前已有223人学习下载适合安全运维、蓝队人员及等保自查场景也可作为安全培训与应急响应的参考材料帮助企业在HW前降低“城池失守”风险。1. HW 前夕的高危漏洞自查这份 4.0 手册能帮你堵住哪个口子HW 攻防演练的防守准备里高危漏洞自查是最容易被低估的一项。每年演练期间红队突破边界用的几乎都是已知高危漏洞而企业经常栽在同一个问题上漏洞列表看了一大堆却不知道哪些资产可能中招、该按什么顺序修。斗象发布的《2024HW必修高危漏洞集合_v4.0》整理了 2023 年 1 月至 7 月在攻防演练中被利用最频繁的 21 个高危漏洞覆盖远程代码执行、命令注入、任意文件上传、SQL 注入四类涉及 Apache、ManageEngine、Adobe、瑞友天翼、大华、泛微、禅道等厂商。这篇笔记不做科普目标是带你把这份手册变成一张能直接分发给运维和安全的自查清单。2. 21 个漏洞怎么排优先级按红队利用频率和暴露面做自查打分这份手册的目录结构本身就说明了一个判断21 个漏洞不是平行罗列的。远程代码执行占 11 个命令注入占 5 个任意文件上传占 3 个SQL 注入只有 2 个。这个比例背后是红队的攻击链偏好——能直接拿到命令执行权限的漏洞永远比需要多层组合的漏洞更受欢迎。所以自查的时候不能平均用力得先按类型和暴露面给每个漏洞打分排序。2.1 漏洞类型分布RCE 占了一半暴露的是攻击链偏好把手册里的漏洞按类型拆开看分布情况很清楚漏洞类型数量涉及厂商远程代码执行11Apache、ManageEngine、Adobe、瑞友天翼、PowerJob、DedeCMS、大华、SugarCRM、Oracle命令注入5禅道、TP-Link、VMware、Apache、nginx任意文件上传3海康威视、泛微、大华SQL 注入2泛微、畅捷通远程代码执行占了一半以上这不是巧合。攻防演练里红队的第一目标是拿到边界设备的权限RCE 类型漏洞只要打穿就是命令执行结果连横向的功夫都省了。任意文件上传虽然数量少但海康威视、大华这类安防设备在企业内网里非常常见一旦上传接口被用来落地 Webshell基本意味着安防系统本身已经不可信。SQL 注入只有两个但涉及泛微 e-cology 和畅捷通 T这俩都是国内企业办公和财务的高频系统命中后的影响面不小不能因为数量少就跳过。2.2 影响版本怎么读先把命中的资产圈出来版本判断是这份手册使用中最容易翻车的地方原因在于几个厂商的版本号体系完全不是常规的主版本.次版本。以 ManageEngine 为例手册里列的 7080、7161、6210 这些数字并不是版本号而是各产品对应的 Build 号。如果只登录控制台看一个大版本号很容易得出我的版本不在影响范围的错误结论。判断版本是否命中正确的做法是进入产品后台的 About 页面读取完整的 Build 号再和手册给出的阈值逐位比较。先确认资产上跑的组件再谈版本。实操里我一般先用两条命令快速摸底# 通过响应头判断组件类型适合做第一轮资产指纹 curl -sI http://目标IP:端口/ | grep -iE server|x-powered-by|via # 有登录入口的先看登录页特征很多产品登录页会带版本号 curl -s http://目标IP:端口/ | grep -iE version|release|build提示curl 拿到的 Server 头可能被管理员改过或者被 WAF 隐藏。这个阶段的作用是做初筛最终版本确认还是得走登录后台或读安装目录下的版本文件。版本边界的符号也要扣准确。手册里 Apache NiFi 写的是 0.0.2 版本 1.21.0说明 1.21.0 本身就在受影响范围内Apache Solr 写的是 8.10.0 版本 9.2.0说明 9.2.0 是安全版本等于 8.10.0 的也中招。这种左闭右开和左右全闭的区别直接决定了你资产清单里哪一批机器要进紧急处置队列。2.3 自查优先级打分边界资产优先别平均用力资产多的企业不可能 21 个漏洞同时开修必须分优先级。我一般按三个维度打分漏洞类型权重RCE 10 分、命令注入 8 分、文件上传 7 分、SQL 注入 6 分、是否公网暴露、资产在业务链路里的重要性。打分后的处置策略按三档走P0公网可直达且权重分高的漏洞当天完成封堵或升级例如暴露在公网的 Apache NiFi、Solr、瑞友天翼。P1内网核心资产命中版本区间三到五个工作日内处理例如内网部署的泛微 e-cology、大华智慧园区。P2版本命中但当前没有暴露面记录在册等窗口期统一升级。注意P2 不代表可以不管。HW 期间红队一旦找到一条跳板进入内网P2 的资产就会瞬间变成 P0。清单里每一台命中资产都要有明确负责人和整改时间。3. 远程代码执行漏洞自查从检测路径反推攻击链并落地修复远程代码执行是这份手册里最重的一部分。与其对着 CVE 编号一个个背不如反过来用检测路径理解攻击动作手册里给的每一条检测路径都是漏洞触发的关键入口。流量侧看到这些路径意味着有人在尝试探测或利用自查的第一反应应该是这个请求到没到业务后端、有没有成功返回。3.1 检测路径的用法每条路径对应一段可观测的攻击动作把手册里有明确检测路径的 RCE 漏洞按入口特征分组看会清晰很多。管理接口类入口的攻击动作最直接。Apache NiFi 的/nifi-api/process-groups/root是流程组信息的查询接口而漏洞本质是 DBCPConnectionPool 和 HikariCPConnectionPool 允许用户用 H2 驱动配置数据库 URL从而执行自定义代码攻击者先通过这个 API 定位目标再通过配置接口写入恶意 URL。Apache Druid 的/druid/indexer/v1/sampler?for是采样接口配合恶意文件上传触发。PowerJob 的/api/worker/execute是未授权接口直接提交 Java 代码片段就能执行。大华智慧园区的/admin/user_save.action落在用户管理模块攻击者用它上传带 Webshell 的 JSP 文件后拿到执行权限。单点登录和服务入口类也很有代表性。ManageEngine 的/SamlResponseServlet是 SAML 响应接收点漏洞根因是改动了 Apache Santuario 这个老依赖攻击者构造恶意 SAML 响应就能触发。瑞友天翼的/AgentBoard.XGI?user是应用虚拟化客户端的接入入口这条路径被请求时携带的 user 参数需要特别关注。Adobe ColdFusion 的/cf_scripts/scripts/ajax/ckeditor/plugins/filemanager/iedit.cfc?method走的是编辑器插件的老路径属于典型的功能即漏洞。搜索配置类入口里Apache Solr 的/solr/admin/configs?action是 SolrCloud 模式下的配置管理接口手册里明确说明利用前提是开启 solrcloud 且出网这两点缺一不可。DedeCMS 的dede/article_allowurl_edit.php是后台允许 URL 写入的功能攻击者先把恶意文件地址写进去再触发上传。3.2 RCE 漏洞影响版本与修复动作清单RCE 漏洞的自查最终要落到这个版本到底修没修上清单如下漏洞影响版本修复动作Apache NiFiCVE-2023-344680.0.2 NiFi 1.21.0升级到最新 release默认配置中禁用 H2 JDBC URLManageEngineCVE-2022-47966多产品 Build 号范围内按官方 CVE 公告逐产品升级限制管理界面访问Adobe ColdFusionCVE-2023-263602018 Update 152021 Update 5安装 APSB23-25 对应补丁瑞友天翼5.x 版本 7.0.2.1联系厂商获取修复版本Apache SolrCNVD-2023-275988.10.0 Solr 9.2.0升级到 9.2.0 及以上Apache Druid 25.0.0启用 basic security限制 sampler 接口PowerJobCVE-2023-29926V4.3.2升级新版本为 /api/worker/execute 加认证DedeCMSCVE-2023-2928 5.7.106升级最新版本限制上传类型大华智慧园区 V3.001.0000004.18.R.2223994安装官方安全补丁限制文件上传SugarCRMCVE-2023-22952 12.0.2 11.0.5升级对应大版本补丁WebLogicCVE-2023-2183912.2.1.3.012.2.1.4.014.1.1.0.0安装 Oracle 最新季度补丁这里有个容易被忽略的细节修复不只看核心组件版本还要看依赖。ManageEngine 那个漏洞的根因是 Apache Santuario 依赖如果不升级依赖只换了主程序外壳检测路径依然可能命中。所以修复动作完成后一定要用手册里的检测路径回放一遍确认返回结果从可访问变成了403/404/401中的任意一个。3.3 临时止血无法升级时先封什么演练前一周才拿到手册的情况很常见有些核心业务系统根本不允许临时停机升级。这时候要做的是临时止血把攻击者的请求挡在业务前面。我的习惯是先封检测路径再限制管理端来源 IP最后切断不必要的出网。以 Nginx 反代场景为例# 封堵关键检测路径按实际部署前缀调整 location ~ ^/(nifi-api/process-groups/root|SamlResponseServlet|AgentBoard\.XGI) { deny all; return 403; } # 管理端只允许办公网段访问 location ~ ^/(admin|dede|solr/admin) { allow 10.0.0.0/8; deny all; }注意封检测路径之前先在一台测试机确认这条规则不影响正常业务。比如瑞友天翼的 /AgentBoard.XGI 是客户端正常接入入口直接 deny 会导致远程办公用户连不上这种情况应该改成白名单 IP 准入而不是一刀切。出网限制往往被忽略。Apache Solr 的利用前提是目标能出网PowerJob 的执行结果也要回传如果业务架构允许在防火墙上把这几个组件的主动外连全部断开等于砍掉了漏洞利用的回传通道即使被写入代码也拿不到结果。这是我在多个项目里验证过最有效的临时缓解手段。4. 命令注入与文件上传漏洞检测规则和封堵动作一次说清命令注入和任意文件上传在手册里占了 8 个数量不如 RCE 多但这两类漏洞有一个共同特点利用成功的标志往往是一个新文件的出现。所以自查思路要从看请求切换到看结果——查上传目录、查落地文件、查进程行为。4.1 命令注入漏洞的自查思路版本命中和日志特征并查手册里的 5 个命令注入漏洞分布在禅道、TP-Link、VMware、Apache Solr、nginxWebUI 上影响版本分别是禅道开源版 17.4 到 18.0.beta1、旗舰版 3.4 到 4.0.beta1、企业版 7.4 到 8.0.beta1TP-Link Archer AX21 低于 1.1.4 Build 20230219VMware Aria Operations for Networks 6.xApache Solr 不高于 8.3.1nginxWebUI 不高于 3.4.6。这五个漏洞手册里没有给出统一的检测路径因为命令注入的触发点散在各产品的参数里没法用一个固定路径覆盖。我一般分两步查第一步确认版本是否命中第二步在访问日志里筛近期异常的请求参数——分号、管道符、$()这类 shell 元字符密集出现的请求要单独拉出来看。这只是排查痕迹的手段不能直接断定漏洞被利用过但至少能发现可疑线索。排查时的通用命令思路是先把命中的资产数量摸清# 用 nmap 扫一遍内网网段的端口指纹再和手册版本边界比对 nmap -sV -p 80,443,8080,8443 10.0.0.0/24 -oN asset_version.txt # 筛选日志中带 shell 元字符的请求注意时间范围对齐演练期 grep -E (\||;|\$\(|) /var/log/nginx/access.log | grep -v 静态资源后缀提示nmap 扫出来的版本号只能做参考部分产品会在 HTTP 头里隐藏真实版本。命中的判定最终以厂商发布公告里的版本对照表为准。4.2 任意文件上传漏洞文件落到哪、能不能执行是关键三个文件上传漏洞对应的是海康威视 iVMS-8700 综合安防管理平台、泛微 e-cology9低于 10.58.3以及大华智慧园区CVE-2023-38362023-07-13 之前发行版本。这类漏洞的共性问题是上传接口没有校验文件类型或者校验可以被绕过导致 JSP、PHP 文件直接落到 Web 目录。自查文件上传漏洞核心不是看上传请求本身而是看两个问题上传目录和 Web 执行目录是否重叠以及目录里有没有近期新增的可疑脚本文件。比如# 在应用部署根目录下找最近 30 天内新增的可执行脚本 find /应用部署目录 -name *.jsp -newer /tmp/基线文件.txt 2/dev/null # 列出上传目录下所有非正常图片/文档后缀的文件 ls -la /应用部署目录/upload/ | grep -iE \.(jsp|jspx|php|asp|aspx)$安防平台这类系统有个特殊点它们往往同时承担着视频流和 Web 管理功能Web 目录旁边就是录像存储目录硬盘空间大、文件多混一个 JSP 进去非常隐蔽。所以查的时候不能只查 upload 目录整个 Web 应用目录都要覆盖。4.3 用 WAF 和防火墙先挡住明显攻击在补丁到位之前对已知的文件上传入口做前置封堵是性价比最高的动作。以 Nginx 层面对上传接口的管控为例思路是上传接口只允许来自业务网段的请求同时用 WAF 规则拦截可执行文件后缀。location ~ ^/(admin/user_save|upload)\.action { # 只允许办公网段调用管理接口 allow 10.0.0.0/8; deny all; } location ~* \.(jsp|jspx|php|asp|aspx)$ { # 对 Web 目录下可执行文件的访问做拦截先放行静态资源 if ($request_uri ~* /upload/) { return 403; } }这些配置属于应急缓解真正解决还是要靠官方补丁。海康和大华的产品补丁通常在厂商技术支持页面发布联系对应项目负责人拿补丁包最直接。5. HW 漏洞自查避坑指南版本判断、路径检测和修复中的五个翻车点手册本身写得清楚但我在实际推这个清单的过程中还是踩了不少坑。这里整理五个最容易翻车的点每一条都是真实项目里遇到过的情况。5.1 现象检测路径一命中就判定漏洞存在误报一片把手册里的路径直接写进 WAF 监控规则后内网一天报了上百条。原因是很多路径本身就是管理后台的正常功能入口比如/nifi-api/process-groups/root运维日常排查也会访问返回了 200 就被判定为攻击。原因只看路径命中没有结合返回状态码和响应内容。漏洞利用请求和正常访问的关键区别在于请求参数和响应特征而不仅仅是路径本身。解决检测规则改成三层校验——路径命中、返回状态码符合预期、响应体包含特定接口特征才告警。比如 NiFi 的接口正常返回会带 processGroup 相关字段ColdFusion 的 iedit.cfc 接口要看 method 参数是否发生调用。规则上线前先在一台干净环境手动访问一次记录基线。5.2 现象版本判断错位把 Build 号当版本号ManageEngine 那串数字4307、7080、7161是 Build 号不是常规版本号。有同事拿着 12.x 的版本号对比手册直接得出不在影响范围的结论实际对应的 Build 号早就在阈值以下了。原因厂商版本命名体系混乱手册又保留了原始写法没有统一成一套可排序的格式。解决对这类产品进入后台 About 页面读取完整 Build 号后台进不去就看安装目录下的build.properties或者补丁记录文件别只看登录页的大版本号。5.3 现象补丁打了服务没重启检测路径一打还是通的某台泛微 e-cology9 升级到了安全版本但访问原来的接口路径仍然返回正常页面检查发现补丁的 jar 包已经替换应用进程根本没重启。原因部分产品的补丁是替换类文件进程不重启时加载的还是旧类还有的是集群环境只升了其中一个节点。解决修复完成后做三项确认——进程启动时间是否晚于补丁时间、jar 包的时间戳是否更新、用手册检测路径回放一次看是否已被拦截或返回异常。5.4 现象WAF 拦了固定路径攻击者做编码和大小写绕过规则里写的是/admin/user_save.action攻击者在路径中插入%2f或把大小写混排比如/admin/user_Save.actionWAF 直接放行后端框架却正常解析。原因规则只匹配了固定字符串没有做 URL 解码和大小写归一化。很多 Java 框架在解析路径时对大小写不敏感对编码后的斜杠也会解码后再匹配路由。解决WAF 规则里统一加两步预处理——先 URL 解码再小写化然后做特征匹配。配置完用%2f、大小写混排、路径末尾加/.三种方式各测一遍确保规则在变形后仍然生效。5.5 现象边界修完了内网横向一打全穿把公网资产对照手册修完结果演练第三天红队从一台边缘设备跳进内网直接打了内网的大华智慧园区和泛微防御体系照样破防。原因手册里的漏洞不是只打边界。大华、海康、泛微这类系统大量存在于内网红队进内网后第一个找的就是这类熟悉的高价值目标。自查时只对公网资产做了一遍是最大的漏洞。解决把手册清单同步用到内网资产测绘结果上内网命中同一个漏洞的资产同样走 P0/P1 分级流程。另外像 GitLab、自建代码仓库这类常见外露资产也值得单独做一轮高危漏洞修复方案的核查——它们在演练里经常被当作权限提升和信息收集的跳板别只盯着手册里的厂商名单。6. 把手册转成自查清单验证方法、字段设计和复盘习惯手册的价值在执行层。拿到这份资源的最后一步是把它转成一张按资产维度组织的自查清单而不是按 CVE 维度组织。6.1 清单字段与状态流转我用的清单字段是资产 IP、所属域名、组件名称、当前版本、命中漏洞编号、检测路径验证结果、修复动作、责任人、当前状态、计划完成时间。状态只有四个待确认、已封堵、已升级、已验证。一张表管到演练结束。6.2 两条命令验证修复效果验证接口是否封堵curl -s -o /dev/null -w %{http_code} http://目标IP/nifi-api/process-groups/root # 返回 403/404 说明封堵生效返回 200 需要回到第 5.1 节做二次判断验证版本是否更新# 以 Solr 为例访问管理接口查看版本 curl -s http://目标IP:8983/solr/admin/info/system?actionstats | grep -oE solr-spec-version:[^]*6.3 复盘习惯从那以后每次 HW 前我都强制走一遍同样的流程先摸资产指纹再把手册里的漏洞按资产命中情况生成清单修复完一定回放检测路径验证一次最后把验证结果贴回清单再关单。这个习惯帮我挡掉了至少一半的假修复。希望帮到你。本文还有配套的精品资源点击获取