一次签名毁掉数亿美元，深度拆解DeFi历史级漏洞
在过去一年的 Web3 安全事件中，跨链桥仍然是最频繁的攻击目标之一。跨链桥的复杂性、权限模型以及消息验证机制，使其成为攻击者最青睐的突破口。本文以 Poly Network 跨链合约权限漏洞为核心案例，做一次专业级漏洞解析，从攻击逻辑、智能合约设计缺陷到代码级问题进行完整拆解。虽然该事件发生更早，但其漏洞模型在最近一年的多起跨链攻击中仍被反复复用，因此具有非常高的研究价值。
一、漏洞背景：跨链桥的核心信任假设
跨链桥的本质是一个 状态验证系统。当用户在链 A 锁定资产时，桥会在链 B 铸造映射资产。
整个过程依赖三个关键组件：
1️⃣ 锁仓合约(LockProxy)
2️⃣ 跨链消息验证(EthCrossChainManager)
3️⃣ 管理员/验证者权限控制
在 Poly Network 的设计中，EthCrossChainManager 负责验证跨链消息并调用目标合约。
简化流程如下：
User -> LockProxy -> CrossChainManager -> Target Contract
攻击者的核心目标就是：
👉 伪造跨链消息，让 CrossChainManager 执行任意合约调用
如果这个组件存在权限漏洞，那么攻击者就能直接控制资金池。
二、漏洞核心：跨链消息验证逻辑被绕过
漏洞发生在 EthCrossChainManager.sol 的 verifyHeaderAndExecuteTx() 函数。
简化代码如下：
function verifyHeaderAndExecuteTx(
bytes memory proof,
bytes memory rawHeader,
bytes memory headerProof,
bytes memory curRawHeader,
bytes memory headerSig
) public returns (bool) {
TxArgs memory args = _deserializeTxArgs(proof);
address toContract = args.toContract;
bytes memory callData = args.args;
(bool success,) = toContract.call(callData);
require(success, "call failed");
return true;
}
乍一看似乎没问题，但关键问题在于：
toContract 地址来自外部输入，并没有正确限制。
攻击者可以构造跨链消息，使 toContract 指向 任意合约地址。
🚨 这就意味着：
攻击者可以让跨链管理合约 调用任何函数。
例如：
toContract = LockProxy
callData = transferOwnership(attacker)
如果验证逻辑不严格，攻击者就能接管资产管理合约。
三、攻击步骤完整复盘
攻击者利用该漏洞执行了一个 三阶段攻击。
第一步：构造恶意跨链交易
攻击者伪造跨链消息，使CrossChainManager调用
EthCrossChainData.putCurEpochConPubKeyBytes()。
目标：
👉 替换验证节点公钥
一旦成功，攻击者就成为新的验证者。
攻击调用示例：
CrossChainManager.verifyHeaderAndExecuteTx(
malicious_proof,
...
)
第二步：接管跨链验证权限
攻击者更新验证者集合：
function putCurEpochConPubKeyBytes(bytes memory pubKeyList) public
新的 pubKeyList 包含攻击者控制的密钥。
此时：
跨链验证系统完全被攻击者控制。
第三步：转移资产池资金
攻击者随后伪造跨链交易，调用：
LockProxy.unlock(...)
伪造资产释放。
伪代码：
lockProxy.unlock(
toAssetHash,
attacker,
amount
);
攻击者重复调用多个链的资金池。
最终盗取资产约 6 亿美元。
四、漏洞本质：跨链消息执行权限过大
从安全架构角度看，这个漏洞本质是 跨链执行器的“任意调用”问题。
核心问题有三个：
1️⃣ 缺少目标合约白名单
安全设计应该是：
require(allowedContracts[toContract], "invalid target");
但原合约没有。
2️⃣ 调用数据未做函数级限制
攻击者可以调用任何函数。
安全模型应该是：
contract + method selector whitelist
3️⃣ 验证逻辑与执行逻辑耦合
验证和执行写在同一个函数中：
verify -> execute
这违反了安全设计原则。
正确设计应该是：
verify -> queue -> execute
并加入 timelock。
五、漏洞修复方案(专业视角)
安全团队通常会做三层防护。
1️⃣ 合约调用白名单
mapping(address => bool) public allowedContracts;
require(allowedContracts[toContract], "not allowed");
2️⃣ 函数选择器限制
bytes4 selector = bytes4(callData);
require(
allowedSelectors[toContract][selector],
"method not allowed"
);
3️⃣ 多阶段执行模型
验证阶段
↓
消息入队
↓
延迟执行
↓
管理员审计
这种模式现在被很多跨链协议采用。
例如：
LayerZero
Wormhole
Chainlink
六、对 Web3 开发者的关键启示
这个漏洞其实揭示了一个 Web3 常见误区：
“只要验证正确，执行就一定安全。”
现实情况恰恰相反。
跨链系统真正的风险是：
验证层一旦失效，执行层必须仍然安全。
因此现代安全设计强调：
🔐 最小权限原则(Least Privilege)
🔐 白名单执行模型(Allowlist Execution)
🔐 延迟执行机制(Timelock)
七、总结
Poly Network 的漏洞并不是复杂的密码学漏洞，而是一个 经典的权限控制失误。
攻击者利用：
任意合约调用
+ 验证权限接管
+ 跨链资金池释放
完成了一次史诗级攻击。
这类漏洞在最近一年仍然不断出现，尤其是在跨链桥、Layer2 messaging、桥接资产协议中。
因此对于 Web3 开发者来说，最重要的一句话是：
🚨 不要让任何跨链消息拥有“任意调用权限”。
否则，一条伪造消息就足以摧毁整个协议。
ChainSafeAI(链熵科技)专注于区块链生态安全，以“数据驱动 + 技术赋能”构建360°全方位安全防护体系，服务于交易所、金融机构、OTC服务商及加密资产投资者。
公司提供覆盖KYT风险监测、智能合约审计、加密资产追踪、区块链漏洞测试等在内的全维度安全与合规技术解决方案，助力客户防范洗钱、诈骗等风险，保障业务合规运行。
通过实时风险预警、合规审查与资金溯源分析，协助客户识别链上异常行为、防范洗钱及诈骗风险、降低被盗损失并提升资产追回可能性。