跳到正文
阿里雲開發者社區 AI·· 3 小時前AI 評分63

五宗網絡安全事件分析指出跨環節風險檢查不足

Fnet 云网安 261102

AI 導讀

本期網絡安全熱點分析梳理五宗事件,指出各項控制分開檢查、未評估環節串連後的整體風險,是多宗事件的共同問題。事件包括 AI 研發平台入侵、遭篡改的 Claude Code 擴展、Ivanti 漏洞利用鏈、幣安資產遭轉出,以及 Drupal Commerce Core 授權缺失遭在野利用。文中建議企業把密鑰管理、發布者核驗、漏洞鏈修補及權限路徑納入整體安全檢查。

正文

001-公众号单封面AIGC-1-无标头.png

🛡️NSOC(网络·安全·云一体化运营中心)

7×24 主动监控与专家值守,网络可用性 99.99%,安全事件 百分百全 闭环,云资源一站式管理

今日热点 Top 5

S1 九家平台,同一排抽屉

核心内容

Wiz 十月发布报告《AI 研发平台的黑色十月》,统计十月份至少九起针对 AI 应用系统研发平台的入侵事件,涉及 Northflank、Railway、OpenCode、Warp 与 Lightning AI 等。

Northflank 是一家云应用托管平台,研发团队可在其上部署应用、容器、数据库与 AI 应用而无需管理底层设施。

该公司十月三十日披露事件:当天 11:43(协调世界时)收到 Wiz 的威胁告警,工程师一分钟后开始查看;
随后打了访问策略补丁,12:50 与 13:05 又各打一次,并请 Wiz 的事件响应团队介入。

通告要求客户「假定所有环境变量都已经被解密,禁用并轮换全部密钥」,随后确认有多家客户报告平台上存放的 AI 接口密钥被未授权使用,并建议客户核对各 AI 供应商的用量与账单。

作为处置,Northflank 为 PostgreSQL、MongoDB、MySQL 与 Redis 启用了凭据轮换,为全部客户(含免费账号)开启审计日志,并建议轮换存放在工作负载、密钥组与全局密钥里的凭据、关掉附加组件的公网访问。

公司未说明攻击者如何进入、影响多少客户、是否取走了 AI 接口密钥以外的凭据。

Wiz 称在其中两起事件里,失窃的企业凭据被用于发起约二百五十万次 Amazon Bedrock 调用,产生约十万美元的 AI 用量;
研究者还发现了转售模型访问权的基础设施,但未能把这些经营与初始入侵关联起来。

这类做法被称作 LLMJacking:用别人的凭据调用模型,账单落在别人头上,或者把访问权转卖出去。

Wiz 未确认九起事件出自同一批人,但其中多起都指向同一个目标——存放 AI 接口密钥的环境变量。

LLMJackingAI 平台环境变量密钥轮换Wiz

为什么重要

这批平台的共同点是替别人保管密钥。环境变量一旦被整批解密,泄漏的不是一家企业的密钥,而是它下面所有客户放在这里的那一排。

账单落在哪里,决定了多久能被发现。二百五十万次调用、十万美元,在一家正在扩大模型用量的公司里,不构成一个需要解释的异常。

平台是新柜子,锁是老锁。环境变量里的明文口令,与十几年前配置文件里的那一行,是同一种东西——只是现在的柜子里装的东西更贵。

九起挤在一个月里,说明这条路已经被人验证过、跑通过、可以重复。它不再是一次事故,而是一门生意。

报警来自平台之外。Northflank 是先收到 Wiz 的通知,才开始查自己的系统——自查没有先发现,这一条比入侵本身更值得记。

顾问金句

这一起要纠的不是某一家平台的防护水位,而是「放钥匙的地方」这件事的算法。

企业把模型接口的密钥交给了一个托管平台,等于把钥匙挂在了别人家的墙上,而墙被拆的时候,通知你的是隔壁的邻居。

建议企业做五件事。

首先,把 AI 接口密钥从「配置文件里的一行」升格为独立资产:谁发的、给谁用、能调哪个模型、月度上限多少、上次轮换是哪天,这五项要有台账。

