6.8 亿警示:DeFi 审计盲区与 ICON、aelf 攻击复盘

核心要点

ack3研究显示2026上半年多数DeFi损失源于审计范围外漏洞。结合ICON重放攻击与aelf运行时入侵案例,揭示“已审计”标签的安全局限及信任缺口。

据 Woofun AI 消息,去中心化金融领域长期存在的"已审计"安全背书幻觉正在被数据证伪,核心事实指向审计覆盖范围的结构性缺失。安全公司 ack3 联合布拉格捷克理工大学发布的预印本论文指出,在 2026 年上半年报告的 135 起安全事件中,总损失高达 9.3986 亿美元,其中 68 起拥有公开事前审计记录的事件里,绝大多数攻击路径完全游离于审计范围之外。

这一发现直接挑战了市场对于智能合约审计作为绝对安全防线的传统认知,表明局部代码审查无法为整个 DeFi 项目的系统安全性提供有效担保。

Woofun AI 整理数据显示,在这 68 起具备审计记录的事件样本中,攻击路径的分布呈现出极端的非对称性:46 条攻击路径被归类为完全不在任何可查审计范围内,仅 20 起事件至少部分落在审计覆盖区内,另有 2 起无法判定。从数量上看,审计范围外事件占比为 67.6%,但其对应的损失金额却占据了报告损失总额的 94.4%。

这种惊人的比例并非单纯反映审计失效,而是揭示了极端值对统计结果的巨大扭曲。具体而言,Kelp DAO 遭受的 2.92 亿美元损失与 Drift Protocol 遭受的 2.85 亿美元损失是主要变量。若剔除这两起特大事件,审计范围外攻击造成的损失占比虽仍高达 72.1%,但绝对金额从 6.8097 亿美元骤降至 1.0397 亿美元,而该组样本的总损失也从 7.2124 亿美元缩减至 1.4424 亿美元。通过公开的数据集 json 文件,研究者可以复现这一事件分类数量与损失金额的对应关系,证实了即便在已审计样本中,绝大部分资金风险依然暴露在审计盲区。

深入剖析该研究的方法论与局限性,其数据窗口严格限定在 2026 年 1 月 1 日至 6 月 29 日,涵盖 122 起确认攻击事件与 13 起疑似事件。值得注意的是,全部样本中有 35 起事件未找到审计记录,32 起审计历史未知,这两类共计 67 起事件并未纳入上述 68 起有审计记录的统计范围,这意味着研究仅聚焦于"有审计但依然出事"的子集。这份由两名隶属 ack3 的作者撰写的 6 页预印本论文,明确承认其缺乏未遭受攻击的对照组,且未统计各系统暴露风险的具体时长。

因此,研究无法证明经过审计的协议整体更安全,也无法估算事件发生概率,更不能证实"超出审计范围"是每一笔损失的直接诱因。部分未公开的审计和私人事故可能缺失,而已报告的损失数据也不完全具有可比性。基于此,研究仅能得出有限结论:审计记录和审计覆盖范围是两个独立指标。一份经过审查的智能合约,并不代表合约升级、特权密钥、前端、中继器、预言机、云服务或是应急响应流程,能获得同等安全保障。

8 月 27 日发生的 ICON Network 重放攻击案例,直观展示了审查边界处的失效样本。在该事件中,提现链路的两个模块对同一条消息的解读出现分歧:序列号的高位比特用于判断消息是否唯一,但加密签名仅覆盖序列号低 256 位。攻击者利用这一逻辑错配,通过修改未纳入签名校验的高位比特,在约 20 分钟内,将两条合法签名的提现消息重复提交 1492 次,其中 1490 次调用执行成功。本次重放攻击释放 1.19866 亿枚 ICX 以及 531600 枚 bnUSD。复盘发布时,ICON 确认净损失约 150.2 枚 ETH 外加 31204 枚 USDC。基金会称 531600 枚 bnUSD 和 136.6 万枚 SODA 资产已追回,用户存款、账户余额与头寸未受影响。

尽管 ICON 表示迁移合约已完成外部审计并落实建议,Sodax 开发文档审计列表中也包含 2025 年 11 月的 Sodax 中继审计报告,但复盘报告明确指出,唯一性校验逻辑与签名校验值之间的精确错配不在上述审计发现范围内。响应时间线同样暴露问题:ICON 第一条自动化告警在 UTC 时间 02:08 触发,距离攻击启动约 7 分钟;工作人员在 03:40 左右启动调查,03:53 暂停受影响合约,06:18:54 暂停整条网络。从首次告警到完整应急处置存在约 90 分钟间隔,ICON 归因于警报机制调整导致的误报,计划部署自动关停触发机制并开展专项复审。

另一个典型案例是 8 月发生的 aelf 运行时入侵事件,其凸显了审计脱节带来的不确定性。公开资料描述出现运行时入侵与可控恢复,但现有证据不足以判定攻击路径落在事前特定审计范围之内。项目官方公告说明,存在一份未授权智能合约,能够借助交易参数,将编码后的 .NET 程序集与指令注入节点执行链路。初步调查报告将事件归因于运行时反射与动态加载校验存在缺陷,同时合约执行环境和敏感节点、基础设施资源之间隔离不足。

aelf 一共识别 155 笔相关交易,5 个独立载荷程序集,载荷具备执行主机命令、尝试对外通信、访问节点密钥、基础设施侦察等能力。截至 9 月 11 日,该结论仍为阶段性判断,aelf 官网博客在 8 月 26 日后没有发布针对本次事件的专项更新,尽管 8 月 26 日公告承诺后续发布最终复盘。aelf 技术安全文档写明其区块链与 ELF 代币合约经过多轮审计,未发现安全问题,但现有公开页面无法将 8 月攻击对应的运行时路径与事发前某份审计报告对应起来。

这种不确定性表明,一份有时间戳的审计报告会逐渐和当前系统代码、依赖库、实际运维状态脱节,用户需要一份带版本的安全记录来体现差异,包括被审查仓库与代码提交版本、部署合约地址、被排除组件、特权角色、依赖库,以及审计完成后的合约升级、密钥托管与轮换机制、运行时隔离策略、告警和熔断机制。

重新定义审计信任与安全记录标准已成为行业迫切需求。一枚审计徽章无法回答被审查的组件、已部署的系统和应对故障的机制是否还处在同一个安全边界内。未来的安全实践必须让审计宣传和实际工作内容匹配,并关联当前正在运行的系统。这要求建立带时间戳的资产恢复状态记录,清晰区分确认损失、冻结资产与尚未解决的风险敞口。只有当审计范围明确涵盖合约升级、特权密钥管理、前端交互、中继器逻辑、预言机数据源、云服务配置以及应急响应流程时,"已审计"标签才能具备实质性的安全意义。否则,用户仍将面临巨大的信任缺口,因为现有的审计模式往往只审查静态代码片段,而忽略了动态运行环境中的复杂交互与潜在漏洞。这是继多次重大 DeFi 黑客事件后,行业对安全基础设施有效性的一次深刻反思,标志着从单纯依赖代码审计向全生命周期安全监控的范式转变。

评论

回复 @用户
0/800
老王看盘1小时前
感觉 DeFi 那些已审计的项目也有漏洞,心里还是有点没底,这数字看着真吓人。
显示 1-1 / 共 1

消息提醒

登录后查看消息
查看全部消息管理订阅