DoDo Research:从合约层面解析跨链桥机制设计弱点

原文作者:DoDo Research

原文来源:Twitter

近期 BNB 跨链桥受攻击,导致近 $570M 损失。这一事件再次把跨链桥的安全性问题推上热议。根据 Messari 8 月的研报数据,过去一年内共有 8 起跨链桥攻击事件,构成将近 $2B 美金的资产损失。

Dr.DODO 今天通过深度分析 Poly Network,Multichain 及 BNB 桥事件,从合约层面展示跨链桥机制设计弱点。跨链

首先,让我们简要回顾跨链桥的基本概念,以及设计机制分类。

不同的公链如同孤立的无需许可的计算机,具有不同的共识机制,相互之间无法直接通讯。跨链桥的存在就是为了使信息能够不被篡改地从一个计算机(源链)传递到另一个计算机(目标链)上。

跨链桥的核心是解决一个共识问题:跨链桥如何确定源链上的状态已发生改变,进而在目标链上铸造等量的资产?

不同的跨链桥对这个共识问题有不同解决方案,如采用中心化的桥,委员会,PoS 机制,轻客户端等。而不同的解决方案在信息传递的安全性,成本,延迟性上有所取舍。

详细分析可以参考此前文章《跨链漫谈:深度解析16个跨链方案权衡》:

接下来,我们进一步的把跨链流程进行拆解,了解跨链具体涉及到哪些步骤,这样在讨论不同攻击的时候,我们可以更好的理解出错的点在哪里。

跨链流程:

1. 当源链用户发起一个状态改变,如一笔交易;此事件将由源链验证者进行验证出块。

2. 此时跨链桥去监听此跨链事件,下载并对进行验证、签名。

3. 接下来被验证签署后的事件被传输至目标链。

4. 由目标链上的验证者进行验证出块。

5. 由此,源链上发起的状态改变得以在目标链被执行。

讲述跨链桥机制分类的文章已经很多,我们在此按验证方法把跨链桥分为:

– 外部性验证:PoS (较为中心化的 Multi-sig)

– 乐观性验证 (或状态行证明桥)

– 本地验证:轻客户端

跨链

按资产转移方式把跨链桥分为:

– 燃烧+铸造

– 锁定+铸造

– 在源链/目标链部署流动性池

跨链

Poly Network 攻击案例分析

简单来说, Poly Network 的工作机制是作为中间链去接收发送链的区块头,相当于所有它连接的链的轻客户端。

比如,当 Ontology 上发起一笔交易,区块头会被送到 PolyNetwork 上。区块头含有 state root hash,当交易与证明到达 PolyNetwork,这上面的 keepers 就可以进行验证。若合法, PolyNetwork 会自己发送一个 event,目标链的 relayer 听到后,会转发到目标链的 EthCrossChainManager 合约上。

跨链

在了解 Poly Network 工作机制之后,我们来看受攻击的合约。

首先,LockProxy 是控制资产的合约。其次,EthCrossChainManager (CCM) 的优越性有两点:

1)只有它能调用 LockProxy 进行 unlock 或者 burn 资产。

2)CCM 掌管着 CrosschainData , 合约保存着 Poly Network 的 keeper 公钥名单。

跨链

也就是说,当跨链交易的数据发到 CCM 之后,合约可以从这个数据中恢复出一些签名的地址。

然后它会拿这些地址和它自己存的 keeper 名单 做对比,看看是不是有 2/3 的 keeper 在这些地址里面。如果有,就认为发送过来的数据是合法的。

黑客通过 brute force 撞出了 CCM 中特定的 “Solidity function ID”, 从而得以调用 EthCrossChainData 的合约,并把其中存的 keeper 名单里的公钥匙换成自己的, 这样他就可以任意的给 CCM 发信息,自己去进行签署,从而操作 lock proxy。

所以上述攻击出现的问题有两点:

1)任意的用户可以进行的远程调用合约。在这个事件之后,项目方加入了白名单机制,只有指定方可以调用这个非常特别的合约。

2)合约之间的从属关系,导致关键的合约容易被篡改。

Multichain 攻击案例分析

Multichain 是可实现跨链路由的桥,通过封装资产 “anyToken”,Multichain 可实现任意资产的任意跨链。首先,当用户把 DAI 放到池子里,等量的 anyDAI 就会被铸造出来,然后由网络中的验证人确定这一事件,在 B 链铸造出等量的 anyDAI, 然后燃烧掉 A 链的 anyDAI。

跨链

受攻击的合约中,关注下图标记的 1,2,3 行:首先,从 anyDAI 这个合约拿到它底层资产合约的地址,即 DAI。其次,permit()  使用户通过签名来允许路由器从用户地址中提款。最后,safetransferfrom 是一个真正的提款动作。

