预言机被夺舍,代币价格被随意篡改,750 万美元被洗劫一空

要点总结
• 攻击者利用 MinimalForwarder 合约中缺失的权限校验,伪造签名执行关键函数
• 控制预言机 setPrices() 后,通过操控价格反复套利,跨链洗劫流动性池
• 权限校验缺失、调用路径未限制、签名机制薄弱是核心安全漏洞
• 此次事件暴露的是整体设计对“默认信任”的误判,而非单点 bug
• DeFi 项目中越模块化、越可组合,越需要对每一次调用身份严格验证
KiloEx 被盗的原因仅仅是因为一次权限校验的失守。
它只是忘了关一扇门,攻击者就被放了进来,把整个价格系统接管了。
让我们先来看看攻击是怎么发生的。
KiloEx 的永续合约架构中,价格由内部预言机合约 KiloPriceFeed
更新,理论上只有平台的 Keeper 模块能调用 setPrices()
。
但链上的权限路径是一条串联链条:
MinimalForwarder → PositionKeeper → Keeper → KiloPriceFeed
攻击者就是在最上游的 MinimalForwarder 找到了突破口。
简单地说,黑客只是「换上了员工服」,就从大门一路畅通无阻地走到了「价格控制室」,没有安保人员检查他的身份。
KiloEx 架构中的 MinimalForwarder
合约允许用户伪造签名,指定任意地址发起调用,但调用过程中并没有验证调用路径的真实性。
具体做法是,攻击者通过构造签名,逐层欺骗调用链,从 MinimalForwarder
一路走到 KiloPriceFeed
,最终控制了 setPrices()
函数,获得了修改预言机价格的权限。
从技术上说,它不是一个点的问题,而是一整套权限架构上的「默认信任」失效。
一旦拿到价格控制权,攻击方式就变得非常简单直接。
攻击者用篡改后的价格低位开仓,高位平仓,反复在 Base、opBNB、BNB Chain 等链上操作,将平台的资金池洗劫一空。
那么,KiloEx 的问题到底出在哪里呢?
根据 @SlowMist_Team 的分析,KiloEx 遭受攻击的根本原因在于其合约架构中的访问控制缺失,尤其是在 MinimalForwarder
合约中。攻击者利用该合约的漏洞,伪造签名并绕过权限验证,最终控制了预言机价格的更新。
具体问题如下:
- 调用链入口缺乏身份校验:
MinimalForwarder
合约的execute()
函数未对调用者的身份进行严格验证,允许攻击者伪造签名并指定任意地址发起调用。 - 目标函数权限控制不足:
预言机合约KiloPriceFeed
中的setPrices()
函数缺乏足够的访问控制,未能有效限制调用来源。 - 调用路径未设限:
攻击者能够通过构造特定的调用路径,逐层调用PositionKeeper
、Keeper
等合约,最终达到修改价格的目的,表明调用路径的深度与方向未被有效限制。 - 签名验证机制薄弱:
MinimalForwarder
合约在执行过程中未能有效验证签名的真实性和上下文,导致攻击者能够利用伪造的签名通过验证。 - 缺乏最终调用者的边界条件设定:
合约未设定「最终调用者必须为平台合约」的边界条件,使得非授权的外部地址也能成功调用关键函数。
这不是一个 bug,而是一种信任假设上的设计失败。
一条调用链越长、涉及的模块越多,就越需要在每一层都加上最基本的限制:
我是谁?
我从哪来?
我能做什么?
KiloEx 没有做这些检查,最终把最关键的价格控制权交到了黑客手中。
当前进展与官方回应
目前,KiloEx 官方已确认漏洞原因,并表示漏洞已定位,预计将很快修复,也已经暂停前端服务,并联合多个安全机构追踪攻击者资金流向。
但对于用户来说,真正重要的不是「修复」,而是明白一个事实:
合约安全,从来不是靠祈祷别人不去攻击,
而是从设计上就不允许任何人攻击。
权限控制,是最容易忽略的安全底线
权限控制本是智能合约中最基础、最明确的一项设计,
却也往往是最容易被忽视的。
当一个协议需要跨合约、跨模块协作时,
任何一处未验证的入口、任何一个默认放行的路径,
都可能成为整个系统被接管的起点。
KiloEx 被攻击的事件不只是对项目方的考验,
更是对所有智能合约开发者的一次公开考题:
- 你愿意为了开发效率,跳过那一层层显得「多余」的校验逻辑吗?
- 你真的知道,合约的每一次授权调用,背后是谁在发起、从哪跳转、又指向哪里吗?
你疏忽的每一行代码,都会有人认真研究。
你知道得越少,别人就越容易利用得更多。
这一次的学费,是 750 万美元。