漏洞复现与 CVE 利用

漏洞复现是连接"漏洞情报"与"实战防御"的桥梁：在隔离环境里复现一个公开漏洞，既能学习利用原理，更重要的是验证自己的资产是否受影响、补丁是否有效。这篇讲清楚 CVE/CNVD 等漏洞编号体系、CVSS 评分怎么读、如何用 Docker 安全地搭复现环境，以及一套规范的复现到应急响应流程。

漏洞编号体系

同一个漏洞在不同库里有不同编号，理解它们的关系才能高效查情报：

查漏洞详情常用：NVD、exploit-db.com（EXP 库）、厂商安全公告。

读懂 CVSS 评分

CVSS（通用漏洞评分系统，当前为 v3.1/v4.0）用 0–10 的分数表示严重程度，是排定修复优先级的依据：

评分由攻击向量（网络/本地）、复杂度、所需权限、用户交互、对机密性/完整性/可用性的影响等因素综合得出。但分数只是参考——还要结合自身资产是否真的暴露、是否有公开 EXP、是否被在野利用（看 CISA KEV 已知被利用漏洞目录）来定优先级。一个 CVSS 9.8 但你根本没部署该组件的漏洞，远不如一个 7.5 但正在被大规模利用的漏洞紧急。

用 Docker 安全搭建复现环境

复现的第一原则是隔离——漏洞环境往往是故意留洞的，绝不能碰外网。Docker 是最方便的隔离手段，Vulhub 项目把上百个 CVE 打包成一键启动的 docker-compose 环境：

# 拉取 Vulhub（开源漏洞复现平台）
git clone https://github.com/vulhub/vulhub.git
cd vulhub

# 进入某个漏洞目录，一键启动
cd log4j/CVE-2021-44228
docker compose up -d

# 复现完成后销毁环境，连同数据一起清理
docker compose down -v

隔离要点：

• 复现主机放在独立的虚拟机 + 仅主机网络里，不要用日常办公机。
• 不给复现容器配公网出口，防止"靶机"被真实攻击者顺手接管。
• 用完即焚，docker compose down -v 清干净。

标准复现流程

经典案例：Log4Shell（CVE-2021-44228）

以 2021 年的 Log4Shell 为例，理解一次高危复现要关注什么：

• 成因：Apache Log4j2 的 JNDI Lookup 功能会解析日志内容里的 ${jndi:ldap://...}，攻击者把恶意字符串塞进任何会被记录的输入（如 User-Agent），即可让服务器去攻击者控制的 LDAP/RMI 服务器加载并执行远程类，造成 RCE。
• CVSS：10.0，无需认证、网络可达、影响面极广（Log4j 被海量 Java 应用依赖），属典型供应链级灾难。
• 复现关注点：哪个版本受影响（2.0-beta9 ~ 2.14.1）、哪些输入点会被记录、JDK 版本对利用的影响。
• 修复：升级到 2.17.1+；临时缓解可移除 JndiLookup 类或设置相关系统属性。

Log4Shell 也提醒我们：现代漏洞很多出在第三方依赖上，资产清点必须包含"我用了哪些组件、什么版本"。

从复现到应急响应

复现能力直接服务于防守。当一个新的高危 CVE 爆出时，蓝队的标准动作：

1. 资产排查：用 SBOM/资产清单确认是否使用了受影响组件及版本。
2. 暴露面评估：受影响资产是否对外暴露、是否需要认证。
3. 复现验证：本地复现确认自家环境是否真的可被利用。
4. 检测与狩猎：根据漏洞特征写 IDS/WAF 规则、排查日志中是否已有利用痕迹（是否已被攻陷）。
5. 修复与缓解：打补丁是根治；不能立即升级时用 WAF 规则、配置变更做临时缓解。
6. 复盘：纳入资产与依赖管理流程，避免下次再被同类问题打穿。