注:签名了的交易被表示为(v,r,s)

跨链

可以看到黑客恶意部署的代币地址,和无效的签名。

跨链

回顾 8.1 中的三行代码,黑客重新部署了 anyDAI 导致底下 OUTPUT 的底层资产解析出来是 WETH 的地址。在此,Multichain 在这里的失误就是它应该检验代币地址是不是来自 Multichain 的代币。

跨链

第二个微妙的问题就是 permit 是 erc20 的一个扩展协议,但是由于比 weth 出来的时间晚,所以 weth 没有支持这个特性。那么如果去调用一个合约的一个不存在的方法,EVM 会自动去调用这个合约的 fallback 方法;然而,fallback 方法在这个情况下也没报错,所以,permit 功能也被成功执行。

而第三行之所以可以执行,我们可以认定因为 Multichain 之前请求了 WETH 无限的花费上线,黑客通过滥用了这个 approval 把 WETH 从受害者的账户转出。但值得注意的是很多的协议都会使用,以帮助用户节省 gas 费用。

BNB 桥攻击案例简述

Binance 事件的黑客用 RangeProof 伪造 Merkle proof证明某些数据存在 Merkle tree。

Proof 理论上难伪造。

BNB 桥涉及数据结构 IAVL:可理解为 等价于以太坊的 Merkle patricia trie,是一种 custom merklized balance binary search tree,InnerNode 分为 Left 和 Right 两个字段。

在这里 IAVL 的 RangeProof 存在的重要问题就是它允许 Left 和 Right 两个字段可以同时被填充(按理说只能有一个)。而当 Left 与 Right 都存在的情况下会忽略 Right 进行 RootHash 计算。

击者基本上通过将信息粘贴到 Right 字段中的优势,而这些信息从未得到验证,也从未影响哈希计算,以使验证者相信某些 Leaf 是 Tree 的一部分。从而,成功地伪造了 Merkle Proof。

关于 BNB 桥攻击中更复杂的合约调用逻辑可以阅读:

https://mp.weixin.qq.com/s/y9jiMKrGThN8J4agFnFpJw

转载声明:本文 由CoinON抓取收录,观点仅代表作者本人,不代表CoinON资讯立场,CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据,请自行承担全部责任。

声明:图文来源于网络,如有侵权请联系删除

风险提示:投资有风险,入市需谨慎。本资讯不作为投资理财建议。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 2022年10月14日 下午4:18
下一篇 2022年10月14日 下午4:18

相关推荐

DoDo Research:从合约层面解析跨链桥机制设计弱点

星期五 2022-10-14 16:18:24

近期 BNB 跨链桥受攻击,导致近 $570M 损失。这一事件再次把跨链桥的安全性问题推上热议。根据 Messari 8 月的研报数据,过去一年内共有 8 起跨链桥攻击事件,构成将近 $2B 美金的资产损失。

Dr.DODO 今天通过深度分析 Poly Network,Multichain 及 BNB 桥事件,从合约层面展示跨链桥机制设计弱点。跨链

首先,让我们简要回顾跨链桥的基本概念,以及设计机制分类。

不同的公链如同孤立的无需许可的计算机,具有不同的共识机制,相互之间无法直接通讯。跨链桥的存在就是为了使信息能够不被篡改地从一个计算机(源链)传递到另一个计算机(目标链)上。

跨链桥的核心是解决一个共识问题:跨链桥如何确定源链上的状态已发生改变,进而在目标链上铸造等量的资产?

不同的跨链桥对这个共识问题有不同解决方案,如采用中心化的桥,委员会,PoS 机制,轻客户端等。而不同的解决方案在信息传递的安全性,成本,延迟性上有所取舍。

详细分析可以参考此前文章《跨链漫谈:深度解析16个跨链方案权衡》:

接下来,我们进一步的把跨链流程进行拆解,了解跨链具体涉及到哪些步骤,这样在讨论不同攻击的时候,我们可以更好的理解出错的点在哪里。

跨链流程:

1. 当源链用户发起一个状态改变,如一笔交易;此事件将由源链验证者进行验证出块。

2. 此时跨链桥去监听此跨链事件,下载并对进行验证、签名。

3. 接下来被验证签署后的事件被传输至目标链。

4. 由目标链上的验证者进行验证出块。

5. 由此,源链上发起的状态改变得以在目标链被执行。

讲述跨链桥机制分类的文章已经很多,我们在此按验证方法把跨链桥分为:

– 外部性验证:PoS (较为中心化的 Multi-sig)

– 乐观性验证 (或状态行证明桥)

– 本地验证:轻客户端

跨链