其次,把用量当成一条安全指标来看:把各供应商的调用量与账单接入日常巡检,出现无法归因的调用峰值时,先按密钥泄漏处理,再按业务增长解释。

再者,把环境变量当成明文来对待:凡是以环境变量形式下发的凭据,都要能被一次性批量轮换,做不到这一点的平台不应该承接敏感密钥。

而后,把托管类供应商的告警接收路径写清楚:出事后谁通知你、你多久能收到、收到之后头一步做什么,这三问要有答案,而不是等一封公开通告。

另外,把「代管密钥」的第三方重新数一遍:凡是替企业保管凭据的平台,都要在供应商清单里单独标一栏,标明它能解开什么。

S2 ID 是对的,版本号是对的,发布的人不是

核心内容

十月二十九日太平洋时间凌晨两点二十七分到下午一点三十五分,约十一个小时里,Cursor 的编辑器扩展市场中出现了一份被篡改的 Anthropic Claude Code 扩展,版本号 2.1.313,至多五千名研发者在此期间安装。

Phorion 与 OpenSourceMalware 两家机构分析了样本:攻击者在扩展主脚本 extension.js 的开头插入了一段恶意 JavaScript 加载器,其余官方代码一字未动。

这段代码在扩展加载时即执行,不需要使用者打开对话框、不需要发起任何一次 AI 对话。

装载后的动作有四步:收集系统与用户信息,含用户名、主机名、公网地址、Git 提交邮箱,以及本机环境变量的名称;
向本机的 SSH 授权文件追加一枚攻击者控制的公钥,命名 svc-telemetry,并尝试开启 SSH 服务、建立反向隧道;
用 macOS 的 LaunchAgent 或 Windows 的计划任务与启动脚本做持久化,约每分钟重试一次隧道;
把主机信息与后门状态回传到地址 134.209.82.225。

Phorion 另有一个发现:恶意代码自己写错了。

macOS 上它用 systemsetup -getremotelogin 查看远程登录是否开启,但这条命令需要提权,实际返回的是管理员权限报错而不是状态;
代码只在输出含「Off」时才去开启,于是这一步被整段跳过。

Windows 上它想通过 PowerShell 安装并启动 OpenSSH 服务,却经 /bin/sh 去调用——标准 Windows 上没有这个壳,安装失败。

结果是:在没有预先开启 SSH 的机器上,隧道建不起来,但侦察数据照样外传,公钥照样被写进授权文件;
脚本本身不直接取走凭据,说明攻击者原打算在拿到通道之后手动去取。

Cursor 下架了该扩展,临时关停整个市场以审计其他扩展并轮换全部访问密钥,配合托管方关掉了攻击者的服务器;
公司称未发现其他版本或官方分发渠道受影响。

Cursor 表示 Anthropic 并未开发这个恶意扩展,但没有解释攻击者是如何用 Anthropic 的名义完成发布的。

供应链CursorClaude CodeSSH 后门扩展市场

为什么重要

来源校验靠的是标识与版本号,而这两样都对。真正没有被校验的那一项,是「这次发布是谁发起的」——它不在任何一个字段里。

执行不需要交互。信任的动作发生在点击安装的那一下,而不是打开工具的那一下;此后每一分钟的重试都在替对面续命。

五千台里有相当一部分没事,原因是恶意代码自己写错了,不是任何一层控制起了作用。这是运气,不是水位。

侦察清单里有「环境变量的名称」。它不取凭据,只记下钥匙挂在哪一格——这是为下一步挑门,而不是为这一步取货。

市场被整体关停十一个小时,这个动作本身说明了一件事:这些平台在被审计之前,说不清自己货架上还有没有别的。

顾问金句

这一起要纠的不是某一次市场被投毒,而是「我们怎么认定一个东西是官方的」这件事。

企业核了名称、核了标识、核了版本号,三项全对;
而这三项在攻击者手里,是三个可以被填上去的值,不是三道需要被通过的门。

建议企业做五件事。

首先,把编辑器与 AI 工具的扩展来源收成白名单:只允许从被审过的发布通道取包,其余一律不装,白名单之外的安装请求要有审批记录。

