2021 年 08 月 10 日，据慢雾区消息，跨链互操作协议 Poly Network 遭受黑客攻击，慢雾安全团队第一时间介入分析，并将分析结果分享如下。

攻击背景

Poly Network 是由 Neo、Ontology、Switcheo 基金会共同作为创始成员，分布科技作为技术提供方共同发起的跨链组织。

如下图，通过官方的介绍我们可以清楚的看出 Poly Network 的架构设计：用户可以在源链上发起跨链交易，交易确认后由源链 Relayer 将区块头信息同步至 Poly Chain，之后由 Poly Chain 将区块头信息同步至目标链 Relayer，目标链 Relayer 将验证信息转至目标链上，随后在目标链进行区块头验证，并执行用户预期的交易。

以下是本次攻击涉及的具体地址：

攻击核心

1、源链未对发起的跨链操作的数据进行检查。

2、目标链未对解析出的目标调用合约以及调用参数进行检查。

3、EthCrossChainData 合约的 owner 为 EthCrossChainManager。

4、 bytes4(keccak256(abi.encodePacked(_method, "(bytes,bytes,uint64)")))

可以被 hash 碰撞。

攻击细节

Poly Network 会在各个链上部署智能合约以便进行跨链互操作（分析将以在以太坊部署的智能合约为例），其中 EthCrossChainManager 合约用于验证 Poly Chain 同步来的区块头以确认跨链信息的真实。EthCrossChainData 合约用于存储跨链数据，中继链验证人 (即 Keeper) 的公钥也存储在这个合约中。LockProxy 则用于资产管理。

本次攻击中，攻击者分两步来完成这次攻击，我们接下来进行详细分析：

首先攻击者通过在其他链调用 crossChain 函数构造数据发起跨链交易。

我们切入此函数进行分析 :

EthCrossChainManager.crossChain

(https://github.com/polynetwork/eth-contracts/blob/master/contracts/core/cross_chain_manager/logic/EthCrossChainManager.sol#L91)

从上图我们可以清晰的看出，此函数只是用于帮助用户构造 makeTxParam 并存储了构造后的哈希以便后续验证，其并未对用户传入的跨链操作参数进行任何限制，因此攻击者完全可以通过构造任意想构造的数据而让 Relayer 毫无防备的将其同步至 Poly Chain，通过 Poly Chain 将其同步至以太坊 Relayer。

随后在以太坊上的 Relayer 通过调用 EthCrossChainManager 合约中

的 verifyHeaderAndExecuteTx 函数提交区块头信息来验证这笔跨链信息的真实性。

我们切入此函数进行分析：

EthCrossChainManager.verifyHeaderAndExecuteTx

(http://www.w9a.com/d/file/tineiron/20210812/ugh1lqxz31e.sol alt="被黑 6.1 亿美金的 Poly Network 事件分析与疑难问答" loading="lazy" src="http://www.w9a.com/d/file/tineiron/20210812/20ndspwafe0.jpg"/>

通过上图代码我们可以看出其先对区块头进行反序列化，以解出所需要验证的具体信息。随后调用 getCurEpochConPubKeyBytes 函数从 EthCrossChainData 合约中获取 Keeper 公钥，并通过 deserializeKeepers 函数得到 Keeper 地址。

接下来将通过 ECCUtils.verifySig 验证签名是否为 Keeper，从以下代码中我们可以发现 verifySig 函数中会切出签名者的 v r s，并通过 ecrecover 接口获取签名者地址，然后调用 containMAddresses 函数循环比较签名者是否为 Keeper，只要 Keeper 签名数量符合要求即可通过检查，数量要求即为 EthCrossChainManager 合约传入的 n - ( n - 1) / 3)。

签名验证后会通过 ECCUtils.merkleProve 进行默克尔根验证，只要是正常跨链操作即可通过此项检查。随后会对交易是否重复发送进行检查并存储已验证后的数据。这里只需保证不重复提交即可。

最后，也是最关键的一步，其将通过内部调用_executeCrossChainTx 函数执行构造的数据。

从上图我们可以看出_executeCrossChainTx 函数未对传入的_toContract、_method 等参数进行检查就直接以_toContract.call 的方式执行交易。

其中通过链上数据我们可以看出 EthCrossChainData 合约的 owner 即为 EthCrossChainManager 合约，而先前我们知道中继链验证人 (即 Keeper) 的公钥存在 EthCrossChainData 合约中，且此合约存在 putCurEpochConPubKeyBytes 函数可以直接修改 Keeper 公钥。

经过以上分析，结果已经很明确了，攻击者只需在其他链通过 crossChain 正常发起跨链操作的交易，此交易目的是为了调用 EthCrossChainData 合约的 putCurEpochConPubKeyBytes 函数以修改 Keeper 角色。随后通过正常的跨链流程，Keeper 会解析用户请求的目标合约以及调用参数，构造出一个新的交易提交到以太坊上。这本质上也只是一笔正常的跨链操作，因此可以直接通过 Keeper 检查与默克尔根检查。最后成功执行修改 Keeper 的操作。

但我们注意到 putCurEpochStartHeight 函数定义为

    function putCurEpochConPubKeyBytes(bytes calldata curEpochPkBytes) external returns (bool);