按资产转移方式把跨链桥分为:

– 燃烧+铸造

– 锁定+铸造

– 在源链/目标链部署流动性池

跨链

Poly Network 攻击案例分析

简单来说, Poly Network 的工作机制是作为中间链去接收发送链的区块头,相当于所有它连接的链的轻客户端。

比如,当 Ontology 上发起一笔交易,区块头会被送到 PolyNetwork 上。区块头含有 state root hash,当交易与证明到达 PolyNetwork,这上面的 keepers 就可以进行验证。若合法, PolyNetwork 会自己发送一个 event,目标链的 relayer 听到后,会转发到目标链的 EthCrossChainManager 合约上。

跨链

在了解 Poly Network 工作机制之后,我们来看受攻击的合约。

首先,LockProxy 是控制资产的合约。其次,EthCrossChainManager (CCM) 的优越性有两点:

1)只有它能调用 LockProxy 进行 unlock 或者 burn 资产。

2)CCM 掌管着 CrosschainData , 合约保存着 Poly Network 的 keeper 公钥名单。

跨链

也就是说,当跨链交易的数据发到 CCM 之后,合约可以从这个数据中恢复出一些签名的地址。

然后它会拿这些地址和它自己存的 keeper 名单 做对比,看看是不是有 2/3 的 keeper 在这些地址里面。如果有,就认为发送过来的数据是合法的。

黑客通过 brute force 撞出了 CCM 中特定的 “Solidity function ID”, 从而得以调用 EthCrossChainData 的合约,并把其中存的 keeper 名单里的公钥匙换成自己的, 这样他就可以任意的给 CCM 发信息,自己去进行签署,从而操作 lock proxy。

所以上述攻击出现的问题有两点:

1)任意的用户可以进行的远程调用合约。在这个事件之后,项目方加入了白名单机制,只有指定方可以调用这个非常特别的合约。

2)合约之间的从属关系,导致关键的合约容易被篡改。

Multichain 攻击案例分析

Multichain 是可实现跨链路由的桥,通过封装资产 “anyToken”,Multichain 可实现任意资产的任意跨链。首先,当用户把 DAI 放到池子里,等量的 anyDAI 就会被铸造出来,然后由网络中的验证人确定这一事件,在 B 链铸造出等量的 anyDAI, 然后燃烧掉 A 链的 anyDAI。

跨链

受攻击的合约中,关注下图标记的 1,2,3 行:首先,从 anyDAI 这个合约拿到它底层资产合约的地址,即 DAI。其次,permit()  使用户通过签名来允许路由器从用户地址中提款。最后,safetransferfrom 是一个真正的提款动作。

注:签名了的交易被表示为(v,r,s)

跨链

可以看到黑客恶意部署的代币地址,和无效的签名。

跨链

回顾 8.1 中的三行代码,黑客重新部署了 anyDAI 导致底下 OUTPUT 的底层资产解析出来是 WETH 的地址。在此,Multichain 在这里的失误就是它应该检验代币地址是不是来自 Multichain 的代币。

跨链

第二个微妙的问题就是 permit 是 erc20 的一个扩展协议,但是由于比 weth 出来的时间晚,所以 weth 没有支持这个特性。那么如果去调用一个合约的一个不存在的方法,EVM 会自动去调用这个合约的 fallback 方法;然而,fallback 方法在这个情况下也没报错,所以,permit 功能也被成功执行。

而第三行之所以可以执行,我们可以认定因为 Multichain 之前请求了 WETH 无限的花费上线,黑客通过滥用了这个 approval 把 WETH 从受害者的账户转出。但值得注意的是很多的协议都会使用,以帮助用户节省 gas 费用。

BNB 桥攻击案例简述

Binance 事件的黑客用 RangeProof 伪造 Merkle proof证明某些数据存在 Merkle tree。

Proof 理论上难伪造。

BNB 桥涉及数据结构 IAVL:可理解为 等价于以太坊的 Merkle patricia trie,是一种 custom merklized balance binary search tree,InnerNode 分为 Left 和 Right 两个字段。

在这里 IAVL 的 RangeProof 存在的重要问题就是它允许 Left 和 Right 两个字段可以同时被填充(按理说只能有一个)。而当 Left 与 Right 都存在的情况下会忽略 Right 进行 RootHash 计算。

击者基本上通过将信息粘贴到 Right 字段中的优势,而这些信息从未得到验证,也从未影响哈希计算,以使验证者相信某些 Leaf 是 Tree 的一部分。从而,成功地伪造了 Merkle Proof。

关于 BNB 桥攻击中更复杂的合约调用逻辑可以阅读:

https://mp.weixin.qq.com/s/y9jiMKrGThN8J4agFnFpJw