其次,把本机的授权文件纳入巡检:SSH 授权文件里出现来历不明的公钥,等同于有人在你的门上配了一把钥匙,这件事应该由巡检发现,而不是由事后复盘发现。

再者,把「加载即执行」当成一个通用的判断标准:任何在打开时就运行的组件,安装动作本身就是一次授权,不能按「装了不用就没事」来理解。

而后,把 AI 编码工具配置成只读可信目录、只允许访问被列明的工作区,减少一次加载能碰到的东西。

另外,把市场类供应商的应急能力问清楚:出事后能不能在半小时内下架、能不能给出受影响清单、能不能证明其他包没有被改——这三问答不上来的,不适合进入研发环境。

A3 补丁分三次发,链条只用一次

核心内容

美国网络安全和基础设施安全局十月三十日把两颗影响 Ivanti Connect Secure 的缺陷加入已知被利用缺陷目录,依据是在野利用已经确认。

头一颗是 CVE-2026-111357,厂商给出的评分是 8.8、官方漏洞库记录为 7.0,属于关键功能缺失认证,本地已认证的攻击者可借此提权到 root;
另一颗是 CVE-2026-118527,评分 4.3,属于可预测标识符生成,远程已认证的攻击者可以把内容由自己控制的文件写到磁盘上已知的位置。

这两颗与更早的认证绕过 CVE-2026-104935(8.6,十月十三日进入目录)构成同一条链,起初由 Volexity 在本月早些时候披露,实施方是此前未被记录的组织 UTA0576。

Volexity 的描述是:认证绕过、远程代码执行与权限提升三者串接,达成免认证的 root 级代码执行。

与常见手法明显不同的是,UTA0576 不落网页壳、不装恶意程序,行为集中在四件事:取走凭据与有限的活动目录元数据、做主机侦察、找管理员口令、找 BitLocker 恢复密钥。

Volexity 把利用时间追溯到至少十月三日,受害者中包括已经打满补丁的设备。

修复版本是 25.1.1.3(覆盖 25.1.1.2 及更早)与 22.8R2.6(覆盖 22.8R2.5 及更早),22.8 系列将在二〇二七年一月三十一日停止支持。

联邦民用机构对 111357 的处置期限是十一月二日,对 118527 是十一月十三日。

Ivanti 说明,发现利用时它已经为认证绕过那颗准备好了修复,并在质量验证阶段,为了不耽误客户堵住主要通道,选择先发那一颗;
权限提升那颗的一部分在公司自己的产品安全流程中被发现,已于七月的 25.1.3.0 版本修过,正在向其他受支持版本回移时被利用。

确认是否已经失陷,官方口径是需要流量与内存取证,原因是相关命令在内存里跑,设备自带的完整性检查器可能漏掉;
恢复步骤是备份配置、恢复出厂设置并升级(虚拟实例按重建处理)、恢复配置、重置全部账号口令、重签证书、重置存下来的接口密钥。

IvantiCISA KEV利用链UTA0576取证

为什么重要

一颗一颗地打,链还开着。只装上了十月十三日那颗的机构,等于把主要通道堵住,却把梯子留在了原地。

两个期限之间隔了十一天。十一月二日与十一月十三日之间,是留给对面的窗口,而不是留给自己的缓冲。

确认失陷要看内存,而多数团队的取证能力停在磁盘与日志层。设备自带的检查器可能漏,这句话本身就是一条行动指令。

对面不装后门,只取钥匙。管理员口令、BitLocker 恢复密钥、活动目录元数据——目标不是这一次的数据,是下一次还能进来。

恢复清单里有重签证书与重置接口密钥。这两条在多数企业的预案模板里根本没有位置,而它们决定了处置完还算不算处置完。

顾问金句

这一起要纠的不是「补丁打了没有」,而是「补丁是按颗算的,利用是按链算的」这件事。

厂商为了一颗一颗地不耽误客户,选择分次发布;
这个决定在工程上是合理的,在防守侧却制造了一个新的误判空间——打上了,不等于合上了。

建议企业做五件事。

首先,把边界设备上的修复从「按公告条目」改成「按利用链」:同一批里互为上下游的几颗,要么一次性全上,要么按未完成处理。

