跨链桥安全事件总结分析

跨链桥事件总结分析

Poly Network 跨链桥事件

Relayer的不完整检验

  • 源链上(Ontology)的relayer没有对上链的交易做语义校验,因此包含修改keeper恶意交易可以被打包到poly chain上

  • 目标链上(以太坊)上的relayer虽然对交易做了校验,但是攻击者可以直接调用以太坊上的EthCrossChainManager合约最终调用EthCrossChainData合约完成签名修改

  • 攻击者精心够着了能导致hash冲突的函数签名,从而调用putCurEpochConPubKeyBytes完成对签名的修改

见攻击步骤的具体分析

Poly Network事件分析

Polygon Plasma Bridge漏洞

外部验证+乐观验证 该漏洞可以伪造铸币证明,导致双花攻击

完整的一次Withdraw交易过程如下:

  • 用户在Polygon上发起Withdraw交易,该交易会burn掉用户在Polygon的代币;
  • 经过一个检查点间隔(大约30分钟),等待该withdraw交易被包含到检查点中;
  • 超过2/3的验证者签名后将其提交到以太坊,此时用户调用ERC20PredicateBurnOnly合约中的startExitWithBurntTokens()校验checkpoint是否包含burn交易;
  • 校验通过,则铸造一个NFT退款凭证发给用户
  • 用户等待7天挑战期
  • 调用WithdrawManager.processExits()销毁NFT,并退款给用户

Polygon为了防止交易重放(双花攻击),使用NFT作为退款凭证,来唯一标识一笔Withdraw交易。但是,由于NFT的ID生成缺陷,造成了攻击者可以构造参数利用同一笔有效的Withdraw交易,生成多个不同ID的NFT,再利用这些NFT进行退款交易,从而实现“双花攻击”。

  1. addExitToQueue()会调用_addExitToQueue()铸造一个NFT,NFT的ID是由Plasma Bridge的age优先级生成
  2. WithdrawManager.verifyInclusion()函数对这样的withdraw交易进行校验,并生成对应的age
  3. 交易的校验和age的生成过程,都依赖参数data解码出的branchMaskBytes
  4. 交易的校验过程调用_getNibbleArray()对branceMaskBytes 进行了转码操作。
    在这里插入图片描述

该函数将对应的HP编码,转成对应的Hex编码。

  1. 如果传入的HP编码后的值b的第一个十六进制位(半个字节)是1或3,就解析第二个十六进制位。否则,就直接忽略第一个字节。
  2. 那么如果攻击者构造一个branchMaskBytes参数,使得其第一个十六进制位不等于1和3,则共有14*16 = 224种方式,能够获得相同的转码后的值
1
2
3
4
5
6
7
8
Hex转HP
[6,3,6,1,7,4,10] Hex编码
[20,63,61,74] HP编码
HP转Hex
[15,23,45,32,62] HP编码
[5,2,3,4,5,3,2,6,2]Hex编码
[20,45,76,34]HP编码 [23,...]HP编码
[4,5,7,6,3,4,10]Hex编码

Polygon事件分析CN

Polygon事件分析Eng

Meter.io 跨链桥事件

绕过源链上代币的锁定过程,却获得了代币的锁定证明,进而在目标链铸造资产

  • deposit()用于ERC20代币的存款,depositETH()用于WETH/WBNB代币的存款。
  • Bridge合约提供了两种方法:deposit()和depositETH()用于上述两种代币的存款,但是deposit()并没有阻止WETH/WBNB的存款交易,并且存在有着缺陷的逻辑判断。

在这里插入图片描述

tokenAddress不为_wtokenAddress地址时进行 ERC20 代币的销毁或锁定,若为_wtokenAddress则直接跳过该部分处理.

跨链桥合约中的depositETH函数会将链平台币转为wToken后转至depositHandler地址,所以在depositHandler执行deposit逻辑时,已处理过代币转移,故跳过代币处理逻辑

但跨链桥合约的deposit函数中并没有处理代币转移及校验,在转由deposiHandler执行deposit时,若data数据构造成满足tokenAddress == _wtokenAddress即可绕过处理

慢雾Meter.io跨链桥分析

Meter.io跨链桥分析

Wormhole Bridge跨链桥事件

利用虚假的签名,在目标链Solana链上mint了12万个WETH。

Wormhole中引入了Validator角色—即guardians

  • Wormhole中没有leader角色,所有的guardians都对其监听到的on-chain event执行相同的计算,同时对Validator Action Approval(VAA)签名。
  • 若有⅔+的大多数guardian节点使用各自私钥对同一event签名,则在所有链上的Wormhole合约都将自动认为其是有效的,并触发相应的mint/burn操作。
  1. 攻击者在Ethereum上向Solana转入0.1ETH
  2. 在Solana上铸造Wormhole ETH的交易触发了Wormhole函数complete_wrapped
  3. 函数的参数之一是transfer message ,guardians 签名的消息,说明铸造的代币和数量
  4. transfer message 是通过触发post_vaa函数创建的,检查guardians的签名来检查消息是否有效
  5. 实际上post_vaa并不检查签名,典型的Solana方式,智能合约通过调用verify_signatures函数创建
  6. verify_signatures 函数的输入之一是Solana内置的system程序,
  7. verify_signatures中调用Secp256k1签名验证函数
  8. Wormhole合约使用函数load_instruction_at来检查Secp256k1函数是否被首先调用
  9. load_instruction_at函数最近被弃用了,因为它不检查它是否针对实际系统地址执行
  10. 攻击者创建自己的账户地址,存储与Instrcutions sysvar相同的数据。
  11. 使用这个伪造的system程序,攻击者可以有效地谎报签名检查程序已被执行,但根本没有检查签名

Wormhole Bridge跨链桥事件

pNetwork跨链协议事件

绕过锁定的过程,攻击者合约发出对应的lock event .错误地提取,处理了恶意的日志事件。

  • 攻击者部署了一组专门设计的智能合约,来滥用pNetwork节点寻找的peg-out日志事件。
  • 创建一系列的事件日志,包含合法的peg-out请求,和攻击者合约发出了非法peg-out请求。
  • 负责提取这些日志事件的Rust代码存在错误,提取并错误地处理了合法和错误的日志。

pNetwork官方报告