diff --git a/data.json b/data.json index 554cacad..52e11c89 100644 --- a/data.json +++ b/data.json @@ -26923,5 +26923,18 @@ "https://mp.weixin.qq.com/s/gCzjmru9awQp-YrMH3MyPg": "【已复现】WordPress 核心主题预览缺陷可导致RCE漏洞（Click2Shell）", "https://mp.weixin.qq.com/s/A9XSM4sLw91lPYEo3_-nsw": "国家信息安全漏洞共享平台认证！360揽获三项漏洞治理核心殊荣", "https://mp.weixin.qq.com/s/8sEpo2P5dHyXqAnHjGOzsQ": "众测复盘：从 APP 一条普通图片请求，挖掘外围服务器文件上传漏洞", - "https://mp.weixin.qq.com/s/1_ALUqD3yoiOV3tuxWOjLw": "专家解读 | 依法堵住网络“小设备”的安全大漏洞" + "https://mp.weixin.qq.com/s/1_ALUqD3yoiOV3tuxWOjLw": "专家解读 | 依法堵住网络“小设备”的安全大漏洞", + "https://mp.weixin.qq.com/s/2o_t5sK6Cn_ULn-BXwp07g": "【AI安全】40个Agent∕MCP漏洞归成13类后，扫描器为何仍只能找候选", + "https://mp.weixin.qq.com/s/ZAJIk-inmt0496wYuo96Gg": "车联网漏洞挖掘方法及典型案例剖析", + "https://mp.weixin.qq.com/s/qonAHlNXe90mvsmwsMRqNw": "(7.1分) CVE-2025-39682：Linux内核TLS UAF本地提权", + "https://mp.weixin.qq.com/s/A62MrfscxdDyH2Vbo5LnUA": "工具分享 | 一款若依（Ruoyi-Vue）漏洞检测工具", + "https://mp.weixin.qq.com/s/reYpJTR0GNez94zb4V5Bgg": "紧急安全预警｜CUPS曝本地提权漏洞，lpadmin低权限用户可获取Root权限", + "https://mp.weixin.qq.com/s/9gcZXxMaT7tkMpp7-aI0yQ": "【安全圈】攻击者利用 Issabel Framework 漏洞实现未经身份验证的 OS 命令执行", + "https://mp.weixin.qq.com/s/Wi3L7UgVk_ewaVVmOxb7GA": "APP漏洞挖掘全套自动化工具（自动化检测程序+漏洞报告模板+检测指南）", + "https://mp.weixin.qq.com/s/3Vhnvfkz_NPpaWmb2qBj_Q": "千万别忽视！这个逻辑漏洞可绕过管理员的审核", + "https://mp.weixin.qq.com/s/JvOp_vQxbVDRXjdCnX5cmQ": "Claude Code、Codex、Copilot与Gemini CLI四大编程代理惊爆零点击RCE", + "https://mp.weixin.qq.com/s/6AqwVTnQ1BBW1nPo4KSE1A": "Windows 内核 WMI 计数回绕 CVE-2026-42980", + "https://mp.weixin.qq.com/s/XlGxJeKunR6f4u15Ispnrg": "Adobe 修复了 Magento 零日漏洞，该漏洞已被利用来部署 Rust 后门和 PHP Web Shell", + "https://mp.weixin.qq.com/s/ycXjYy0JMAjt62EAE84tPg": "AI在企业级漏洞预警中的应用", + "https://mp.weixin.qq.com/s/YrcGxhNFYEWAF1paVRcjvg": "JumpServer越权漏洞：URL里加个参数，管理员Access Key直接裸奔" } \ No newline at end of file diff --git a/doc/2026-09/(7.1分) CVE-2025-39682：Linux内核TLS UAF本地提权.md b/doc/2026-09/(7.1分) CVE-2025-39682：Linux内核TLS UAF本地提权.md new file mode 100644 index 00000000..2f0f24ff --- /dev/null +++ b/doc/2026-09/(7.1分) CVE-2025-39682：Linux内核TLS UAF本地提权.md @@ -0,0 +1,161 @@ +# (7.1分) CVE-2025-39682：Linux内核TLS UAF本地提权 +红队安全圈 + 红队安全圈 红队安全圈 2026-09-19 00:06 + +已确认在野利用的 Linux 内核本地提权洞：net/tls 一条零长度记录就能打碎引用计数，低权限直接够到 root。 + +## 01  漏洞速览 + +Linux 内核 net/tls 子系统存在一个 Use-After-Free 漏洞（CVE-2025-39682），CVSS 3.1 评分 **7.1** +，本地低权限攻击者可以借此把权限提到 root。最要命的信号是：CISA KEV 已确认在野利用，说明有真实攻击者在用，不只是实验室玩具。跑着内核 6.0 到 6.16 的机器，尤其是多用户服务器和云主机，都需要立刻排查。 + +漏洞编号 +CVE-2025-39682 + +影响产品 +Linux Kernel（net/tls） + +影响版本 +6.0 - 6.16.3 及 6.17-rc1/rc2（详见下文） + +漏洞类型 +CWE-416 Use After Free + +危害等级 +CVSS 3.1 7.1 High（本地提权） + +是否在野 +是，已进 CISA KEV + +公开 PoC +有，崩溃 PoC + 完整分析已公开 + +攻击前提 +本地低权限账号 + 启用 kTLS 接收路径 + +影响面 +多用户 Linux 服务器本地提权到 root + +## 02  漏洞成因 + +根因在  +tls_sw_recvmsg + 对零长度 TLS 记录的处理。正常约定是：每次  +recvmsg() + 要么只处理连续的 DATA 记录，要么处理一条非 DATA 记录。但当一条零长度记录从  +rx_list + 取出时，这个约定被打破——后续 TLS 记录会按错误的 zero-copy 和排队假设继续处理。 + +具体链条： + +1. copied == 0 时函数继续循环收包。一条零长度解密记录正好触发这个条件。 + +2. 下一轮迭代中，如果新记录的 content type 与先前建立的 control 不一致，tls_record_content_type() 返回 0。 + +3. 返回值小于等于 0 走错误路径，把 darg.skb（其实就是 strp 的 anchor）挂进 ctx 的 rx_list。 + +4. 问题在这：当 darg.zc == 1（zero-copy 模式激活）时，把 anchor 挂进 rx_list 是禁止的。这会破坏 anchor 的 frag_list 和引用计数。 + +后果是：socket 关闭时，tls_sw_release_resources_rx 遍历已释放的内存，UAF 在 kfree_skb_list_reason 处被 KASAN 确认。这块 SKB 最早由 tcp_sendmsg_locked 分配，在错误重新入队之前已经被 tls_strp_msg_done 释放。 + +一句话总结：错误路径把一个 zero-copy 模式下的 anchor SKB 二次入队，引用计数被打乱，释放后还在用。 + +## 03  影响范围 + +受影响版本（升级到以下版本之上即安全）： + +6.0      - 6.1.148 + +6.2      - 6.6.102 + +6.7      - 6.12.43 + +6.13     - 6.16.3 + +6.17-rc1 / 6.17-rc2 + +补丁已随主线发布。KEV 条目提到部分受影响产品可能已 EoL/EoS——这类机器打不了补丁，只能换版本或做缓解。 + +## 04  利用分析：触发序列已公开 + +研究者已发布完整触发序列，六步复现（在 Linux 6.12.41 上实测触发 KASAN UAF）： + +**步骤 1** +：发送一条 TLS Application Data 记录（type 0x17，内容 Hello world）。 + +**步骤 2** +：发送一条零长度 TLS Handshake 记录（type 0x16，空明文）。 + +**步骤 3** +：用 read(conn, buf, 0x100) 部分消费第一条记录，让下一次调用时 copied == 0。 + +**步骤 4** +：再发送一条 Application Data 记录（type 0x17）。 + +**步骤 5** +：调用 recvmsg——handshake 记录与后续 data 记录的 content type 不匹配，触发漏洞路径：darg.zc == 1 时错误地把 anchor SKB 入队 rx_list。 + +**步骤 6** +：关闭 socket——UAF 在 tls_sw_release_resources_rx 中触发。 + +公开的崩溃 PoC 本身只让内核崩溃（KASAN 报 slab-use-after-free）。但从崩溃到提权是经典路径：UAF 意味着可以堆喷射占位被释放的 SKB 内存，配合跨缓存攻击或 page 级喷射替换成可控对象，进而改写函数指针或核心结构完成 LPE。研究者的分析标题就写明目标是 privilege escalation。 + +利用门槛评估：本地、低权限、复杂度低（AC:L）。难点在于 kTLS 接收路径需要目标进程真的在用 kTLS——这缩小了实战面，但在负载均衡、加密代理类服务里并不罕见。 + +## 05  检测与排查 + +版本排查（第一步先看内核版本是否在受影响区间）： + +uname -r + +确认 kTLS 是否在用——看进程有没有设置  +TCP_ULP tls +，服务端场景直接查模块和 socket 状态： + +ss -tinm | grep tls + +lsmod | grep tls + +日志排查：内核日志出现过 KASAN 的 slab-use-after-free，位置在 kfree_skb_list_reason 或调用栈带 tls_sw_release_resources_rx，说明漏洞已被触发。在野利用场景下，攻击者得手后还会尝试提权，需结合 auditd 的 setuid/execve 异常记录一起看。 + +## 06  修复建议 + +1. 升级内核到包含补丁的版本：6.1.149+ / 6.6.103+ / 6.12.44+ / 6.16.4+ / 6.17-rc3+（或发行版 backport 版本）。 + +2. 暂时无法升级的：确认业务没有启用 kTLS 接收路径可显著降低风险——漏洞入口在 tls_sw_recvmsg，不用 kTLS 就打不到。 + +3. EoL/EoS 系统（KEV 明确点名）：没有补丁可打，尽快迁移到受支持版本。 + +4. 多用户服务器和容器宿主机：限制本地不可信用户，是所有内核 LPE 的通用缓解。 + +## 07  红队视角 + +这个洞的实战价值在于：在野确认 + 本地低门槛。KEV 收录说明已有攻击者把它塞进利用链，很可能作为容器逃逸或多阶段入侵里的提权环节——拿到 Web shell 后从低权限服务账号提到 root，一步到位。 + +对防守方的提示： + +- 面向公网的服务就算本身无此漏洞，落入的账号一旦能触发本地内核漏洞，边界就没了。7.1 分的本地提权在多租户环境里实际影响远超分数。 + +- 排查优先级：容器宿主机 > 多用户跳板机 > 单用途加密服务节点。 + +- 类似历史案底：net/tls 这几年不是第一次出事，tls_setsockopt 系列和 tls_sw_recvmsg 早前的处理缺陷都报过。这条接收路径建议整体纳入重点审计范围。 + +后续如果出现可用的完整 LPE exploit，会跟进分析。 + +## 08  POC 链接 + +STAR Labs 的完整分析（触发序列 + 崩溃 PoC 源码 + TLS 记录生成脚本）： + +https://starlabs.sg/advisories/25/25-39682/ + +CISA KEV 条目： + +https://www.cisa.gov/known-exploited-vulnerabilities-catalog#CVE-2025-39682 + + +如果文章对您有收获，欢迎**关注** +、点赞、推荐、转发。 + +— END — + + diff --git a/doc/2026-09/AI在企业级漏洞预警中的应用.md b/doc/2026-09/AI在企业级漏洞预警中的应用.md new file mode 100644 index 00000000..1b174bd0 --- /dev/null +++ b/doc/2026-09/AI在企业级漏洞预警中的应用.md @@ -0,0 +1,779 @@ +# AI在企业级漏洞预警中的应用 +原创 aerfa21 + aerfa21 我的安全视界观 2026-09-19 08:13 + +> 漏洞预警真正的瓶颈，从来不是"不知道有漏洞"，而是从**看到通告** +到**确认自己受影响** +之间那段转化。 +> 这篇文章基于两个已经落地的成果展开：一张《漏洞预警流程 - - AI 驱动四阶段闭环体系》流程图，和一份针对 Nginx CVE-2026-42945 的批量排查脚本（迭代到 v1.0.2）。前者是体系流程，后者是流程里"应用"环节被真正跑起来的一个切片。 + + +数据速览 + +先把全篇要用到的数字摆出来，后面每一节都在解释它们是怎么来的： + +对象 → 规模 + +预警场景全景 + +7 类业务场景，其中"漏洞预警"是打磨最久的一类 + +预警流程 + +4 个阶段 → 3 个团队并行 → 11 个动作节点 → 4 条 PS 备注 + +监测信源 + +5 类（奇安信 CERT / CVE / NVD / 微软安全公告 / Chrome 安全更新） + +内化产出 + +4 项（漏洞原理、漏洞细节、POC 分析、是否启动应急响应） + +排查脚本 + +153 行 → 4 个检测步骤 → 3 个联合判定条件 → 2 类运行环境 → 3 轮修复 + +成熟度定位 + +排查脚本 L2（条件自动判定）｜内化研判 L0（人工）｜整体由最低环节决定 + + +一 +漏洞预警的瓶颈，从来不在"信息" + +做安全的人都有一个共同感受：**漏洞信息永远是过量的** +。 + +奇安信 CERT、CVE / NVD、微软安全公告、Chrome 安全更新，再加上各种商业与开源情报源，每天推过来的通告数以百计。真正稀缺的从来不是"漏洞线索"，而是三样东西： +1. **判断力** +——这个漏洞对我方资产到底成不成立？ + +1. **时间** +——从看到通告到确认影响范围，能不能压缩到小时级？ + +1. **一致性** +——同一个人、不同时间、面对不同漏洞，能不能给出同样质量的结论？ + +传统做法是"人工盯 + 人工查"：信息靠人刷，判断靠经验，排查靠临时写命令。结果是**监测环节堆满了信息，内化环节堵在了一个人身上，应用环节的排查动作又高度重复、质量参差** +。 + +我们先把场景盘清楚了，才敢谈 AI + +在动手做任何自动化之前，我先做了一件事：把 AI 可能介入的安全业务场景全部列出来，形成一张全景图。结论是 **7 类** +： + +1. 业务场景：**漏洞预警** +——针对商业或开源软件的 0day / Nday 漏洞监测与响应 + +优质监测渠道 +　奇安信 CERT、CVE、NVD、微软、Chrome + +内化阶段要产出什么 +　漏洞原理、漏洞细节、POC + +2. 业务场景：投毒预警——针对商业或开源软件的投毒信息 + +优质监测渠道 +　墨菲安全、悬镜安全、OSSF 项目 + +内化阶段要产出什么 +　软件名称与版本、IOC、C2 + +3. 业务场景：APT 追踪——针对 APT 组织的技战法 + +优质监测渠道 +　TG、公众号 + +内化阶段要产出什么 +　TTPs、恶意样本 + +4. 业务场景：攻击事件——针对知名企业被攻击事件做自省 + +优质监测渠道 +　TG、公众号 + +内化阶段要产出什么 +　TTPs、企业安全建设启发 + +5. 业务场景：敏感信息泄露——针对公司代码、账号的外部监测 + +优质监测渠道 +　GitHub、码云、CSDN、语雀、公众号 + +内化阶段要产出什么 +　—— + +6. 业务场景：安全技术分享——会议、文章等内容内化 + +优质监测渠道 +　TG、公众号 + +内化阶段要产出什么 +　安全工具、技术手法、攻击思路、建设经验 + +7. 业务场景：产品漏洞信息——针对公司自身产品的漏洞与利用信息 + +优质监测渠道 +　公众号、CSDN、先知 + +内化阶段要产出什么 +　—— + +这七类场景有一个**共同的形状** +：前端是海量、非结构化的信息，后端是可以标准化的动作。这个形状恰好就是  +AI 最擅长补位的地方 - - **读得比人快，记得比人全，但判断必须由人兜底** +。 + +本文聚焦第一类，也是我们打磨最久的一类：漏洞预警。 + + +二 +流程：AI 驱动的四阶段闭环 + +我们把漏洞预警拆成了四个阶段：**监测 → 内化 → 应用 → 验证** +。 + +![漏洞预警流程 —— AI 驱动四阶段闭环体系](https://mmbiz.qpic.cn/mmbiz_png/JFR9icl1yawn0MgdQibWwHnNByHqZaSVKlJtr3PPMBINOO2ibTd20K8QbOiariaKw9ZPCEGPElmKpxgBRakfIclJ4LlNDV4bdczdp6sDO0ic4NPwc/640?wx_fmt=png&from=appmsg "") + +图 1：漏洞预警流程 - - AI 驱动四阶段闭环体系（监测 → 内化 → 应用 → 验证） + +先把全局看清，再逐个阶段展开： + +① 监测 + +关键动作 +　5 类信源聚合 + +主要产出 +　待研判漏洞清单 + +AI 的落点 +　去重、降噪、相关性排序 + +必须由人兜底的地方 +　信源准入标准 + +② 内化 + +关键动作 +　提取原理 / 细节 / POC + +主要产出**结构化利用条件表** + +AI 的落点 +　通读公告与 POC、抽取条件字段 + +必须由人兜底的地方**是否启动应急响应** + +③ 应用 + +关键动作 +　3 团队并行、11 个动作节点 + +主要产出 +　受影响清单、工单、BAS 用例 + +AI 的落点 +　把利用条件翻译成可执行排查逻辑 + +必须由人兜底的地方 +　影响范围与修复优先级确认 + +④ 验证 + +关键动作 +　3 层验证 + 回退机制 + +主要产出 +　闭环 / 回退修复 + +AI 的落点 +　结果比对与回归 + +必须由人兜底的地方 +　闭环判定 + +① 监测：信源聚合与降噪 + +渠道是固定的五类：奇安信 CERT、CVE / NVD、微软安全公告、Chrome 安全更新，以及微信公众号开源情报源。 + +这一步  +AI 的价值不在"抓取"（抓取是工程问题），而在**降噪和初筛** +：同一漏洞被多个渠道重复推送时去重、把与我们技术栈无关的通告降权、把"影响面大且可落地"的通告前置。人不再需要逐条读完全部通告，只需要读被排到前面的那几条。 + +② 内化：把通告翻译成"可判断的结论" + +这是整个流程里**最关键、也最难** +的一环，流程图上专门用红字标注了：**需要人工参与** +。内化要产出四样东西： +- **漏洞原理：它到底是怎么触发的；** +- **漏洞细节：触发它需要满足哪些前置条件；** +- **POC 代码的提取与分析：有没有可验证的 PoC，PoC 说明了什么；** +- **是否启动应急响应的判断。** +AI 在这里承担的是"重活中的体力活"：通读公告与 PoC、把散落在正文/附件/引用链接里的**利用条件** +结构化地抽出来（版本区间、配置要求、认证前提、是否需要特定编译选项），并给出一个初步研判。 + +而人承担的是"重活中的判断活"：**是否启动应急响应的标准是什么** +。这是流程图里反复强调、也是我们至今仍在持续明确的问题——**这个标准不能交给模型去猜** +。 +> 一个关键认知： +AI 不是把"研判"这个环节自动化掉了，而是把研判的**输入准备好** +了。以前研判的人要花两小时读材料，现在读一份已经被整理好的结论摘要，再把时间花在真正需要经验的那一步。 + + +③ 应用：三个团队并行，11 个动作节点 + +这是流程里最"重"的一段，也是最容易被 AI 提效的一段。三个团队**并行** +推进，各自面向不同的资产面： + +**安全运营团队** + +面向 +　全域网络资产 + +动作节点 +　4 步：② 受影响范围初评 → ③ 受影响范围确定 → ④ 推动受影响修复 → ⑤ 修复后漏洞验证 + +**内部蓝军团队** + +面向 +　"这个漏洞打不打得进来" + +动作节点 +　3 步：① 漏洞分析与研判 → ② 漏洞利用武器化 → ③ 丰富 BAS 用例库 + +**产品安全团队** + +面向 +　产品线 + +动作节点 +　4 步：② 受影响范围初评 → ③ 受影响范围确定 → ④ 推动受影响修复 → ⑤ 修复后漏洞验证 + +三支队伍的差异，其实在"**用什么工具去确认范围** +"这一句上： + +**安全运营团队** +（全域网络资产） +1. **受影响范围初评：查询 CAASM 平台 / 联动 OPS，通过名称、版本信息初步判断可能受影响的资产；** +1. **受影响范围确定：使用 CAASM 平台 / 联动 OPS，通过 POC 扫描、主机信息收集确定实际受影响范围，并针对性输出防御或检测方法；** +1. **推动受影响修复：通过 CAASM 平台工单、POC 扫描结果生成工单，推送给资产责任人，提醒按 SLA 修复；** +1. **修复后验证：再次通过 POC 扫描、主机信息收集验证修复情况。** +**内部蓝军团队** +（面向"打不打得进来"） +1. **漏洞分析与研判：分析和复现漏洞，输出利用条件、难易程度、POC，以及是否启动应急响应；** +1. **漏洞利用武器化：直接或结合历史漏洞，做成实战渗透的武器；** +1. **丰富 BAS 用例库：转化为 BAS 格式的验证 POC，加入常态化安全有效性验证。** +**产品安全团队** +（面向产品线） +1. **受影响范围初评：查询 SDL 平台组件及工单，通过名称、版本信息初步判断可能受影响的资产；** +1. **受影响范围确定：使用 CAASM 平台 / 组织产线安全专员，通过漏洞利用条件、POC 等确定实际受影响范围；** +1. **推动受影响修复：通过 wiki / SDL 平台创建漏洞工单，推送给产品安全专员，提醒按 SLA 修复；** +1. **修复后验证：使用检查配置、POC 等方式验证修复情况。** +流程图上还压着 4 条 PS 备注，它们恰恰是"纸面流程"和"真实流程"的差距所在： +- 暂无 POC 等无法用 POC 直接验证的场景，**先用人工跟进全流程闭环** +； + +- 需关注**安全产品检测规则更新、或自研检测规则更新** +； + +- 外部客户侧的修复需视实际情况而定，影响大、舆论声音大走 **PSIRT 流程** +； + +- 需关注**实验局中安全产品的自身安全情况** +。 + +**AI 在"应用"环节的落点，就是把内化阶段产出的"利用条件"，直接变成可在资产上批量执行的排查动作。** + 下一节的脚本，就是这一段的具体实现。 + + +④ 验证：闭环，以及回退 + +验证有三层： +1. 各细分场景 / 团队验证对应的漏洞修复情况； + +1. BAS 验证新漏洞的安全防护（监测）效果； + +1. **验证通过 → 闭环；不通过 → 回退到修复阶段。** +注意第 3 条——流程里明确写了回退路径。一个没有回退的流程，闭环是假的。 + +同时有一个容易被忽略的 PS：**需关注安全产品检测规则更新，或自研检测规则更新。** + 一个漏洞的闭环，不只意味着"资产修好了"，还意味着"我们下次能不能更早发现它"。 + + +三 +案例：CVE-2026-42945 排查脚本是怎么迭代出来的 + +流程讲完，来看一个真实切片——**一份 153 行的 Nginx 批量排查脚本，从能跑，到敢在上万台机器上跑** +。 + +![CVE-2026-42945 排查判定逻辑](https://mmbiz.qpic.cn/sz_mmbiz_png/JFR9icl1yawm9PXTicQacvdzndJBMPYdLob2VW9XbjVux3EcGeSv9t5ic5icekLEyu2Gf7caS4cI6xic3HVgvyp1ibhqu06w9PicRUN5spBoMiarkvU/640?wx_fmt=png&from=appmsg "") + +图 2：把通告里的自然语言翻译成判定逻辑 —— 三条件联合判定 + 4 步检测 + +3.1 从"通告"到"判定条件"：一次翻译 + +通告给出的信息是描述性的：某版本区间的 Nginx，在特定 rewrite + 配置下，叠加 ASLR 关闭的环境，存在可利用风险。 + +人类读这段话，会立刻明白"要同时满足三个条件才真正有风险"。但**要把它变成机器能跑的逻辑，需要一次翻译** +： + +通告里的自然语言 → 翻译成的可执行判定 + +某版本区间的 Nginx + +提取 nginx -v + 版本号，与 0.6.27 ~ 1.30.0 + 做区间比较 + +特定 rewrite + 配置 + +grep -rE 'rewrite.*\?.*\$[1-9]' + 匹配配置文件 + +ASLR 关闭 + +读 /proc/sys/kernel/randomize_va_space +，为 0 即关闭 + +三条件同时成立才有风险 + +三个结果做逻辑与，输出最终结论 + +这一步就是 AI 最直接的用武之地：**把通告读成条件表，再把条件表写成代码。** + 人只需要复核条件表对不对——**复核一张表，比复核 153 行代码便宜得多。** + +3.2 脚本长什么样：4 步检测 + +翻译完条件，脚本的结构几乎是自然浮现的： + +[1/4] + 检查对象：内核 ASLR + +判定方式 +　读 /proc/sys/kernel/randomize_va_space + +空值 / 异常处理 +　非 0 即视为已开启，利用难度高 + +[2/4] + 检查对象：宿主机 Nginx + +判定方式 +　版本区间 + 高危 rewrite + 配置 + +空值 / 异常处理 +　无 nginx 则明确输出"未安装"，不报错 + +[3/4] + 检查对象：Docker 可用性 + +判定方式docker ps + 探测，失败降级 sudo + +空值 / 异常处理 +　无权限则标记"跳过容器检测" + +[4/4] + 检查对象：容器内 Nginx + +判定方式 +　逐容器重复同一套判定 + +空值 / 异常处理 +　无运行中容器则直接给出结论收尾 + +值得注意的是：**判定逻辑（版本区间 + 配置匹配 + ASLR）在宿主机和容器两条路径上是同一套** +，只是执行方式从本机命令换成了 docker exec +。逻辑复用，才能保证两个环境的结论可比。 + +3.3 版本区间判定：一个典型"看起来简单"的坑 + +第一版最容易写错的就是版本比较。字符串比较会把 1.9.0 + 判定为大于 1.30.0 +，直接导致漏报。最终采用的是 sort -V + 的版本序比较： +``` +``` + +逻辑是：把目标版本和上下界一起排序，如果目标版本排序后既不小于下界、又不大于上界，就落在区间内。 + +这类"边界条件"是 AI 辅助写脚本时最该被要求穷举的部分——**六个用例一次列全** +：正常版本、区间下界、区间上界、比下界小、比上界大、多段版本号（如 1.9.0 + vs 1.30.0 +）。 + +3.4 v1.0.2：三个被真实环境打出来的问题 + +脚本头部留了一行版本说明，很能说明问题： +``` +``` + +三个修复，对应三类典型的"**在实验室里想不到、一上生产就暴露** +"的问题。 + +**问题一：空配置被误判为"有风险"。** + +早期版本里，grep + 没匹配到内容时返回空，脚本却依然打印了"发现高危配置"，制造了误报。修复方式是**先判空，再下结论** +： +``` +``` + +注意这里还藏着第二个细节：**只有当"配置命中"和"ASLR 关闭"同时成立时才置风险位** +，而不是看到配置就报风险。这是对"三条件联合判定"的忠实实现——**流程的严谨性，最终要靠代码的严谨性来承载。** + +**问题二：日志写不进去。** + +早期把日志写在工作目录，遇到权限受限的机器直接 Permission denied +，整个排查中断。改为写 /tmp + 并同时输出到终端： +``` +``` + +日志文件名里带上**主机名和时间戳** +，是为了多台机器并发执行后，回收日志时不会互相覆盖——这是一个"批量执行"场景才会浮现的需求，单机测试永远遇不到。 + +**问题三：只查了宿主机，漏了容器。** + +这是最致命的一类遗漏。现在很多服务跑在容器里，宿主机上根本没有 nginx + 命令，脚本会直接输出"宿主机未安装 Nginx"然后收尾，看起来一切正常，实际风险全在容器里。 + +修复后的脚本做了两件事。一是**自动兼容 sudo docker** +： +``` +``` + +二是**遍历所有运行中容器** +，对每个容器重复同一套"版本区间 + 高危配置"判定，把宿主机和容器的结论合并到同一个风险位上。同时，无 Docker 的场景下走一条干净的收尾分支，直接给出结论，而不是让脚本在半路报错。 + +最终输出被收敛成一句话，让非脚本作者也能直接读结论： +``` +``` + + +3.5 复盘：AI 做了什么，人做了什么 + +回头看，AI 在这份脚本上的贡献可以拆成四件很具体的事： + +条件翻译 + +AI 负责 +　把通告里的自然语言利用条件，翻译成"版本 / 配置 / 环境"判定表 + +人负责 +　确认条件表与真实利用路径一致 + +边界穷举 + +AI 负责 +　列出 6 个版本比较用例，以及"grep 无输出""无 docker 权限""无运行中容器"等空值分支 + +人负责 +　判断哪些边界在真实资产上会出现，甚至做一些必要的测试 + +代码审查 + +AI 负责 +　识别"空字符串被当成命中"这类逻辑漏洞，以及权限、路径等环境依赖 + +人负责 +　决定修复优先级 + +文档化 + +AI 负责 +　把每轮修复原因写进脚本注释，让 v1.0.2 + 成为可追溯的变更记录 + +人负责 +　- -  + +应急响应判定 + +AI 负责**不参与** + +人负责 +　决定这个漏洞要不要启动应急响应 + +结论文案 + +AI 负责 +　生成结论与输出格式 + +人负责 +　确认给谁看、能不能被直接读懂 + +**分工非常清楚：AI 负责把条件变成代码，人负责确认条件本身是对的。** + +**** +四 +方法论：给自动化定级，别用最高那一环代表整体 + +有了流程，还差一个坐标系：**这套东西到底自动化到了什么程度？** + 我们用一个四级模型来定位。 + +4.1 四级成熟度 + +**L0 人工** + +特征 +　人执行、人判断 + +人的角色 +　全流程 + +典型风险 +　效率低、一致性差 + +**L1 AI 辅助** + +特征 +　AI 产出草稿或摘要，人执行、人判断 + +人的角色 +　判断 + 执行 + +典型风险 +　把 AI 草稿直接当结论 + +**L2 条件自动判定** + +特征 +　判定条件固化进工具，自动出结论 + +人的角色 +　定义条件、复核结论 + +典型风险 +　条件错则全错；误报 + +**L3 闭环自动回退** + +特征 +　检测 → 工单 → 复测 → 回退全自动 + +人的角色 +　定义标准、处置异常 + +典型风险 +　错误被自动扩散 + +![自动化成熟度分级](https://mmbiz.qpic.cn/sz_mmbiz_png/JFR9icl1yawmRkoHR2GVgA55KfhZhqmsXWyoia606eQhj5kqNPlHVDYo54VcNoiaJCaouxLr4SITFW1OedY2HfJdusLTXtAM1RfibfWKuWwLhBw/640?wx_fmt=png&from=appmsg "") + +图 3：自动化成熟度分级 —— 排查脚本在 L2，内化研判仍在 L0 + + +4.2 本案例的位置：一个流程，三种级别 + +把前面两个成果放进这个坐标系，会发现一件有意思的事——**同一个流程里，不同环节的成熟度并不一样** +： + +排查脚本（版本 / 配置 / ASLR 判定） + +级别**L2** + +依据 +　三个判定条件已固化，自动出结论 + +内化研判（是否启动应急响应） + +级别**L0** + +依据 +　流程图上红字明确"需要人工参与"，标准尚未书面化 + +修复后复测 + +级别**L2** + +依据 +　复用同一脚本，但"是否闭环"的判断仍在人 + +工单流转与回退 + +级别**L1** + +依据 +　生成环节半自动，回退路径仍靠人推动 + +**所以最重要的一句话是：整体成熟度由最低的那一环决定。** + 排查做到了 L2，不代表漏洞预警做到了 L2 - - 木桶的短板仍然卡在"是否启动应急响应"那一步。 + +这也是我们不去宣传"漏洞预警已实现自动化"的原因：**局部 L2 是事实，整体 L2 是夸大。** + +4.3 什么时候可以升级 + +往上升一级之前，先回答三个问题： + +自检问题 → 答案是"否"时该怎么办 + +判定条件能否枚举完？ + +不能 → 留在 L1，别硬做 L2 + +结论错了的代价能否承受？ + +不能 → 必须保留人在环 + +有没有回退路径？ + +没有 → 不要做 L3 + +对照本案例：判定条件能枚举（版本 + 配置 + ASLR 三个条件）；错了的代价可控（脚本只出结论，不自动处置）；有回退路径（验证不通过退回修复）。**三个条件都满足，所以排查环节做到 L2 是合适的。** + +而"是否启动应急响应"这一环，恰恰卡在第一个问题上——**标准还没定义清楚，条件就枚举不完，所以它只能留在 L0。** +  +这不是技术能力不够，是业务判断还没收敛。 + + +五 +沉淀：AI 的 5 个可复用能力，和 4 条不能越的边界 + +把上面的流程和案例抽象一层，AI 在漏洞预警中稳定的价值点有五个： +1. **信息抽取** +——从通告、PoC、情报里抽取版本区间、前置条件、IOC、TTPs 等结构化字段； + +1. **条件翻译** +——把"利用条件"翻译成可执行的检测逻辑，这是从"内化"到"应用"的关键一跳； + +1. **代码生成** +——批量排查脚本、扫描规则、BAS 用例的初稿生成； + +1. **边界自检** +——主动穷举空值、异常版本、权限缺失、环境差异等分支，这是最容易被人类作者忽略的部分； + +1. **批量落地** +——同一份逻辑同时覆盖宿主机与容器、同时适配多台机器，把一次性排查变成可复用工具。 + +对应的，也有必须守住的边界： +- **应急响应的启动标准必须由人定义，不能由模型推断，否则流程会失去一致性；** +- **模型可能给出似是而非的 CVE 编号、版本号、PoC 细节，所有事实性内容必须回到官方公告核对；** +- **版本比较、区间判定这类"看起来简单"的逻辑，恰恰是误报漏报的高发区，必须用真实数据回归验证；** +- **暂无 POC、或像微软这类无法用 POC 直接验证的场景，仍以人工跟进全流程闭环为主——这是流程图上明确写下的 PS。** +六 +这套方法能迁移到另外 6 类场景吗 + +能，而且迁移成本比想象中低 - - 因为 7 类场景共享同一个骨架：**监测 → 内化 → 应用 → 验证** +，变的只是"内化阶段要产出哪些字段"。 + +漏洞预警 + +内化阶段抽取什么 +　原理、细节、POC、利用条件 + +应用阶段的动作大致是什么 +　范围排查 → 推修复 → 验证（已跑通） + +投毒预警 + +内化阶段抽取什么 +　软件名称与版本、IOC、C2 + +应用阶段的动作大致是什么 +　依赖清单比对 → 定位投毒版本 → 阻断 + +APT 追踪 + +内化阶段抽取什么 +　TTPs、恶意样本 + +应用阶段的动作大致是什么 +　映射到检测规则 → 补 BAS 用例 + +攻击事件 + +内化阶段抽取什么 +　TTPs、企业安全建设启发 + +应用阶段的动作大致是什么 +　自查同类弱点 → 整改 + +敏感信息泄露 + +内化阶段抽取什么 +　泄露主体、仓库、时间 + +应用阶段的动作大致是什么 +　定位责任人 → 下架 → 溯源 + +安全技术分享 + +内化阶段抽取什么 +　工具、手法、思路、建设经验 + +应用阶段的动作大致是什么 +　评估可用性 → 试点落地 + +产品漏洞信息 + +内化阶段抽取什么 +　受影响产品与版本 + +应用阶段的动作大致是什么 +　走 PSIRT / 产线流程 + +**只要"内化"这一步能把非结构化信息压成固定字段，"应用"和"验证"就能被标准化。** + 这也是我们坚持先把漏洞预警这一类做扎实的原因 - - 它是这套骨架最完整的样本。 + + +七 +落地清单：如果你也要做，先做这 11 件事 +1. **信源先固定（5 类足够），先解决去重与排序，别急着上模型；** +1. 内化阶段**强制产出"利用条件表"** +，字段固定，不产出不算完成； + +1. **应急响应的启动标准由人定义并书面化，不允许模型推断；** +1. 每一条利用条件，都必须有**对应的可执行检测逻辑** +，否则它只是描述； + +1. 脚本必须穷举四类分支：**空值、异常版本、权限缺失、环境差异** +； + +1. 排查动作必须**同时覆盖宿主机与容器** +两类运行环境； + +1. 结论输出要能被非作者直接读懂：**一句话结论 + 命中明细 + 日志路径** +； + +1. 每一轮修复**写进版本注释** +，保留可追溯的变更记录； + +1. 验证环节必须留**回退路径** +，验证不通过能退回修复阶段； + +1. 暂无 POC / 无法用 POC 验证的场景，**老老实实人工跟进闭环** +； + +1. 先给流程**逐环节定级** +（L0–L3），不要用排查环节的成熟度代表整体成熟度。 + +结语 + +漏洞预警这件事， +AI 的价值不在于"替人做判断"，而在于**把判断的输入准备好、把判断的结论落成动作** +。 + +流程上，它把"监测 → 内化 → 应用 → 验证"四阶段里最耗人力的信息处理和重复动作接了过去；工具上，它让一份排查脚本可以在几轮迭代内，从"能跑"变成"敢在几万台机器上跑"。 + +CVE-2026-42945 的脚本从最初版本迭代到 v1.0.2，改的其实只有三件事：**别误报、别中断、别漏查** +。这三件事，恰好就是漏洞预警从"看起来做了"到"真的做了"之间的距离。 + +而流程图上那句红字依然成立 - - + **最关键和最难的环节是漏洞分析与研判，需要人工参与** +。AI 让我们更快地走到这一步，但这一步，仍然需要人。 + +**📎 领取资料** + +本文那张《漏洞预警流程 —— AI 驱动四阶段闭环体系》全景流程图，提供**可编辑源文件（drawio 格式）** +，可直接改成你所在团队的组织架构与流程节点。 + +在公众号后台回复 +全景图 +，即可获取。 + + diff --git a/doc/2026-09/APP漏洞挖掘全套自动化工具（自动化检测程序+漏洞报告模板+检测指南）.md b/doc/2026-09/APP漏洞挖掘全套自动化工具（自动化检测程序+漏洞报告模板+检测指南）.md new file mode 100644 index 00000000..1c88994a --- /dev/null +++ b/doc/2026-09/APP漏洞挖掘全套自动化工具（自动化检测程序+漏洞报告模板+检测指南）.md @@ -0,0 +1,49 @@ +# APP漏洞挖掘全套自动化工具（自动化检测程序+漏洞报告模板+检测指南） +原创 鼹鼠 + 鼹鼠 知树安全团队 2026-09-19 16:00 + +迅雷链接： + +https://pan.xunlei.com/s/VP1u4ZcMD8N10WrZQdT0x7tuA1?pwd=8p2m# + +夸克链接： + +https://pan.quark.cn/s/d043f0749b06 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/h0MX7S28K30AfibL5uvOBdhaZyic7Admf1SmjVtA4YqF9Cu3clYzkKlbrP3n1Y8a1mvspDAic5ibZFEKNHMPZPib9n8QDEhuic0ACuhaHBzBeeaDc/640?wx_fmt=jpeg "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/h0MX7S28K33ZBgNs94hgDAy9uxAx9PTokGR9mEibbMrD8HDztBibFOGpSqtV70ibIGQKPSBT5nJXtz0KervuRkGhp6mNU44UlDP5icuT75cS6vc/640?wx_fmt=jpeg "") + + +👆点击上方公众号👆 + +回复下边四位数字获取免费资料！ + +1120 +：全套免杀课程 + +1121 +：安全杂志电子版 + +1122 +：常用高效爆破字典 + +1123 +：全套逆向课程 + +1124 +：国家信息水平测试全套课程 + +1125 +：CNVD证书挖掘技巧合集 + +1126 +：上心挖洞培训课程 + +1127 +：外网CVE漏洞POC + +![](https://mmbiz.qpic.cn/mmbiz_jpg/h0MX7S28K33LeVg1BSQ7kiaWt3Ch1DJW0UyVDTnteqB0oNQm4mA1icH9GujUcCBuOItuJ55TU1YoDQc9XTbjGQUrtGkia53wB54fk2YmiaRAMC0/640?wx_fmt=jpeg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/h0MX7S28K31AbEhruI1dF4eoFQWgLiaDzNTyMOIN6FeiciaCP9s7rr1ia27sQic7OR1E4Dt2vj1NdCS8TSnqGSlVrd9vMvq1aYbW1KzKMQqB17b8/640?wx_fmt=jpeg "") + diff --git a/doc/2026-09/Adobe 修复了 Magento 零日漏洞，该漏洞已被利用来部署 Rust 后门和 PHP Web Shell.md b/doc/2026-09/Adobe 修复了 Magento 零日漏洞，该漏洞已被利用来部署 Rust 后门和 PHP Web Shell.md new file mode 100644 index 00000000..2cef152a --- /dev/null +++ b/doc/2026-09/Adobe 修复了 Magento 零日漏洞，该漏洞已被利用来部署 Rust 后门和 PHP Web Shell.md @@ -0,0 +1,57 @@ +# Adobe 修复了 Magento 零日漏洞，该漏洞已被利用来部署 Rust 后门和 PHP Web Shell +Rhinoer + Rhinoer 犀牛安全 2026-09-19 16:00 + +![](https://mmbiz.qpic.cn/mmbiz_png/vO1zY1O9p8KOtsBmKibHK3nI6W0ia6dEKvjzbNl0C3OE3iciaJh6tPiboYJtXGxV8HmYjtsQxc7UelibgCRqyo3RfMntFHnCQFqBGz4TqMIzKaiaJA/640?wx_fmt=png&from=appmsg "") + +Adobe 周一发布了安全补丁，以解决影响 Adobe Commerce 和 Magento Open Source 的最高级别漏洞，该漏洞已被公开利用。 + +该漏洞目前被追踪为**CVE-2026-75650**（CVSS 评分：10.0），由 Sansec 命名为StyleSmuggler，Sansec 发现该漏洞将于 2026 年 9 月 4 日开始遭受零日攻击。 + +Adobe表示： “此次更新修复了一个可能导致任意代码执行的严重漏洞”，并补充说，“我们意识到 CVE-2026-75650 已被恶意利用，目标是 Adobe Commerce 商家。” + +该漏洞的核心在于利用 PHP 代码注入滥用 Magento 的模板系统，生成“支付交易失败提醒”电子邮件，并在过程中触发代码执行。 + + +该缺陷影响以下版本—— +- Adobe Commerce +- 2.4.9-2026年8月及之前 +- 2.4.8-2026年8月及之前 +- 2.4.7-2026年8月及之前 +- 2.4.6-2026年8月及之前 +- 2.4.5-2026年8月及之前 +- 2.4.4-2026年8月及之前 +- Adobe Commerce B2B +- 1.5.3-2026年8月及之前 +- 1.5.2-2026年8月及之前 +- 1.4.2-2026-8 月及之前 +- 1.3.4-2026年8月及之前 +- 1.3.3-2026年8月及之前 +- Magento 开源 +- 2.4.9-2026年8月及之前 +- 2.4.8-2026年8月及之前 +- 2.4.7-2026年8月及之前 +- 2.4.6-2026年8月及之前 +补丁已作为热修复程序的一部分发布，可从以下链接下载：repo.magento[.]com/patch/VULN-39341-composer-patches.zip + +Adobe表示： “为了帮助解决受影响产品和版本的漏洞，您必须应用 VULN-39341 补丁（取决于您的版本）并轮换您的加密密钥。 ” + +就在几天前，这家荷兰电子商务安全公司披露，攻击者正在利用 CVE-2026-75650 漏洞部署一个基于 Rust 的 Linux 后门程序，该后门程序会连接到外部服务器并等待进一步指令。此外，该漏洞还被滥用，用于在易受攻击的网站上投放 PHP 投放器，该投放器会写入一个能够执行任意 PHP 代码的 Web Shell。 + +据总部位于荷兰的 Disrex 公司称，电子商务开发平台管理的 Magento 服务器在 2026 年 9 月 4 日晚上 10:20（UTC）首次确认的 StyleSmuggler 漏洞利用事件发生 50 分钟后遭到入侵。 + +Disrex 表示：“StyleSmuggler 将 Magento 自身的模板处理和依赖注入代码转换为未经身份验证的远程代码执行链。” + +Previdian的遥测数据显示，自2026年9月7日以来，其蜜罐遭到了12次攻击，攻击者分别来自中国和罗马尼亚的两个独立IP地址。不过，创始人兼首席执行官Ryan Dewhurst表示，这些攻击均未成功。 +### 更新 + +美国网络安全和基础设施安全局 (CISA) 于 2026 年 9 月 8 日将 CVE-2026-75650添加到其已知利用漏洞 ( KEV ) 目录中，要求联邦民事行政部门 (FCEB) 机构在 2026 年 9 月 11 日之前应用修复程序。 + +与此同时，Adobe 还发布了针对其产品中 170 多个漏洞的补丁，其中包括 CVE-2026-82004（CVSS 评分：10.0），这是一个 Campaign Classic 中的操作系统命令注入漏洞，会导致任意代码执行。 + +Adobe 还修复了 ColdFusion 中的两个严重漏洞（CVE-2026-48273，CVSS 评分：9.9；CVE-2026-75746，CVSS 评分：9.1），这两个漏洞可能导致任意代码执行。这家网页设计软件制造商表示，目前尚未发现任何利用这些漏洞的攻击。 + + +信息来源： +The Hacker News + diff --git a/doc/2026-09/Claude Code、Codex、Copilot与Gemini CLI四大编程代理惊爆零点击RCE.md b/doc/2026-09/Claude Code、Codex、Copilot与Gemini CLI四大编程代理惊爆零点击RCE.md new file mode 100644 index 00000000..12f0c5a5 --- /dev/null +++ b/doc/2026-09/Claude Code、Codex、Copilot与Gemini CLI四大编程代理惊爆零点击RCE.md @@ -0,0 +1,88 @@ +# Claude Code、Codex、Copilot与Gemini CLI四大编程代理惊爆零点击RCE +原创 网空闲话 + 网空闲话 网空闲话plus 2026-09-18 23:35 + +据Air Security研究实验室9月17日的博文披露，一个名为 +**Plugin4Shell** +的零点击远程代码执行漏洞，同时影响Claude Code、OpenAI Codex、GitHub Copilot和Gemini CLI。Air Security称其为首个AI代理生态供应链漏洞；其核心不是模型被越狱，也不是单一产品实现失误，而是四家厂商在插件安装与自动更新中重复了同一个设计错误：**代理按市场提供的SHA固定值检出代码，却从不验证工作目录中实际落地的提交是否就是被固定的提交** +。结果是，经过审查、已被信任并固定的插件，可在用户毫无交互的情况下被替换为恶意版本，攻击者由此获得与使用者同等权限的远程代码执行能力。Air Security估计，潜在受影响代理规模达数百万。 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/lQ1jXOMq3d3TBL7TQTOuQjhZUppEHjibAvoRHs2RWjAEqRORXT8YvsAWvaIpdtqCJCxKJgKeyy0NicJzIMeAWuCwpNv2ib5lQjbdnuAPUY2Zls/640?wx_fmt=webp&from=appmsg "") +### 一、漏洞成因与机制 + +AI代理的插件和技能通常来自开放社区市场。企业安装插件后，代理会继承员工对敏感数据、内部系统和生产环境的访问权限。为防“先审查、后投毒”的供应链攻击，行业普遍采用**SHA pinning** +：市场审查某一提交，将插件固定到该Git提交，理论上后续上游变化不应影响已批准版本。 + +Plugin4Shell恰恰破坏这一保证。代理执行类似git clone +后git checkout +，但Git在名称同时是有效引用和对象ID时，会优先解析为引用，只打印“refname is ambiguous”警告。攻击者控制插件仓库后，可创建一个名称正好等于40位固定SHA的分支，并将其设为默认分支。于是git checkout +检出的是恶意分支，而非固定提交；代理却报告“安装成功”。更危险的是，相同检出逻辑会在后台自动更新时再次运行。Claude Code和Codex默认自动更新已安装插件，因此市场一旦更新固定值，恶意替换就会无提示、无点击地进入已安装环境。 + +Gemini CLI的机制略有不同：它使用git clone --depth 1 +、git fetch origin +，再执行git checkout FETCH_HEAD +。若仓库默认分支本身命名为FETCH_HEAD +，检出会解析到该分支，正确获取的提交被静默丢弃，攻击者默认分支内容得以执行。有效修复必须在代理侧完成：检出后解析实际HEAD，并断言其等于固定SHA，否则中止安装： + +bash +``` +``` + + +关键是要检查解析后的HEAD，而不是请求的引用名。由于固定值在客户端解析，市场端无法独自修复该问题。 + +
代理固定与安装机制利用变体关键条件修复状态
Claude Codeclone后checkout固定SHA创建40位SHA同名分支并设为默认托管平台允许SHA形分支名；默认自动更新Anthropic已在2.1.179修复
Codexclone后checkout固定SHA同上同上；默认自动更新OpenAI已在0.146.0验证修复
GitHub Copilotclone后checkout固定SHA同上同上截至2026年9月17日Air Security未获修复确认；披露称微软尚未发布补丁，用户暂无补丁
Gemini CLIclone --depth 1，fetch固定SHA，checkout FETCH_HEAD默认分支命名为FETCH_HEAD默认分支为FETCH_HEADGoogle不修复，建议迁移Antigravity；企业及付费API用户支持情况需向Google确认
+### 二、零点击攻击链 + +Plugin4Shell有两条主要利用路径。其一，攻击者先向受信任市场发布真正良性的插件，通过审查并获得采用，随后将上游内容替换为恶意版本。其二，劫持合法作者的插件仓库，再利用Plugin4Shell绕过版本固定，将恶意版本推送给所有已安装代理。Air Security此前已在“The Story of Skills”中证明恶意技能可感染超过26,000个代理，在“SkillJacking”中证明925个技能被劫持、影响134,000个代理。前置投毒与仓库劫持已被证明可大规模发生，Plugin4Shell则补上了绕过防护机制的关键一步。 + +
步骤动作结果
1、植入攻击者发布良性插件，固定于提交aaa...aaa通过审查
2、采用用户安装均固定到受审版本aaa...aaa
3、版本更新市场将固定值更新到新的良性提交bbb...bbb固定值改变
4 、Rug-pull攻击者创建名为bbb...bbb的分支，设为默认并指向恶意代码原固定提交可保持不动
5、自动更新至RCE固定值变化触发后台自动更新，检出将bbb...bbb解析为分支并执行无提示、无点击
+ +对Claude Code、Codex和Copilot，利用前提是插件托管平台允许40位十六进制SHA形式的分支名，并且该分支为默认分支。GitHub会拒绝此类分支名，但Bitbucket及部分自托管Git服务器允许，而Anthropic官方文档也把Bitbucket和自托管Git列为市场后端。Gemini CLI的FETCH_HEAD变体则不受同样限制。 +### 三、影响范围与潜在后果 + +影响不限于粗心安装插件的用户。即使组织严格审查插件并将版本固定到已审提交，Plugin4Shell仍会令审查通过、固定写入，却安装不同代码。所有下游基于pinning的审核流程都会继承这一失败。攻击者获得的是员工级权限，可触及代理能访问的全部资产和数据；在CI环境中，还可能危及部署密钥、签名材料和注册表令牌。Air Security特别说明，使用Air Marketplace和Air Filter的企业未受Plugin4Shell影响。 +### 四、披露时间线与修复进度 + +
时间事件
2026年5月Air Security研究实验室发现Plugin4Shell，并针对四个代理完成可工作的PoC
2026年6月依据协调披露流程，向四家厂商披露
2026年6月17日Anthropic确认Claude Code 2.1.179修复
2026年8月4日Google确认Gemini CLI不再修复，建议迁移至Antigravity；SecurityLab澄清，Google仍为企业和付费API用户保留Gemini CLI支持，消费者层自2026年6月转向Antigravity CLI
2026年8月12日Codex 0.146.0验证修复
2026年9月17日Air Security发布技术分析。截至当日，未获GitHub Copilot修复确认
2026年9月18日SecurityLab报道该漏洞
+### 五、关联案例：GitSpawn与SymJack + +Plugin4Shell并非孤立事件。GitSpawn显示，Claude Code、Qwen Code、Grok Build等代理在后台执行git status +、git diff +时，未清理项目.git/config +中的core.fsmonitor +等危险配置，恶意项目可令Git在索引更新时执行任意命令。该攻击需项目携带.git +目录，例如ZIP、同步目录或外接存储。Manifold Security共发现7款代理中的8个问题；Goose获CVE-2026-72718，评分7.0；Hermes获CVE-2026-71963。Claude Code 2.1.196、Goose 1.44.0、Codex和Cursor已修复，但Qwen Code 0.22.3、Grok Build 1.0.13、Hermes 0.21.0及Claude Code ultrareview 2.1.252截至2026年9月1日仍未修复。 + +SymJack则利用符号链接与确认窗口的认知差：用户以为在复制视频文件，实际写入的是MCP配置，重启后代理加载恶意服务器并执行命令，可导致SSH密钥、云令牌和会话数据泄露。Adversa AI的Рони Утевски测试了Claude Code、Gemini CLI、Antigravity CLI、Cursor Agent CLI、GitHub Copilot CLI、Grok Build和OpenAI Codex CLI。供应商反应不一：Anthropic曾拒绝报告但后来强化确认窗口；Google和Cursor未认定为新漏洞；OpenAI称Codex CLI场景为理论性；GitHub和xAI未回应。 + +
漏洞披露时间研究者主要影响对象核心机制修复与状态
GitSpawn2026年9月4日Manifold SecurityClaude Code、Qwen Code、Grok Build等7款代理后台Git调用未清理.git/config，core.fsmonitor可执行任意命令Claude Code 2.1.196、Goose 1.44.0、Codex、Cursor已修复；四个变体截至9月1日仍开放
SymJack2026年5月31日Adversa AI的Рони УтевскиClaude Code、Gemini CLI、Antigravity CLI、Cursor Agent CLI、GitHub Copilot CLI、Grok Build、OpenAI Codex CLI符号链接+确认窗口不完整，写入MCP配置后重启执行供应商反应不一，Anthropic后续强化确认窗口
+### 六、评论与缓解建议 + +Air Security强调，因为pin在代理内部解析，市场无法完全关闭该漏洞，只有代理侧修复才能恢复保证；市场端只能通过只允许拒绝SHA形分支名的托管商来削弱分支名变体，实际等于GitHub-only，但这会排除代理官方支持的托管商，且对Gemini CLI变体无效。SecurityLab也指出，仅控制扩展目录不够，可靠修复必须比较实际HEAD与固定SHA。Manifold Security建议检查.git/config +，开发者应禁用后台Git调用中的危险参数。Adversa AI认为确认模型本身是弱点，建议检查符号链接、禁止代理通过shell写入配置目录、关闭项目MCP自动启动，并隔离处理不可信合并请求的CI环境。 + +综合来看，Plugin4Shell与GitSpawn、SymJack共同说明：AI代理的安全边界已从模型扩展到插件市场、Git解析、项目配置和确认界面。只审查市场不够，只固定SHA也不够；代理必须在本地验证实际执行的代码，行业也需要把插件权限、自动更新和Git行为纳入纵深防御。 +### 参考文献 +1. Air Security.  +Plugin4Shell - Zero Click RCE Vulnerability found in top 4 most popular coding agents, millions of agents affected +. 2026-09-17.  +https://www.air.security/blog-posts/plugin4shell + +1. SecurityLab. Zero-click RCE сразу в четырёх крупнейших ИИ-агентах Claude Code, Codex, Copilot и Gemini +. 2026-09-18.  +https://www.securitylab.ru/news/577550.php + +1. SecurityLab. Открыл папку с кодом — и уже поздно. GitSpawn атакует Claude Code, Grok, Qwen и другие ИИ-агенты +. 2026-09-04.  +https://www.securitylab.ru/news/576900.php + +1. SecurityLab. Согласился скопировать видео, потерял SSH-ключи. Атака SymJack разводит программистов и их ИИ-помощников +. 2026-05-31.  +https://www.securitylab.ru/news/573200.php + +[#人工智能]() +[#漏洞分析]() +[#四大AI巨头]() + + diff --git a/doc/2026-09/JumpServer越权漏洞：URL里加个参数，管理员Access Key直接裸奔.md b/doc/2026-09/JumpServer越权漏洞：URL里加个参数，管理员Access Key直接裸奔.md new file mode 100644 index 00000000..cabcdaf1 --- /dev/null +++ b/doc/2026-09/JumpServer越权漏洞：URL里加个参数，管理员Access Key直接裸奔.md @@ -0,0 +1,132 @@ +# JumpServer越权漏洞：URL里加个参数，管理员Access Key直接裸奔 +原创 承影 + 承影 兰花豆说网络安全 2026-09-19 00:38 + +国产开源堡垒机JumpServer曝出高危越权漏洞（QVD-2026-65008），任意普通登录用户在API请求附加_rel=not参数，即可读取所有用户的Access Key明文，进而以管理员身份接管堡垒机。 + + +晚上十点，运维小张正准备下班，钉钉群里弹出一条安全通告：JumpServer Access Key越权泄露漏洞，高危，尽快升级。 + + +他心里咯噔一下。公司几百台服务器的运维入口全走JumpServer，开发人员、外包、实习生，有账号的少说几十号人。要是这些人里随便哪个动点歪心思，在请求里加一个参数，就能把管理员的Access Key明文读出来——那等于整个机房的大门钥匙被人复印了一把。 + + +小张默默打开电脑，开始查版本。 + +## 一、漏洞原理：一个查询参数撬开的大门 + +这次漏洞的根源，是JumpServer的SQL查询过滤存在缺陷。 + + +正常逻辑下，普通用户调用用户列表接口，只能看到自己权限范围内的信息。但攻击者发现，只要在API请求里附加一个 _rel=not 的查询参数，就能绕过权限过滤，越权读取所有用户的Access Key Secret和TempToken明文。 + + +更致命的是，如果环境开启了AUTH_TEMP_TOKEN，攻击者拿着偷来的临时令牌，可以直接以管理员身份登录堡垒机。到这一步，事情就从"信息泄露"升级成"全面沦陷"——堡垒机纳管的所有服务器、所有运维会话、所有审计记录，全部对攻击者敞开。 + + +堡垒机是干什么的？是企业运维体系的总闸门。所有对生产服务器的访问都从这过，权限分级、会话录像、操作审计全指着它。总闸门自己漏了，后面的门再结实也没用。这就像小区的保安室钥匙被配了把万能钥匙，每家每户的门锁都没动，但整个小区已经不安全了。 + +## 二、影响范围和修复版本 + +奇安信给这个漏洞的评级是高危，漏洞编号QVD-2026-65008，GitHub安全公告编号GHSA-6rp5-ff2m-qfrm。利用门槛极低——不需要什么高深技术，一个普通的登录账号加一个查询参数就够了。漏洞由Smart Oasis的GitHub用户@sajjadhaqi在8月提交，JumpServer官方9月9日发布修复公告。 + + +受影响的版本范围： + +V3版本：大于等于v3.7.0，小于v3.10.23 LTS； + +V4版本：大于等于v4.0.0，小于v4.10.19 LTS。 + + +安全版本是v3.10.23 LTS和v4.10.19 LTS及以上。社区版和企业版都在影响范围内。JumpServer在国内的装机量不用多说，互联网、金融、政企、制造业，用它的单位一抓一大把，这个影响面相当可观。 + +## 三、修复方案：升级优先，临时有招 + +正路当然是升级。把JumpServer升到v3.10.23 LTS或v4.10.19 LTS以上，一了百了。 + + +如果一时半会儿升不了（比如生产环境有变更窗口限制），官方给了临时缓解方案：在Nginx层禁用这个过滤参数。 + + +HTTPS启用的环境， + +改/opt/jumpserver/config/nginx/lb_http_server.conf； + + +没启用HTTPS的，改jms_web容器里的 + +/etc/nginx/conf.d/http_server.conf，在location块里加一段规则，匹配到 _rel= 参数（包括URL编码形式）直接返回400。 + +改完提交容器变更、重启jms_web容器生效。 + + +修完怎么验证？官方给了三条curl命令：带 _rel=not 参数的请求期望返回400，带URL编码形式 %5Frel=not 的期望返回400，不带参数的正常请求期望返回401或403。三条都符合预期，说明缓解生效。 + + +注意，临时方案只是堵住了这一个利用路径，治标不治本，窗口期过后还是要排期升级。 + +## 四、升完级别急着收工，还有几件事 + +第一，轮换凭证。 +既然漏洞存在期间Access Key可能已经泄露，光升级不算完，管理员和关键用户的Access Key、TempToken全部重新生成一遍，历史泄露的密钥作废，这步省了等于白修。 + + +第二，翻日志。 +往前查API访问日志，重点看带 _rel=not 或 %5Frel=not 参数的请求记录，看看漏洞公开之前有没有可疑调用。有普通账号频繁调这种接口的，顺着账号往下查。 + + +第三，盘一盘账号权限。 +这次漏洞的利用前提是"任意已登录用户"，你系统里那些离职没销的、外包项目结束没回收的、实习生共用账号，都是潜在入口。借着这次机会做一次账号清理，最小权限该收紧的收紧。 + + +第四，想想纵深。 +堡垒机这种单点价值极高的系统，除了等厂商补丁，网络层的访问控制、异常API调用的监测告警，平时就得配上。这次是一个参数的问题，下次可能是另一个参数。 + + +这几年国产开源组件的漏洞响应速度肉眼可见地在提升，从8月收报告到9月发修复公告、给出临时方案和验证命令，JumpServer这次的处理算得上周到。但组件靠谱不等于用的人可以躺平——开源软件用的人越多，漏洞公开后被批量扫描利用的速度就越快。 + + +通告发出来那一刻起，攻防的倒计时就开始了。你的堡垒机，今晚查了吗？ + +![](https://mmbiz.qpic.cn/sz_mmbiz_gif/buQYO9JqQcqHibMSbuUlH1q4N0BqiaJT4A81RZWbGMibEU57wlC7W6ryRDOF3vnn8UEfjlTdxeyEovsOzIibw7B11Xp7353IVMKgugHfLB4YWic4/640?from=appmsg "") + +END + +推荐阅读 + +[网信办最新通报的10个案例，每一个都像在说你公司](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493912&idx=1&sn=d69ea89513c346d56af1ac05c7454e68&scene=21#wechat_redirect) + + +2026-09-18 +[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493912&idx=1&sn=d69ea89513c346d56af1ac05c7454e68&scene=21#wechat_redirect) + + +[湖南7家大模型运营单位出现安全围栏漏洞](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493907&idx=1&sn=da9d419af5e83b4ee65e4e05f8264bcd&scene=21#wechat_redirect) + + +2026-09-17 +[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493907&idx=1&sn=da9d419af5e83b4ee65e4e05f8264bcd&scene=21#wechat_redirect) + + +[网络安全的春天，真的来了](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493902&idx=1&sn=5b5bc0912422d61454d0cb50b8be93d0&scene=21#wechat_redirect) + + +2026-09-13 +[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493902&idx=1&sn=5b5bc0912422d61454d0cb50b8be93d0&scene=21#wechat_redirect) + + +[微信史诗级零点击漏洞：一通语音电话，账号就被隔空接管](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493895&idx=1&sn=4669be4aaa362b64af3764102226d2cb&scene=21#wechat_redirect) + + +2026-09-11 +[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493895&idx=1&sn=4669be4aaa362b64af3764102226d2cb&scene=21#wechat_redirect) + + +[参编邀请 | 全国首部“AI生成内容合规”标准，欢迎加入编制组！](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493890&idx=1&sn=010dae1fdb791cf9eb2db0679ab498a7&scene=21#wechat_redirect) + + +2026-09-10 +[](https://mp.weixin.qq.com/s?__biz=MzI3NzM5NDA0NA==&mid=2247493890&idx=1&sn=010dae1fdb791cf9eb2db0679ab498a7&scene=21#wechat_redirect) + + + diff --git a/doc/2026-09/Windows 内核 WMI 计数回绕 CVE-2026-42980.md b/doc/2026-09/Windows 内核 WMI 计数回绕 CVE-2026-42980.md new file mode 100644 index 00000000..92932eaa --- /dev/null +++ b/doc/2026-09/Windows 内核 WMI 计数回绕 CVE-2026-42980.md @@ -0,0 +1,231 @@ +# Windows 内核 WMI 计数回绕 CVE-2026-42980 + Ots安全 2026-09-19 06:58 + +**威胁简报** + + +**恶意软件** + + +**漏洞攻击** + +2026 年 6 月 9 日，微软的六月安全更新日，一条编号为 CVE-2026-42980 的本地提权漏洞被列在 NT 内核名下，官方定级 Important，基础分 7.8，可利用性评为"更可能"。二十八天后的 7 月 7 日，一位自称计算机专业学生的研究者把这个洞的完整利用链放上 GitHub，链条终点是一行 nt authority\system +。再往后两周，英文媒体开始集中报道；又过了一个多月，中文渠道里流转的修复版本号仍然是错的，而那个错误足以让一次自查得出"已经安全"的结论。 + +本篇要核三件事。编号层的定级是否可信，机制描述的唯一来源是谁，以及一条错误的版本号是怎么从一家媒体流进中文通告的。 +## 一、原因导致：一处没有守卫的减法 + +本章的全部内容都来自研究者的补丁对比与静态逆向。厂商从未公布函数名、接口号或算术位置，因此本章不构成厂商口径，这一点在 3.5 节会再说明一次。 +### 1.1 计数器在算一笔什么账 + +WMI 查询在内核里要完成一次序列化：把提供程序返回的数据块按调用方给的输出缓冲区逐个摆放，同时维护一个 32 位的剩余空间计数。 + +流程大体分两步。第一步按调用方给出的项目估算所需空间，估算值不大于剩余计数就放行。第二步等提供程序真的返回数据后，按实际长度对齐到 8 字节边界，再从剩余计数里减掉。**这个设计本身没有问题，问题出在第一步用的是估算值，第二步用的是实际值，而两者可以不一致。** + +落差来自对齐这个动作。第一步的估算按调用方给出的名称或数据长度计算，第二步按提供程序返回的真实长度向上对齐到 8 字节边界。对齐本身会引入最多 7 个字节的增量，而在特定长度上，这个增量足以让实际值越过估算值。 + +**缺陷不需要任何人写错一个数。它需要的是两个阶段用两套口径计算同一个量，并且中间没有人做一次比较。** + 这类形态在代码审查里几乎查不出来，因为两处代码相隔很远，各自单独看都成立。 +### 1.2 两条只差一位的查询路径 + +研究者给出的两个接口号是 0x22812C + 与 0x228130 +。把这两个值按 Windows 的接口编码位域拆开，可以看到一个能自行核对的结构： + +``` +0x22812C   DeviceType 0x22   Function75   Access FILE_WRITE_ACCESS   Method METHOD_BUFFERED +0x228130   DeviceType 0x22   Function76   Access FILE_WRITE_ACCESS   Method METHOD_BUFFERED +``` + + +四项位域里有三项完全相同，只有功能号相邻差一位。这符合"同一组件的一对兄弟操作"的形态，与研究者给的两个函数名（一个处理多数据块查询，一个处理单实例多次查询）在结构上对得上。同一位域里的 Method 值为 0，即缓冲模式，这也与研究者在 4.2 节描述的缓冲区分配方式一致。 + +**这一段核对的价值在于，它把接口号从"研究者的一家之言"提升到了"内部自洽、可以独立验算"。** + 但它仍然不能证明这两个接口号就是厂商修补的那两处，因为验证这件事需要可读的内核差异。 +### 1.3 闸门用的值与实减用的值不是同一个 + +把链条的核心讲成一句话：**减去一个数之前，没有确认这个数不大于被减数。** + +无符号整数相减一旦为负，结果不是负数，而是回绕到一个接近类型上限的巨大值。研究者与截图共同给出了一个具体窗口：剩余计数为 0x94，对齐后的实际尺寸为 0x98，相减得到 0xFFFFFFFC。这个值换成十进制是 4,294,967,292 字节，比 4 GB 少 4 个字节。 + +写进正文的这三个数都经过复算。截图里两项输入的尺寸与按估算公式算出来的结果逐项吻合，0x94 减 0x98 的回绕结果也与 4 GB 这个量级吻合。**算术本身可以验算，这一点是本篇能给出机制的量化描述、而不只是名词堆叠的原因。** + +**同一条缺陷之所以危险，不在于减法写错了符号，而在于做这个减法之前少了一次比较。** + 一次比较的成本是一个分支，省掉它换来的却是对内核池剩余空间的错误认知。 + +回绕后的数值在操作上的意义是容量错觉。内核认为手里还有 4 GB 的空间可以摆放数据，于是不再做任何换缓冲区或截断的处理，继续往下写。**从这一刻起，写入边界已经不由缓冲区决定，而由攻击者提供的数据长度决定。** + 一次比较的成本是一次分支预测，而省掉它换来的是整个内核堆的写权限。 +### 1.4 修复的形态与一个前置开关 + +研究者对修复的描述是：把不受检查的减法换成带饱和保护的减法，使得被减数小于减数时结果被钳到 0 而不是回绕。他同时给出一个细节，该修复被一个内部特性开关守卫。 + +这个细节如果成立，含义不小。**特性开关意味着同一份更新里可能同时存在修复前后的两条代码路径，走到哪一条取决于开关状态，而开关状态不由更新包决定。** + 也就是说，一台装着六月更新的机器，其内核里是否有生效的修复，不能仅从版本号推出来。 + +必须把边界写清楚：**这一点只有一个来源，没有厂商说明，也没有第二方复核。公开信息未说明该开关的默认状态、推送范围与判定方式。** + 本篇把它作为观察记录，不作为结论，也不据此给出任何处置建议。 +### 1.5 机制描述的确认边界 + +有一位第三方分析者在同一时期明确写过：有追踪平台把该缺陷归到 WMI 子系统，但该归属未获微软确认，应视为未证实。 + +这句话需要原样接住。本章乃至第四章里出现的函数名、接口号与算术位置，**全部是研究者的逆向结论，不是厂商口径** +。厂商给出的可核事实只有六项：内核归属、弱点类别、定级与分数、受影响产品清单、可利用性评级、以及"成功可获得 SYSTEM 权限"。 + +**把两者混着读，会得出一个错误的印象：以为 WMI 这条路径是厂商确认过的。** + 正确的读法是分开记：官方确认的是严重性，研究者主张的是位置。**官方确认的那一半不依赖研究者，研究者主张的那一半也不因为官方没否认而成立。** +## 二、漏洞触发：从计数回绕到令牌替换 +### 2.1 触发点为什么选在后一条路径 + +两条路径都存在同一个减法缺陷，但研究者选的是后一条（接口号 0x228130 +）。理由是该路径的估算闸门取决于调用方给出的项目尺寸，而后续的减法取决于提供程序实际返回的尺寸。两个值分属不同来源，中间就存在一个可以被撑开的落差。 + +**这个选择本身是一条方法论：同一类缺陷在同一个组件的不同入口上，可利用性可以差很远，差别来自哪个入口的两个值由不同方提供。** + +这里有一个需要标注的缺口。研究者只对后一条路径展开了闸门与实减的取值来源，前一条路径的闸门取值来自哪里，他的撰写文里没有展开，公开信息未说明。**因此"前一条路径不可利用"这句话在本篇里不成立** +，只能说公开材料没有给出它的可利用性分析。 +### 2.2 越界写入落在什么对象上 + +序列化在错误的剩余量下继续，把后续数据写到已分配缓冲区的末尾之外。这一步的关键在于数据可控：被复制的那一段里有一部分内容由调用方提供。 + +要把这个越界写变成可用的原语，需要让相邻位置正好是攻击者能观察的对象。研究者的做法是先用命名管道做池填充，制造一串同尺寸的连续分配，再挖一个洞，让内核把出问题的缓冲区分配到预定位置旁边。**这条链的可靠性不来自某一次幸运的对齐，而来自对内存分配器行为的主动塑形。** + +选管道作为目标对象有三个实用性理由。管道对象在用户态有完整的读接口，污染之后的变化不需要内核调试器就能观察。它记录的可读长度一旦被撑大，越读的量由这个字段决定，攻击者可控。管道对象本身是可批量创建的，批量创建等于把触发成功的概率从一次放大到多次。 + +**这三点合起来说明一件事：可利用性不只由缺陷本身决定，也由内核里有没有合适的邻居对象决定。** + 同一条缺陷换一个内核版本，可选邻居变了，工程成本也会变。 + +本节不给出触发输入的具体格式与池排布参数。这些内容在公开仓库里可以找到，但**公开存在与适合转载是两件事** +，本篇只描述到结构这一层。 +### 2.3 从信息泄露到任意读 + +越界写污染了相邻的管道数据结构，把它记录的可读长度撑大。此后一次对管道的常规窥探读取请求就能越读，把后面的内核池元数据取回用户态。 + +拿到元数据之后，研究者把被污染的结构重新塑形成另一种形态，使读取来源变成一个受控的内核地址。**到这一步，链条完成了一次质变：从"能越界写一小段"变成"能读内核任意地址"。** + +从写一小段到任意读，中间靠的不是新的漏洞，而是对一个已经能控制的内存结构做二次塑形。**这是内核利用里的常见手法，也是它难以通过单点加固拦住的原因：同一个初始原语可以被反复改造成新的原语。** + +这一层的意义在于能力升级的方向。越界写能改动的范围受限于相邻对象的布局，而任意读不受此限，它可以按地址去取任何内核结构。链条从受布局约束的一步，走到了不受布局约束的一步，后续的地址推导因此都建立在读取结果之上，而不是建立在猜测之上。 + +**判断一条内核利用链成不成熟，看的就是它有没有走到这一步。** + 停在越界写的利用需要精确命中目标结构，走到任意读的利用则可以按需检索，两者的工程成本差一个量级。 +### 2.4 令牌替换与收尾验证 + +拿到任意读之后，链条沿当前线程追溯到所属进程，再沿活动进程链走到进程号为 4 的系统进程，读出它的令牌。随后通过一条写路径把这个令牌值写进当前进程的令牌字段。之后修复被污染的管道结构，派生一个新的命令行进程，该进程继承新令牌。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/zNsFJyIuL0FaKqx1Ix8jGKIhFaoaoqqvtDlZRPbZGc83dKeXSJUuiakAyvUEEa5REUS94sMjZEleDqIicxh2T9PeWWBrVAnDiaN5c0XCe9yQ1o/640?wx_fmt=png&from=appmsg "") + +上图取自 PoC 仓库，是这一段的直接证据。左侧终端输出覆盖了从池元数据提取到外壳派生的完整过程，其中三处值得逐字看：trigger: DeviceIoControl ioctl=0x228130 + 与紧随其后的 returned=0x98 +，说明触发接口与返回尺寸；System token written to current process +，说明令牌替换这一步执行完成；SYSTEM shell spawned +。右上角命令行窗口的标题为管理员命令行，提示符前一行显示 nt authority\system +，当前目录是 C:\Users\grunt\Desktop +。 + +图里的终端数值还可以用来自核：两项输入的尺寸与按估算公式算出的所需空间逐项吻合，与前文那个 0x94 减 0x98 的窗口处在同一次运行里。**这张图因此不只证明"跑通了"，还证明"跑通时用的算术就是前面描述的那一套"。** +### 2.5 这条链的可靠性边界 + +研究者在撰写文里用一句话收束可靠性：这是在受测的易受攻击实验室配置中达到的可靠本地提权。他没有主张全部受影响版本都能以相同可靠性被攻破。有第三方分析者也提醒过，实验室里的成功不应被读成每一个受影响版本都能同样轻松地被打穿。 + +PoC 源码里还留了一处自述，它自己的输出文案在找不到被污染的管道时提示"填充未命中，重启后重试"。**这条链需要多次尝试，其中一部分尝试会因内存布局不理想而失败。** + 这属于可利用性的常规代价，不改变缺陷的成立，但会影响把它武器化所需的工程投入估计。 + +**读这一节要避免两个方向的偏差。** + 一个方向是拿"实验室里跑通"当成"生产环境一键提权"，另一个方向是拿"需要重试"当成"威胁被夸大"。**正确的读法是：机制成立，工程成本存在，两者都写进处置依据。** +## 三、补丁分析：一层计数与一条错误的版本号 +### 3.1 修复被放在哪一层 + +按研究者的描述，修复落在算术层：把回绕改成钳位。剩余计数一旦被钳到 0 而不是变成一个巨大的值，后续的序列化就没有空间可写，链条从第一步就断了。 + +这个位置的选择有它的道理。**在内核内存破坏类缺陷上，于算术层设界比在下游逐个检查写入更有收敛性** +，因为下游的写入点可能有很多个，而错误只有一处。研究者也据此认为，修复之后信息泄露、任意读写与令牌替换都会一并失效。 + +需要标注的是，**这个判断的依据仍然只有他一个来源** +。补丁不可逐行核，所以"修复是否彻底"这件事，本篇给不出独立结论。 + +把修复放在算术层还有一个可观测的副作用，它让"是否已修复"这件事在行为上变得不容易验证。如果修复点在下游的某一处写入，防御方可以通过观察该写入是否越界来判断。修复点在算术层时，越界写从第一步起就不会发生，没有任何可观察的中间态。**这也是为什么 6.1 节给出的核对办法只能是版本号比对，而不是行为观测。** +### 3.2 一个修复版本号的传播错误 + +有一家英文安全媒体在报道这篇 PoC 时写了这么一句：Windows 11 24H2 上，修复后的内核为 10.0.26100.1992 或更高版本。 + +这个数字与厂商清单不符。清单上 24H2 的修复 build 是 **10.0.26100.8655** +。两者的第三段差了六千多，这不是排版偏差。同一篇文章的摘要表里列的却是正确值，也就是说，**错误出现在正文撰写环节，而不在数据源上。** + +这个错误的影响是具体的。拿 10.0.26100.1992 去核对一台已打补丁的 Windows 11 24H2，会看到本机版本"更高"，从而判定为已修复。如果这台机器实际上还停在修复线之下，判定就是错的。 +### 3.3 同一天的两篇报道 + +2026 年 7 月 21 日，两家英文站点就同一条编号各发了一篇。一篇的标题是"公开 PoC 已发布"，另一篇在同日发布的分析里写"撰写时尚无公开利用代码"。 + +两篇都不算错，但放在一起看就出现了矛盾。PoC 仓库的创建时间是 7 月 7 日，比这两篇报道早 14 天。**同一编号、同一天、两个相反的利用状态表述，说明这个时间窗口里的信息同步是断裂的。** + +对读者的实用含义是：**不要用媒体报道来锚定"PoC 何时公开"。** + 仓库的创建与推送时间戳是接口给出的一手事实，媒体日期只是它被注意到的时间。 +### 3.4 中文转述链上的三处改动 + +中文侧最早的一条是编号通报，2026 年 6 月 11 日，定级高危，只收录编号与厂商公告链接，没有技术描述。这一条没有问题。 + +问题出现在后面的技术转述里。有一份中文情报通告沿用了 5.2 节那个错误的修复 build 号，并把受影响版本概括为"Windows 10 版本 1607 及多个后续版本"，实际上清单包含 Windows 11 的全部在支持版本与 Server 2012 起的服务器产品线。另有一篇中文复盘在技术描述里把内核池写成"内核堆栈"，并给出了若干无出处的判断句。 + +**传播链上的偏差有个共同特征：越靠后，具体数字越容易被改写，而判断句越容易被加上。** + 本篇的处置建议因此全部落在可核对的一手字段上，不落在任何转述的结论上。 +## 四、结束语 + +这条编号在公开记录里的形态，比它本身更能说明当前的披露节奏。厂商把严重性说清楚了，把受影响产品列全了，把可利用性评为"更可能"，唯独不说是哪一处代码。研究者把这一层补上了，但没有第二个人复核。中间隔着的二十八天，是补丁与利用之间的真实距离。 + +**这类结构的漏洞会越来越常见：归因与定级由厂商给，机制由研究者给，两者之间的确认环节是空的。** + 防御方能做的是把可核字段与转述结论分开记，把补丁状态落到具体的内核版本号上，把"已经装了就安全"这个默认假设换掉。 + +补丁日只是起跑线，**唯有把版本号核对到修复线之上、把本地低权限执行的入口一并收紧，这两件事同时做到，"更可能"这个评级才不落在自己头上。** +## 五、参考 + +``` +厂商公告（含定级、弱点、受影响产品与修复 build） +https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42980 + +CVE 记录（保留日、发布日、CNA 口径评分） +https://www.cve.org/CVERecord?id=CVE-2026-42980 +https://cveawg.mitre.org/api/cve/CVE-2026-42980 + +NVD 记录（确认未独立评分，唯一参考为厂商公告） +https://nvd.nist.gov/vuln/detail/CVE-2026-42980 + +GitHub 通告 +https://github.com/advisories/GHSA-jh49-99q5-mwf2 + +中文编号（CNNVD 月度通报，本条目为第 43 项） +https://www.cnnvd.org.cn/frontend/warnDetail?id=771a0f919a3d44c1ae6f68801cec9653 + +PoC 仓库与撰写文（机制描述的来源） +https://github.com/G4sp4rCS/CVE-2026-42980-POC +https://github.com/G4sp4rCS/CVE-2026-42980-POC/blob/main/writeup-en.md + +CISA 已知被利用漏洞目录（本条不在其中，目录版本 2026.09.18） +https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json + +六月补丁日汇总（本批 206 条，提权类 65 条） +https://threatprotect.qualys.com/2026/06/09/microsoft-patch-tuesday-june-2026-security-update-review/ + +同日的另一篇分析（称撰写时尚无公开利用代码；指出 WMI 归属未获厂商确认） +https://darkwebinformer.com/counting-below-zero-integer-underflow-to-system-in-the-windows-nt-kernel-cve-2026-42980/ + +出现错误修复版本号的那篇报道（正文写 10.0.26100.1992，摘要表为正确值） +https://securityonline.info/cve-2026-42980-privilege-escalation + +用户提供的素材（联合供稿，同一段文字在多个域名重复出现） +https://cybersecuritynews.com/poc-windows-nt-os-kernel/ +``` + + +**END** + + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/zNsFJyIuL0EGfTYZ8QWky55wEdvia6AURxepMvh56humc7mlIibwu2ykejUkIYTnK7W3fvkmgC4w07Wic0rWzLksI7ic8CaL75KSnmmic6oWzgEw/640?wx_fmt=jpeg&from=appmsg "") + + +公众号内容都来自国外等平台- 搜索的内容通过结合编写 -  + + 提供整洁 - 广告已关 + +公众号 |  +AnQuan7 (Ots安全) + diff --git a/doc/2026-09/【AI安全】40个Agent∕MCP漏洞归成13类后，扫描器为何仍只能找候选.md b/doc/2026-09/【AI安全】40个Agent∕MCP漏洞归成13类后，扫描器为何仍只能找候选.md new file mode 100644 index 00000000..3111f4e8 --- /dev/null +++ b/doc/2026-09/【AI安全】40个Agent∕MCP漏洞归成13类后，扫描器为何仍只能找候选.md @@ -0,0 +1,74 @@ +# 【AI安全】40个Agent/MCP漏洞归成13类后，扫描器为何仍只能找候选 +原创 Oxo Security + Oxo Security Oxo Security 2026-09-18 16:19 + +# 一、从40个披露到13个签名，重复失效比单个漏洞更值得警惕 🧩 +##### AI 时代！人人都在深耕 AI 安全，你缺的就是这关键一步！ + +AI 正重塑安全边界，与其在门外徘徊，不如直接掌握主动权！ +###### 免费课程持续更新 + +https://space.bilibili.com/452583051/lists/7870008?type=season + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/RBozUQPW9c9uzmFRqtCIwuQZzWHXcLVTmoTfLpES3uxw9DESYkLhm5xOCiaXLNAr5BoudicDsXRdhGCd8T6Sib5VQ/640?wx_fmt=png&from=appmsg "") + +agent-security-explore 在 2026 年 9 月 6 日公开固定版本研究材料，把 40 个负责任披露中的 Agent/MCP 漏洞归纳成 **13 类失效模式** +。这些模式包括护栏可被配置工具关闭、名单绕过、可控的收容锚点、默认放行、无鉴权网络暴露、浏览器打开对端 URL，以及白名单命令本身成为出口。🔎 **项目的价值不在又列一张漏洞清单，而在证明相同工程错误会跨多个实现重复出现。** + +Oxo Security 的判断是：**Agent 安全的主要缺口常在模型调用之前和之后，模型本身反而不是唯一变量。** +⚠️ 一个 MCP server 如果默认监听宽地址、没有 Origin/Host 校验、能执行未固定版本包，或把“安全目录”交给模型填写，那么再强的提示词防护也无法修复基础设施边界。 + +![](https://mmbiz.qpic.cn/mmbiz_png/Y05UtykogHT15NmlVOwGy54NlfCwiaRoSiah6Rmeavor3XGrs9dmORlWiaKoR2qk7PKr4icIyAunicOfptW1EW7VWYfFQ7l7v8ZOsIvumA5hMFoI/640?wx_fmt=png&from=appmsg "") +
研究层次
项目公开证据
应怎样使用
漏洞归纳
40 个确认发现、13 类签名
建立审计假设和回归用例
静态扫描
high 置信规则精度约 7%
只生成候选，必须人工确认
运行时实验
16 次链路中 5 次完整外传
验证组合失效而非单点命中
分发测量
19.5% 配置执行未钉版包
优先检查供应链准入
远程面
52% 远程 server 无认证
不把可达性当身份验证
+这些比例来自项目选择的公开样本和测量口径，尚未经过独立复现，也不能代表整个 MCP 生态。📌 **可行动的结论是把数字当作排查优先级，而不是当作行业发生率。** +企业应在自己的 server、客户端、配置仓库和网络暴露面上重新测量。 +# 二、五层边界没有接上时，批准按钮只是视觉安慰 🚧 + +一条真实链路通常跨过包分发、本地启动、工具描述、审批和网络出口五层。未钉版本的 npx/uvx 配置先在机器上拉取并执行包；server 再以 localhost 或远程接口暴露工具；工具描述和内容进入 Agent 上下文；用户批准时看到的摘要可能没有绑定真实参数；最后危险工具把数据发往外部。🔗 **每一层都只验证自己看到的局部信息，组合起来却没有任何一层对最终副作用负责。** + +项目使用 127.0.0.1 接收端、canary 回传、真实 Agent 驱动和三侧日志裁判，在 16 次端到端运行中确认 5 次完整外泄。🧪 这类判定比“模型输出了敏感字符串”更严格：只有 canary 到达接收端才算链路打通。 + +防守顺序应沿链路反向设置： +- 📦 分发层要求发布者、哈希和依赖版本固定，禁止首次运行静默下载； + +- 🖥️ 启动层明确展示 server 命令、工作目录、环境变量与网络监听； + +- 🧾 描述层把工具元数据视为不可信供应链输入，保存来源指纹； + +- ![](https://mmbiz.qpic.cn/sz_mmbiz_png/Y05UtykogHRDrOkteo6Jzc8175rr00wk1J4GpoekMvLM0UQwUSVSCR7twBTIGAiaR0lCUFcgqYXHm1QoRCMZw3H0MV1VMeaVAnx947KcHqYg/640?wx_fmt=png&from=appmsg "") + +✅ 审批层绑定最终工具名、完整参数、目标资源和会话状态； + +- 🌐 出口层对私网、云元数据和未知域名默认拒绝并记录； + +- 🪪 远程 server 使用独立身份与短期凭证，而不是只判断“能连通”。 + +**批准必须是对即将发生的具体动作签名，不能是对一个模糊意图点头。** +🔐 参数在批准后被重写、重定向跟随到新主机、或工具内部展开第二次调用，都应使原批准失效。 +# 三、7%的高置信精度，为什么反而是一条诚实的工具边界 📏 + +**🎯【7%的高置信精度，为什么反而是一条诚实的工具边界 📏】** + +这一节真正关键的不是「7%的高置信精度，为什么反而是一条诚实的工具边界 📏」这个概念本身，而是它背后的判断路径、执行边界和可复用方法。 + +它怎样落到真实安全团队的工作流里？哪些细节会直接影响 AI 代理的可靠性？ + +加入 Oxo AI Security 知识星球 +，可查看本节完整内容，系统掌握「7%的高置信精度，为什么反而是一条诚实的工具边界 📏」的完整拆解与实战用法。 + +📚 **AI 文献解读：最前沿的 LLM 安全论文深度剖析。** + +🐛 **AI 漏洞情报：第一时间掌握主流大模型的 0-day 漏洞与越狱方式。** + +🛡 **AI 安全体系：从红队攻击到蓝队防御的全方位知识图谱。** + +🛠 **AI 攻防工具：红队专属的自动化测试与扫描工具箱。** + +🚀立即加入 **Oxo AI Security 知识星球** +，掌握 AI 安全攻防核心能力！ + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/RBozUQPW9c86l9BKV2TcgrjKw8B41ge3ibibq5qqLoNW0aJYvEfAAibSfRgU74vleMaXJ2chff1d7sk5B7xHcI6iaA/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/RBozUQPW9c86l9BKV2TcgrjKw8B41ge30c1ib8vQunnAo8BIkojRnd5y8VoLeTxpl6czmSXAI91OxicJEaAibrGgA/640?wx_fmt=jpeg&from=appmsg "") + + diff --git a/doc/2026-09/【安全圈】攻击者利用 Issabel Framework 漏洞实现未经身份验证的 OS 命令执行.md b/doc/2026-09/【安全圈】攻击者利用 Issabel Framework 漏洞实现未经身份验证的 OS 命令执行.md new file mode 100644 index 00000000..2ae40612 --- /dev/null +++ b/doc/2026-09/【安全圈】攻击者利用 Issabel Framework 漏洞实现未经身份验证的 OS 命令执行.md @@ -0,0 +1,88 @@ +# 【安全圈】攻击者利用 Issabel Framework 漏洞实现未经身份验证的 OS 命令执行 + 安全圈 2026-09-19 11:00 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/aBHpjnrGylgOvEXHviaXu1fO2nLov9bZ055v7s8F6w1DD1I0bx2h3zaOx0Mibd5CngBwwj2nTeEbupw7xpBsx27Q/640?wx_fmt=other&from=appmsg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + + +**关键词** + + + +漏洞 + + +![](https://mmbiz.qpic.cn/mmbiz_png/sbq02iadgfyHddVbLDb4ewrHVough8wQGAZsovrnU2rwdqs8nZNlwgOKXl7QEVDFXFibxX87yXzRicv8qZAnaLfIzBh7MiaOEpIk5UnAFjAaialA/640?wx_fmt=png&from=appmsg "") + +开源统一通信 PBX 软件的 Web 框架 Issabel Framework 中的一个严重安全漏洞已遭到积极利用。 + + +该漏洞为 CVE-2026-89026（CVSS v3.1 评分：9.8 / CVSS v4.0 评分：9.3），可允许未经身份验证的远程攻击者利用一个硬编码的 JSON Web Token (JWT) 签名密钥执行任意操作系统 (OS) 命令。 + + +"Issabel Framework 在 pbxapi index.php 文件中包含一个硬编码的 HS256 JWT 签名密钥，该密钥在所有安装实例中完全相同，允许未经身份验证的远程攻击者伪造有效的 bearer 令牌，"VulnCheck 在一份警报中表示。 + + +"攻击者可以使用伪造的令牌调用管理器 '/ pbxapi / manager / originate' 端点并附带 System 应用参数，导致 Asterisk 以 Asterisk 用户身份执行任意 OS 命令。" + + +该漏洞的补丁于 2026 年 8 月 1 日推送，通过将硬编码的 JWT 密钥（"da893kasdfam43k29akdkfaFFlsdfhj23rasdf"）替换为存储在 "/ etc / issabel.conf" 文件中的 JWT 密钥来修复该缺陷。 + + +据这家网络安全公司称，Shadowserver Foundation 于 2026 年 9 月 9 日首次观察到对 CVE-2026-89026 的利用。不过，目前尚无关于该漏洞在现实攻击中如何被滥用、攻击者是谁以及此类行动规模等方面的细节。 + + +建议 Issabel Framework 用户应用最新修复程序以获得最佳保护。 + + +   END   + + +阅读推荐 + + + + +[【安全圈】程序员炸锅！智谱 ZCode 被曝静默打包工作区与 Git 历史直传云端](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079007&idx=1&sn=e3ef54109cd4fbca8f3ac931c56cc95c&scene=21#wechat_redirect) + + + +[【安全圈】AI 控机还杀不死！新型安卓木马曝光：卸载仍常驻 Shell](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079007&idx=2&sn=1de45fa1e0c91b7f0ce3601436604bef&scene=21#wechat_redirect) + + + +[【安全圈】AI 智能体打穿沙箱！Docker 曝 9.4 分逃逸漏洞：穿透虚拟机读写宿主](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079007&idx=3&sn=f573fda0930936118a001a7d0985e466&scene=21#wechat_redirect) + + + +[【安全圈】防火墙中枢被击穿！Check Point 曝 9.8 分漏洞：超长用户名直接拿 Root](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652079007&idx=4&sn=ee03a1d00069903ffa5e2b89cb3178f0&scene=21#wechat_redirect) + + + + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEft6M27yliapIdNjlcdMaZ4UR4XxnQprGlCg8NH2Hz5Oib5aPIOiaqUicDQ/640?wx_fmt=gif "") + + + +![](https://mmbiz.qpic.cn/mmbiz_png/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEDQIyPYpjfp0XDaaKjeaU6YdFae1iagIvFmFb4djeiahnUy2jBnxkMbaw/640?wx_fmt=png "") + +**安全圈** + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCEft6M27yliapIdNjlcdMaZ4UR4XxnQprGlCg8NH2Hz5Oib5aPIOiaqUicDQ/640?wx_fmt=gif "") + + +←扫码关注我们 + +**网罗圈内热点 专注网络安全** + +**实时资讯一手掌握！** + + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCE3vpzhuku5s1qibibQjHnY68iciaIGB4zYw1Zbl05GQ3H4hadeLdBpQ9wEA/640?wx_fmt=gif "") + +**好看你就分享 有用就点个赞** + +**支持「****安全圈」就点个三连吧！** + +![](https://mmbiz.qpic.cn/mmbiz_gif/aBHpjnrGylgeVsVlL5y1RPJfUdozNyCE3vpzhuku5s1qibibQjHnY68iciaIGB4zYw1Zbl05GQ3H4hadeLdBpQ9wEA/640?wx_fmt=gif "") + + diff --git a/doc/2026-09/千万别忽视！这个逻辑漏洞可绕过管理员的审核.md b/doc/2026-09/千万别忽视！这个逻辑漏洞可绕过管理员的审核.md new file mode 100644 index 00000000..32847136 --- /dev/null +++ b/doc/2026-09/千万别忽视！这个逻辑漏洞可绕过管理员的审核.md @@ -0,0 +1,79 @@ +# 千万别忽视！这个逻辑漏洞可绕过管理员的审核 + 三垣网安 2026-09-19 09:17 + +**前言** + +![](https://mmbiz.qpic.cn/mmbiz_png/SxoDJcKqQGJiciaVZSxrtNVZdar4DibJhYibHSJOnEpcib9A9hnwIOkeTyNFP6L56L98Vzmic7IlNPoQ4e5FibBfDtumupF4xLjhCrqUEibwD17Emos/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/SxoDJcKqQGJ7GJIBsr9BmXicTJ4bWN8pQMVCfSzQujbYDhNN1ichoYJXPQckkCxz93TmnJfic6bYU5mPBGibz0o8iaG8bJhrIqItT1d0nVrHb1H4/640?wx_fmt=png&from=appmsg "") + + +在 Web 安全中，SQL 注入、XSS 这类漏洞特征明显，很容易被扫描器捕获；但逻辑类水平越权漏洞却十分隐蔽，扫描工具往往很难发现。 + +很多业务系统把权限校验放在前端页面做限制，后端接口直接信任前端传过来的 ID 参数，不去校验操作人和数据归属关系。只要抓包修改请求里的业务 ID，就能越权访问、操作其他用户的数据。 + +本次测试的是某高校档案一站式服务利用大厅，在校史馆预约模块，挖到一处典型水平越权漏洞，普通登录用户可以篡改参数，撤销其他用户提交的校史馆预约记录。下面完整记录整个发现与复现过程。 + + +**漏洞介绍** + +![](https://mmbiz.qpic.cn/mmbiz_png/SxoDJcKqQGIOQGLQzxIJZARuUzqqwGLwWZahfTcJibEDTiadkXQfo6mOD5edO8mXl9xiatLmYY4ofQte6WQJdThvs4e2LQV3KoPHGFzFEDYhEY/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/SxoDJcKqQGI6DqFyY3qxiap3JX5vN5ibyicib6boQWTT7Ofwomqg3vp8LB1kNvyBlE4bWsqxf9yyeKDmotgTgBqG6VBj3f7U4lYYNYcibULQ6jzo/640?wx_fmt=png&from=appmsg "") + +- 漏洞类型：逻辑业务漏洞 + +- 漏洞位置：校史馆预约模块撤销预约接口 + +- 漏洞危害：可以直接绕过管理员审核，直接撤销预约 + +- 漏洞核心成因：后端接口未校验当前登录用户与目标预约记录所属用户的归属关系，直接接收前端传入的预约 ID 参数并执行撤销操作，导致权限绕过 + +**漏洞测试思路** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/SxoDJcKqQGJRnGHPJQkTRK8jkpJX4yJjmf7uSXDKMuAEE5Z7ampyHpSzKEwe6aF4aDbjM6PF0lsgPC4QtIL3TkS39mXicbfcvLCptq0txuEg/640?wx_fmt=png&from=appmsg "") + +![](https://mmbiz.qpic.cn/mmbiz_png/SxoDJcKqQGJfcZ63eTyPKscUfS01eKiaUdvR5RtEPJQUtagFYxr9rCCBciblQM2gBjzeHicwTJRicibQ2LCYBGwqiaGlP0mcTOn3c71eiaKSuTHS5Y/640?wx_fmt=png&from=appmsg "") + + +1. 漏洞url: + +https://xxx.com/8080 + +通过一些手拿到其账号密码登录后进入，档案一站式服务利用大厅 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/SxoDJcKqQGJ7NHL3TpGOF57p8uQC2XJLKW4J86DIofvRMEQLvxMroK7ubmR7rzqRXpFNcd9Sshe3t5bB5Khm6xd2lhRYej1MiaxA2yibSFI2A/640?wx_fmt=jpeg&from=appmsg "") + + +2.点击预约 + +![](https://mmbiz.qpic.cn/mmbiz_jpg/SxoDJcKqQGLEY0BTo5ChdVBBbSLhFjsj08pGamgmK6tT7p9q9MSdnkuCBxialThg0xboUTRuxDfamfqvA6XwIX8rDlkKk1s5rGshaRFuMibKs/640?wx_fmt=jpeg&from=appmsg "") + +3.随意填写就行 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/SxoDJcKqQGKU3S6vJYU663vn3kibyhTZk5iaiac4PFPoNZRPTlEfiaqD8ErJq0EUibzMMjk1rs1u5IjR9hJT7I4ZHGFXXMLlH5beibecDsOsp3veo/640?wx_fmt=jpeg&from=appmsg "") + +4.在撤销预约的时候抓包，修改放回包中的 + +status:-1  + +改成status:1 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/SxoDJcKqQGKbwdCUgcBpUJHCpUCib7kCHqOdI7uYptCu5tTbEXg4ia3NunsiaflZib7mt37NVZuzOtiaMpUauRT58IeDicRWsBE57Uv8s1qlGdhrM/640?wx_fmt=jpeg&from=appmsg "") + +5.可以直接绕过管理员审核，直接取消预约 + +![](https://mmbiz.qpic.cn/sz_mmbiz_jpg/SxoDJcKqQGJicjvPiavv0iajsJo1VynsHVWzibkeHVB0bnNJFVicaW1OFx58RyAPASK3a44BuSm0UIkzy2uTkIU2CxKITQZNxbK5mFA2NrOoFlGM/640?wx_fmt=jpeg&from=appmsg "") + + +**点击关注三垣网安,了解更多网安知识** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/SxoDJcKqQGLJKdg26y3ueVAhFeibU6SaMbTFaRUcOgF3uR5KIR1XMzvh4KS7TWHl12IgMq3wickdTMYaS6WRHWcKVic7WT3h1qicE9TCXJ0gjbo/640?wx_fmt=png&from=appmsg "") + + +[#越权]() + [#渗透测试]() + [#实战案例]() + + + diff --git a/doc/2026-09/工具分享 一款若依（Ruoyi-Vue）漏洞检测工具 (2)..md b/doc/2026-09/工具分享 一款若依（Ruoyi-Vue）漏洞检测工具 (2)..md new file mode 100644 index 00000000..fe4d0233 --- /dev/null +++ b/doc/2026-09/工具分享 一款若依（Ruoyi-Vue）漏洞检测工具 (2)..md @@ -0,0 +1,98 @@ +# 工具分享 | 一款若依（Ruoyi-Vue）漏洞检测工具 +点击关注👉 + 点击关注👉 马哥网络安全 2026-09-19 09:00 + +## 0x01 工具介绍 + +一款 +若依Vue漏洞检测工具，支持自动化扫描若依(Ruoyi-Vue)系列系统的包括Swagger，Druid，文件读取，SQL注入，定时任务，任意密码修改，系统接口越权等多种安全漏洞，同时还可以对接口和敏感信息进行搜集。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Nuuibh3bDOw7T0h7wDxOVcnFicpeHjdZUQb9tQpmibPqicdVxicwZZib2YgsOgjHJb7jIeV0tKFWYQ8LhyLYpdEibR82EChs09EwfxH5FCrrHoSTuc/640?wx_fmt=png&from=appmsg&wxfrom=13&tp=wxpic&watermark=1#imgIndex=1 "") +## 0x02 工具功能 + +1、漏洞检测模块 +
功能
说明
Swagger检测
自动探测 /swagger-ui/index.html、/v2/api-docs、/v3/api-docs 等接口，识别是否存在Swagger文档泄露
Druid检测
检测 Druid 监控页面未授权访问，并支持常见弱口令爆破（admin/123456、druid/druid等）
文件读取
检测 /common/download/resource 等接口的路径穿越漏洞，可读取 /etc/passwd、windows/win.ini 等系统文件
SQL注入
针对若依系统的 dataScope 参数进行 SQL 注入检测
定时任务读取
检测 /monitor/job 定时任务接口的任意文件读取漏洞
任意密码修改
检测若依系统密码重置接口的漏洞
系统接口越权测试
自动测试 /system/user、/system/role、/system/config 等管理接口是否存在未授权访问
全面检测
一键执行以上所有检测项目
+2、辅助功能模块 +
功能
说明
获取JS接口
多线程爬取目标页面引用的所有 JS 文件，正则提取其中的 API 路径，支持 /prod-api、/dev-api、/monitor 等常见前缀
接口测试
对收集到的接口进行批量测试，支持 GET / POST / POST-JSON 三种请求方式，可自定义请求体
敏感信息搜集
基于已抓取的 JS 内容，检测密码明文、API密钥、JWT令牌、数据库连接字符串、Redis URL、云存储地址、GitHub令牌、内网IP、邮箱、手机号等敏感信息
自动提取Basedir
输入完整 URL 时自动识别并填充后端 API 基础路径（如 /prod-api）
+3、核心特性 +- 多线程并发：10线程池并行请求，大幅提升扫描效率 + +- 代理支持：支持 HTTP 代理，便于使用 Burp Suite 等工具进行流量分析 + +- SSL忽略：内置 SSL 证书信任策略，支持扫描自签名 HTTPS 站点 + +- Cookie/Authorization：支持自定义认证头，可测试登录后的接口 + +- 彩色日志：终端风格彩色日志输出，关键漏洞高亮显示 + +- 实时进度：进度条 + 状态栏实时显示扫描进度 + +## 0x03 工具演示 + +1、设置目标URL，如 http://target.com + +2、HTTP代理：可选，格式如 http://127.0.0.1:8080 + +3、自动提取Basedir：勾选后自动识别后端API路径前缀 + +![](https://mmbiz.qpic.cn/mmbiz_png/Nuuibh3bDOw41jkAPmrwrMIlOooicZrBAyyXyibLgTXRal9CkEUa8yNoQNuoBxmLx5hhOwHs5lA9W7UPreLBzvuCJYCpRP6yibx8MeohhJK3z5w/640?wx_fmt=png&from=appmsg&tp=wxpic&wxfrom=5&wx_lazy=1&watermark=1#imgIndex=2 "") + +文章来源：无影安全实验室 + + +**** +![](https://mmbiz.qpic.cn/mmbiz_png/INa3lxHH4I2aV3zCmfiaj4cXeQ2HQd6s53wJS36HYI65ib48fujDK8najfWiahicsljzsdT3dfVS8HHyxaviaSd8g2g/640?wxfrom=5&wx_lazy=1&wx_fmt=png&wx_co=1 "") + + +**今日福利** + +为了帮助大家早日习得网络安全核心知识，快速入行网络安全圈，给大家整理了一套**【2026最新网安资料】** +网络安全工程师必备技能资料包（文末一键领取），内容有多详实丰富看下图！ + +Web安全 +👇 + +![](https://mmbiz.qpic.cn/mmbiz_png/UkV8WB2qYAkcvc41LgmeFn1B18QpgBZFBODrmsTGnPTOibdIT9B5eFLTHVIgWzYafxGAesmYnfzrz52xwV3Bjhw/640?wx_fmt=other&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + +渗透测试 +👇 + +![](https://mmbiz.qpic.cn/mmbiz_png/UkV8WB2qYAkcvc41LgmeFn1B18QpgBZFVKWl2cLRTq7x9haKJerUZNO0YMhiaO8ibN1jjV0qxNLEvRKMfR90eNjQ/640?wx_fmt=other&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + +安全面试题 +👇 + +![](https://mmbiz.qpic.cn/mmbiz_png/UkV8WB2qYAkcvc41LgmeFn1B18QpgBZFgrmaDLaYT1yV5lst9tKC72QrYjd5I8IN7kcOZIZSfQJJz8MdX6a1uA/640?wx_fmt=other&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + +代码审计 +👇 + +![](https://mmbiz.qpic.cn/mmbiz_png/UkV8WB2qYAkcvc41LgmeFn1B18QpgBZFxmUkTNP1iagssZL5zkjID8hibpZsRCj1OnEb4x7ZYWqpiaymSjc8O7vSQ/640?wx_fmt=other&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + +红队笔记 +👇 + +![](https://mmbiz.qpic.cn/mmbiz_png/UkV8WB2qYAkcvc41LgmeFn1B18QpgBZFVZS1mB4MKAo4FoMBGyVSzq38ZXEKJCjZVaTsFtLE7tIJ3zbRWF5xeA/640?wx_fmt=other&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + +入门视频👇 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/O9D0kmTL9EgxtiaXGtk7loXV41e8AXiaORJMhqFbrtcfHvJWTia6ME2oSI9msVYJu79uCicb7foufuibEHaVg32XnWw/640?wx_fmt=other&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1 "") + +![](https://mmbiz.qpic.cn/mmbiz_gif/NUwbCdTuQQxsJibSZGyA8akP9TVyJfPcpJ4uIZJDj3akRUfv6cNbnksGJQsibq1aH8iaGDic7TvOaSwNGXLdQ8PC9A/640?wx_fmt=gif&wxfrom=5&wx_lazy=1&tp=webp "") + + +以上所有资料获取请扫码 + +![](https://mmbiz.qpic.cn/mmbiz_png/2I159AwKj56GWlFpAuJBpDq9xgZp8de9R91BMgAgGaf5D4gwsyWl1FR9RN64BiaJqzxqDicCAgoKtwb9LPrZm4c15qTds6Ux29Cda2avFL0mY/640?wx_fmt=png&from=appmsg "") + +识别上方二维码 + +备注： +**2026安全合集** + +100%免费领取 + +（是扫码领取，不是在公众号后台回复，别看错了哦） + + + diff --git a/doc/2026-09/紧急安全预警｜CUPS曝本地提权漏洞，lpadmin低权限用户可获取Root权限.md b/doc/2026-09/紧急安全预警｜CUPS曝本地提权漏洞，lpadmin低权限用户可获取Root权限.md new file mode 100644 index 00000000..0670e924 --- /dev/null +++ b/doc/2026-09/紧急安全预警｜CUPS曝本地提权漏洞，lpadmin低权限用户可获取Root权限.md @@ -0,0 +1,213 @@ +# 紧急安全预警｜CUPS曝本地提权漏洞，lpadmin低权限用户可获取Root权限 +tuto + tuto 杂杂咱谈 2026-09-19 02:59 + +## 一、概述 + +cups2root是针对LinuxCUPS的本地提权PoC。该利用链将多个CUPS配置与权限边界问题串联起来，使已经属于lpadmin用户组的本地低权限用户，最终获得Root交互式Shell。 + +公开资料显示，该PoC由V12 Security研究人员发布，目前尚未看到对应的CVE编号或官方修复公告。PoC已在Ubuntu 26.04 LTS的AMD64和ARM64环境进行测试。 + +核心攻击链可以概括为： +``` +lpadmin低权限用户 +        ↓ +CUPS Serial Backend +        ↓ +篡改 cups-files.conf +        ↓ +构造恶意配置 +        ↓ +触发 CUPS 崩溃 +        ↓ +systemd 自动重启 CUPS +        ↓ +控制 ServerBin 目录 +        ↓ +替换 cups-exec +        ↓ +CUPS以Root权限执行 +        ↓ +Root Shell +``` +## 二、漏洞利用条件 + +攻击者需要满足以下条件： +- 已经拥有目标 Linux 系统上的本地账户； + +- 账户属于 lpadmin + 用户组； + +- 主组不能是 lpadmin +、root + 或 CUPS 配置中的 SystemGroup +； + +- 系统使用  +systemd； + +- CUPS 本地服务处于运行状态； + +- 系统启用了 CUPS Serial Backend； + +- 存在 PoC 所依赖的标准 Ubuntu CUPS 路径。 + +PoC不需要额外安装第三方Python依赖，运行方式为： +``` +python3 cups2root.py +``` + +成功后会直接打开交互式Root Shell，退出Shell后PoC会尝试清理临时文件、队列以及其他攻击过程中产生的本地痕迹。 +## 三、漏洞利用原理 +### 1. 利用 Serial Backend 修改 CUPS 配置 + +PoC首先创建一个RAW Serial Printer，并将打印设备URI指向 +： +``` +/etc/cups/cups-files.conf +``` + +由于相关Serial Backend以Root权限运行，攻击者可以利用打印数据覆盖该配置文件。 + +随后PoC修改多个关键CUPS路径，包括： +``` +Group +RequestRoot +ServerRoot +TempDir +ServerBin +``` + +其中尤其重要的是： +``` +ServerBin → /etc/cups/interfaces +``` + +这使后续CUPS执行程序的搜索路径被重定向到攻击者能够控制的位置。 +### 2. 触发 CUPS 崩溃并让 systemd 自动重启 + +完成配置篡改后，PoC发送一个构造异常的IPP Subscription请求，使CUPS守护进程发生崩溃。 + +由于CUPS由systemd管理，服务发生异常后会被自动重新启动。重新启动时CUPS会读取已经被修改的/etc/cups/cups-files.conf，于是攻击者之前设置的ServerBin等路径开始生效。 +### 3. 控制 ServerBin 并替换 cups-exec + +重启后的CUPS将/etc/cups/interfaces视为新的ServerBin目录。 + +由于该目录的权限已经被前面的配置修改影响，攻击者可以向其中写入恶意版本的cups-exec之后通过触发CGI请求，让CUPS调用这个替换后的cups-exec。 + +关键问题在于cups-exec此时由CUPS以Root权限执行，因此攻击者的恶意程序可以进一步创建一个 +setuid Root Shell +，从而完成本地权限提升。 +## 四、完整攻击链 +``` +本地 lpadmin 用户 +        ↓ +创建恶意 Serial Printer +        ↓ +Serial Backend以Root权限处理打印数据 +        ↓ +覆盖 /etc/cups/cups-files.conf +        ↓ +修改 ServerBin 等关键路径 +        ↓ + 发送恶意 IPP 请求 +        ↓ +    CUPS 崩溃 +        ↓ + systemd 自动重启 +        ↓ +ServerBin → /etc/cups/interfaces +        ↓ +写入恶意 cups-exec +        ↓  +     触发 CGI +        ↓ +cups-exec以Root执行 +        ↓ +创建Root权限Shell +        ↓ +   获得Root权限 +``` +## 五、AppArmor为何无法阻止 + +该利用链的一个值得注意的地方是: 它并不需要直接突破AppArmor沙箱。 + +PoC利用的是CUPS本身已经被允许执行的文件写入操作，将这些合法权限组合成了完整的提权链。 +``` +AppArmor允许的CUPS操作 +          ↓ +     配置文件写入 +          ↓ +       目录控制 +          ↓ +     程序路径重定向 +          ↓ +Root进程执行攻击者文件 +``` + +因此，单纯依赖Ubuntu默认AppArmor策略并不能阻止这条利用链。公开分析也指出，cups2root 的关键操作均落在现有CUPS AppArmor策略允许的范围内。 + +## 六、影响范围 + +目前公开PoC主要针对 +Ubuntu 26.04 LTS +，并支持： +- AMD64 + +- ARM64 + +需要特别注意的是，该问题属于本地权限提升，并不是"未认证远程攻击者直接获得Root"。 + +攻击者首先需要获得本地账户，并满足lpadmin组权限条件。 + +不过，对于存在： +``` +恶意软件 +Web Shell +被攻陷的普通账户 +不可信本地用户 +AI Agent / 自动化任务 +``` + +等场景的服务器，lpadmin → root的权限跃升可能进一步导致整台主机失陷。 +## 七、当前状态与缓解建议 + +目前公开信息显示，cups2root尚未对应公开CVE，也没有看到针对该利用链的官方补丁公告。 + +在官方修复发布前，可以考虑： +1. 严格限制lpadmin +组成员，仅允许可信管理员加入； + +1. 不需要打印功能的服务器可以考虑 +禁用CUPS； + +1. 不需要串口打印功能时，禁用Serial Backend； + +1. 限制CUPS服务的网络暴露范围； + +1. 持续关注OpenPrinting/CUPS官方安全公告； + +1. 对lpadmin +组成员以及近期CUPS配置变更进行审计。 + +另外，CUPS在2026年已经出现过多项安全问题，因此不建议仅针对cups2root单独进行防护，应结合当前CUPS版本和已公开漏洞统一进行升级与配置审计。 +### 八、总结 + +cups2root的核心并非单一漏洞，而是一条CUPS权限边界利用链： +> lpadmin + → 修改 CUPS 配置 → CUPS 重启 → 控制 ServerBin + → 替换 cups-exec + → Root Shell + + +其最大风险在于，攻击者只需要具备一定的本地打印管理权限，就可能进一步突破到Root权限。 + + +poc: +https://github.com/v12-security/pocs/tree/main/cups/cups2root + +[#Simple]() + [#cpus2root]() + [#LPE]() + + diff --git a/doc/2026-09/车联网漏洞挖掘方法及典型案例剖析.md b/doc/2026-09/车联网漏洞挖掘方法及典型案例剖析.md new file mode 100644 index 00000000..08dedf73 --- /dev/null +++ b/doc/2026-09/车联网漏洞挖掘方法及典型案例剖析.md @@ -0,0 +1,163 @@ +# 车联网漏洞挖掘方法及典型案例剖析 +GRCC + GRCC IoVSecurity 2026-09-19 00:00 + +![](https://mmbiz.qpic.cn/mmbiz_gif/CQb4KERYG3QA0ezCCjgRONQvXCf3wka7je04trwIyMqsDUWBubpwfiahXImiaoia7NnueGomOO28vicSZ5wEFFTa1Q/640?wx_fmt=gif "") + +点击上方 +蓝色字体 +，关注我们 + +**/** +**技术交流群****/** + +添加微信 +13918880149\**15021948198(好友已满），申请会员下载ppt & 加入网络信息安全、测试评价、汽车电子、自动驾驶、智能机器人、智能船舶、超级高铁、飞行器、招聘求职、投融资合作群...** + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibLsiaACia1wSrwS47tMOsRZAeyBibXWrpURdjLeiaKUAa6DjDBYqNyXsDlA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=1 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibo8ZBibCD77MgC90D3fcDT3KpEptib5ccMqtY0pJ7bBeIbOysW9ILsvwA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=2 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibhCQ4Ym9T5gSice0KwqVtOAy21ooNqVBzxyIs2uS9gdohb9N1IAP712A/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=3 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCib5fmK10wUsvPD2mtf89scvJ7EYkh0BmcoZPwX3Q6uMw7j6yx44PrFicg/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=4 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibVqS0aR7Dm20Kq2VxrdnVTo76nEzUMThv7o4cuU6Y0U0uQggWqciaib2Q/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=5 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibMjRuH3YXSxskMEsibPwBesQwaNQB2koLjuicRSMJCPZ5JCCu1b8qn9Ug/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=6 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibL5Q99bW4a1ic2arUXpJyCSbNf0UZudNndTplVO5Gicmib06wbZl7ANq3Q/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=7 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibgZgARj5tecMJGCpldbUnicIicGcu9ticFmpEy2LWCId7ibbYm5KAJc5mjw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=8 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCib0FNvOSHnPIC3djFV33rjInNPL17Tuwj6Via8VM8Ascc4bH4Tibml1ZxQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=9 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibRf5AibtHtvbKapk1icRR8lOdR10dDKmaWao2DxF6VExCwvIVoOjfIS7w/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=10 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibId27vju2m1Hy01IYfkL6iajXtP3MdhWpmu385PCEfvga485QiaxgvN1g/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=11 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibv8ZfDMsznJDnHErqGict4NDIBulUWbewMCZ7lD1blliaxNtIunLcyd2w/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=12 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibILbdC0czS9omKAic28rpuGwMib18UGKjfOIVs9iceSE9LmgtU1TqTYPog/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=13 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibN6wVv5YibEuHQZQMjksx9KHvnLNWXtHUJv9SyULprfiaTUtk5mgv1wwg/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=14 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibZqwajeOL6fEV6odKaAanqWGvfyjNdJCHpe4M1QyxWJpv2wHClEoHSA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=15 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCib2iblqSxibw8SW7ueTDY8JDgibJOPLiaib0h8yIp2fQ4MqZHtdXa64buuF1w/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=16 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibWx2ZMibMRJSicNXWDvDPXzBBxnDEpYUd2JNJXBs8DE71YtibkRoK7FyRw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=17 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibgdQjumt5CKiaBdTh3wey7vgLKtOicvwf8Ehwe7eJMHmGI1D0cIkr0RiaQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=18 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibW7Tm3t5w5QpXZ9jkIX7DXxzxPH5Qp2UKrzBk4lyL0vicia2b0Ol5xjkQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=19 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibI9T4yicIPk4M7zLVamqJcVzOLv0QX1f3eeyrND7CoN5ZHVTKcBRyqPw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=20 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibbsQibx7gwg4D1iaxBWeqJjkfhvQQuF6SN49sPk2EcWUDwBUTibQRRUyWw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=21 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibgxYAicQ0dVH9OC0Q2mD90lYcLwtMiacNo8elgEwjlWQzmGowk7u0icp3w/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=22 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCib9prqiaPExv5IrcwkSgicdb87UTzf6fQ14yoX5az4b7nh0QQ7FR6hlTcA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=23 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCib1BcecMaE8btTqiaLibiawPOyD6ZqQaVE0JBtuicTGdYwh5sia8pbGnVCtLQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=24 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCib4GulocKLXdH176libTsR0yUMtK91Ub1tZs5hbmJo1gwddAST9Y0BssQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=25 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibuan6SUaBscFPZqoIAtVCiaG1l4x9unNhMpawZtt93nnDfG8dREaggGg/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=26 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibiaV1QWLsqbFpjiaUXaX0eFul0k5hlMVyo4vF4eOicaPzcI69Xr7Q8lWnw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=27 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCiba8RZic8HPHxtMUdibf5R3oNXCsOUcKVYsyU2jicz0xicO02iciblVEE0bWoA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=28 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibEupjPHfOEK4XsAhppdDTuyOMXFHFSywLaQbhkTxWZXuPTvZPV4qRQQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=29 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibZdURdICOTic3R6cubde5tM9xsIHpxzicl3Wicdhic9dLENiaR5rpiaFRjg0w/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=30 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibKs1Y4XskkWWo04j7Z9f8InUbqvicn4ot6a4dxichWzLHfyI7xFFFHwFA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=31 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibGZpoY9cnXPhv0go7rRIOSeY4gCQ9PpQGxaa5qtvXDt4EMibyxictX0Xw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=32 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibfz1af3uuh8bHNmfgibWeaD4povc5L1pXvOFtanSiagQ3C7C5DMJlibPRQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=33 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibsUCibYHePeiaIfvgK6rl1C49wmfA2EEPbKeOzpp4N5mTTSuadNn6EJAw/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=34 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibzqwukdNYJRYqznmOkzMH1Phk6BKjTibyduNAJms9bL35LHjfnCH819A/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=35 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibHX9cMWkHIEtW9IsjF0tPTZy39aAv5pRz1y6QgDpkkmk5VnSVlhqNWg/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=36 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibCiaYp6uDWkcIia4zdbHIvadBWq40D43BP2hRkw4nvxh2UE8yCnBUzVqA/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=37 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibyuApxdRokYpmCf1MCDA01hweBSnkwFpicicvfEFTPGvMKRuc7HKETrbg/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=38 "") + +![](https://mmbiz.qpic.cn/mmbiz_png/uTSIm9RGwm2wz9XQFq7bibnouBibN48lCibw2ia2Spqkl3NAqtO9UwJ5HqW8UJ2POVysOPVZCDvGqC5bGsk6JzBXbQ/640?wx_fmt=png&from=appmsg&watermark=1#imgIndex=39 "") + + + +![](https://mmbiz.qpic.cn/mmbiz_gif/b96CibCt70iabwjyojLhA03PtxUnkNPREnt2F48ywfXLpDdDAjicOTPI8Q94tVLbJ58tbRs12iaXDKhUOW9gd4NlFA/640?wx_fmt=gif#imgIndex=40 "") + +相关文章 + +# 整车信息安全设计对车企的挑战与一汽奔腾的应对 +# 智能网联汽车安全测评的中国方案与实践 +# 国强标下智能网联汽车信息安全检测解决方案 +# + +![](https://mmbiz.qpic.cn/mmbiz_gif/MfTd6rd9CyvNRMW8I9cvI1CK5gKiaYqg2veTn9t9dAe1GxYic7pAvgvRIKNFickConFyX8AvW2reAq8GchJI6aBpA/640?wx_fmt=gif&wxfrom=5&wx_lazy=1&tp=webp "") + +![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNwzJ6g6cwDPWQPkMNSdxNzJNib6icvM2LNjWicc7Jdyzgduy5tKjYjt6ghKmiaHv6XEq28Et5pnOos5Y1icH8Wrx9SX03t7n1mmuE1g/640?wx_fmt=png&from=appmsg "") + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNx3XibDCcEHR7XYayO6ROlXoNkpaTZRl06QHfX1ncLMWf2RAUXM28XIrZIovlhoadFvJvBnZBQWfGeGrKAgZ9X42f3wA999JBZ0/640?wx_fmt=png&from=appmsg "") + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNwGy566FAz6qyctiblp3tMd0ECjDLU2WDiaI8BRricjYnobXF0KVMKf2W5aYoqYvcsCoZAyK4ibLWHL0W4KxgBsgGr0QvVHT8mUbPo/640?wx_fmt=png&from=appmsg "") + + + + +![](https://mmbiz.qpic.cn/mmbiz_png/WvsNkg6cHNw6GRHELmyd2YoMhpH3n5v6qnolI6zvBd4PSWZUPUmr44DRDwibgKUhKKg1WqGpcagazmWynTiaGYFnicViaPJNxgxkxNwfguIbcds/640?wx_fmt=png&from=appmsg "") + + + +![](https://mmbiz.qpic.cn/mmbiz_png/8Pvibnf7ic0cy77VtN8ibA7XuZgvGQoicjpar7CWkfIEXV4CEjiankS0tjDZEUgxhNHf0HicpBNcO4YuhOm5eIdb7RaA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp "") + + +![](https://mmbiz.qpic.cn/mmbiz_png/9yhibG49kQicogTWBZcB6XwgTib9lH6QN57pFdZwoRicFbc3JLM7icu8hadyzRKztBHGZ7eDEVgMiaHYqExfhbbpb5vA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp "") + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/WvsNkg6cHNwsY3icqHqQOHzicZXrxoUUHcvh0ZtHZwPx3s3kacK7fuyEYKqic3aCciccp0Ca67I6Gba6YVj7mDlq2trEBvkGToFkDOxYtRhG9cY/640?wx_fmt=png&from=appmsg "") + +扫描二维码**申请** +会员**下载ppt** + &  + +加入行业交流群 + +获取合作机会 + + +![](https://mmbiz.qpic.cn/mmbiz_png/kuhNyShuqyAGSIk680L6OHthYzkwuUDkKqfw3icohb1JLrEvjicKgfaiatIDP1L7RN7zPQkzbrksWzTMmgh5LKjzA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp "") + +![](https://mmbiz.qpic.cn/mmbiz_jpg/uTSIm9RGwm0ibSggKRaicPibLl2nXk3lGdgeoXo0P9Xy8e2aNHPm3LOhKjicHk2zhB5V1ar3CwUTs258UkiaTPYq4gw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp "") + +扫描二维码获取 + +更多精彩 + +![](https://mmbiz.qpic.cn/mmbiz_png/XiacM3aibSNia0qvdL1PUiaZugASarnXx5wAxT5ic13sgRB49E67AsdWeZpHnibUEW2oibToqEWRjHmImztgv33MaknnQ/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp "") + + +关注“**IoVSecurity** +” + + +![](https://mmbiz.qpic.cn/mmbiz_png/fBQwicMRtG3qyicHcTibNaG9RMs2E8knzWpfH0gnibzKsciaBTYdnW8mFyNgvEAqBNoib29iasxMgwh2gWRSIkINyHVLA/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp "") + +![](https://mmbiz.qpic.cn/mmbiz_png/D7nIuxbSmauhlzDVRGHTibAGyGcFvY5qFSPyZdMCxTSXwjhzFTotRe6rciaIxatoAHF0MPI73MMPAbf0UUMIMSvw/640?wx_fmt=other&wxfrom=5&wx_lazy=1&wx_co=1&tp=webp "") + +点个在看 +你最好看 + + + +