其次,把「确认是否失陷」写成处置的前置步骤而不是后续步骤:内存与流量两条取证路径要提前备好工具与权限,不能等出事再找谁会做。

再者,把恢复清单升级成模板:出厂重置、重建实例、改全部口令、重签证书、重置接口密钥,这五步要进预案,缺一步就不算闭环。

而后,把设备上存着的密钥数一遍:哪些口令、哪些恢复密钥、哪些接口凭据放在这台设备或它联到的账号能够到的地方,这一栏今天要被填上。

另外,把停止支持的时间写进日历:22.8 系列在二〇二七年一月三十一日到期,到期之后的同类缺陷不会再有补丁,替换计划要在到期前落地。

A4 一台笔记本,十条链,二十分钟

核心内容

币安十月三十日通报:十月二十九日晚间发生安全事件,涉及数字资产约六十三亿美元。

初步调查显示,一名负责开发运维的工程师的笔记本电脑被入侵,攻击者由此取得系统访问权,进入一个服务容器并提交了未经授权的提币交易;
后续调查发现还存在其他入侵点,完整路径仍在查明。

公司称未发现钱包私钥泄漏的证据,将在事实核实后发布详细技术复盘。

链上数据机构 TRM Labs 测算,攻击者在约二十分钟内,从涉及十条区块链的币安钱包转出约六十三点六亿美元;
若后续确认,这将成为有记录以来金额居首的数字资产盗窃案。

公司称已与区块链伙伴在链上冻结约三十亿美元,其中 Tether 冻结逾十五点六七亿 USDT、Circle 冻结逾八亿 USDC。

联合首席执行官 Richard Teng 对外表示,这不是一个人做的,攻击者使用了「自毁机制」,边走边销毁工具与痕迹,使追踪与调查更难。

赔付由用户安全资产基金与公司自有资金承担,公司称已划出逾六十三点四亿美元用于覆盖缺口,并暂停了充提业务。

美国联邦调查局十一月一日正式把此案归因于朝鲜的 TraderTraitor 组织,Chainalysis 称对此有高置信度判断;
美国特勤局表示正在全天候开展识别、冻结、追踪与追回。

消息传出当日,比特币一度跌破七万七千美元。

BinanceDevOps 终端供应链自毁机制FBI 归因

为什么重要

权限表上每个人都没有越界,路径上一步越了三层。一台工程师的笔记本、一个服务容器、一个提币接口——没有一处是「管理员权限」,连起来就是六十亿。

二十分钟、十条链。发现与处置的时间常数,和转移的时间常数已经不在同一个量级,速度差本身就是损失。

自毁机制把排查从「找证据」变成「找残留」。对面走的时候带走的不只是钱,还有说明它是怎么进来的那些东西。

能冻结三十亿,是另一个团队在另一套流程上的响应速度。兜底能力今天已经算安全能力的一部分,而不只是财务安排。

归因可以慢慢等,赔付不能。这条对任何一家企业都成立:先处理敞口,再讨论是谁。

顾问金句

这一起要纠的不是某一家交易所的防护,而是「权限」这件事被拆成了格子、而路径从来不走格子。

企业的权限表是按人、按角色、按系统画的,攻击者走的是按跳数算的一条线:一台终端、一个容器、一个接口。

建议企业做五件事。

首先,把高价值动作单独拎出来看:凡是能直接移动资金、直接改账、直接对外付款的接口,都要有一条独立于角色体系的复核要求,而不是靠「这个人不是管理员」来兜。

其次,把终端重新算进攻击面:负责运维与发布的机器,权限往往比它看上去大得多,它的失陷等价于一串凭据的失陷。

再者,把「几步能到」当成一种度量:从一台普通终端出发,到能动的那个接口要经过几次跳转、几次认证、几次审批,这个数字比权限数量更能说明问题。

而后,把清痕当成常态来假设:日志外送、异地留存、关键动作双份记录,这三条要做到对面删本地也删不掉。

另外,把兜底与冻结的流程提前演练:出事之后谁有权按下暂停、多久能按、按了之后业务怎么走,这三问在事前要有答案。

A5 检查写在了每一条路上,漏的是路本身

核心内容

Drupal 安全团队十月二十八日发布 SA-CONTRIB-2026-254,Commerce Core 模块存在授权缺失问题(CWE-862),未充分保护某些路由与实体字段,导致访问绕过,可被用于强制浏览,可能对商家造成资金层面的影响。

该团队给出的评级是二十一分(满分二十五),属高度危急,并明确说明该缺陷正在被在野利用,建议站点核对订单是否出现异常。

影响范围是 8.x-2.x 系列 2.41 之前的版本,与 3.0.0 至 3.3.12;
修复版本是 3.3.13 与 8.x-2.41,通告未列出可行的变通方案。

对应的 CVE-2026-118539 记录于十月三十日发布,美国网络安全和基础设施安全局的相关数据管道给出通用漏洞评分 6.5。

Drupal 说明这是 Commerce Core 模块的问题,不是 Drupal 核心的问题。

Commerce Core 的作用是让站点通过购物车、结账表单,或者以解耦方式通过接口售卖商品与服务——换句话说,凡是把订单、价格、库存与支付串在一起的地方,都在这条链上。

模块漏掉的是「某些路由与某些实体字段」的保护,而不是全部;
正因为它不是全部,逐条比对的人会在每一条被列出的路径上得到「正常」的结论。

DrupalCommerce CoreCVE-2026-118539授权缺失在野利用

为什么重要

授权是逐条路由写的,漏的是没有被列进去的那几条。检查表上每一条都通过,表本身不完整——这是很难被发现的一种失败。

后果直接落在钱上。订单状态可被改、折扣可被套、商品可被白拿,安全事件与财务报表在这里是同一件事。

评分 6.5 与「高度危急」并存。数字看起来不急,而它已经在被利用——评分反映的是单点严重度,不反映有没有人在敲门。

没有变通方案,只有升级。对还在跑旧分支的站点,这是一道必须在业务窗口内做完的题。

事后动作是核对订单,不是查日志。影响面要在业务数据里找,而不是在安全设备里找——这条对所有交易类系统都成立。

顾问金句

这一起要纠的不是某一个模块的代码质量,而是「我们凭什么相信这张检查表」这件事。

授权控制天然是枚举式的:写一条路由,加一条检查;
而缺陷恰恰长在没有被枚举到的那个缝隙里。

逐条复核的人不会错,错的是他手里的那张表。

建议企业做五件事。

首先,把交易类系统的授权复核从「按清单核对」改成「按对象盘点」:先把有哪些路由、哪些实体字段、哪些接口动作列全,再谈每一条该不该有检查。

其次,把「未列出」当成默认拒绝:凡是没被显式写进授权规则的路径,一律按不可访问处理,而不是按历史默认放行。

再者,把评分与在野状态分开看:评分低但在野利用确认的,优先级要高于评分高但无人问津的,这两列不能合成一个数字。

而后,把订单与账务的完整性核对做成例行动作:金额、状态、折扣、退款四条要有对账口径,异常能在业务侧被发现而不只是安全侧。

另外,把「无变通方案」这类通告单独标出来:只能升级的缺陷要提前排业务窗口,而不是等它变成紧急变更。

趋势分析

本周期五条热点分别是:九家 AI 研发平台在一个月内被侵入、一个用官方 ID 与正常版本号发布的恶意扩展、一条由三颗缺陷串起来的边界设备利用链、一次六十余亿美元的提币,以及一个授权检查漏了几条路由的电商模块。

它们的地域、行业、金额都不一样,结构却相同——每一处都做了该做的事,而每一处都没有人看过这些事连起来是什么样。

环境变量加密存了,没人算过整批解密之后敞口有多大;
扩展的 ID 与版本号都核了,没人核过这次发布是谁发起的;
十月十三日那颗补丁打了,没人核过链上还剩两颗;
每个账号的权限都在角色表内,没人核过从一台笔记本到提币接口要跳几步;
授权检查写在了每一条路由上,没人核过这张表本身缺不缺行。

​

來源:阿里雲開發者社區 AI · developer.aliyun.com