去中心化金融(DeFi)作为区块链生态当红项目形态，其安全尤为重要。从去年至今，发生了几十起安全事件。BlockSec作为长期关注DeFi安全的研究团队(https://blocksecteam.com)，独立发现了多起DeFi安全事件，研究成果发布在顶级安全会议中（包括USENIXSecurity,CCS和Blackhat)。在接下来的一段时间里，我们将系统性分析DeFi安全事件，剖析安全事件背后的根本原因。
今天带来这个系列的第一篇，去中心化跨链资产桥梁项目ChainSwap攻击事件。
0xffffffff.前言
北京时间2021年7月11日凌晨，去中心化跨链资产桥梁项目ChainSwap再次遭到攻击，部署于该跨链桥上的20+个项目遭到攻击，损失超过800万美元，是DeFi发展史迄今为止发生的最严重的攻击事件。本文将抽丝剥茧分析攻击的全部细节。
时间：Jul-10-202107:16:11PM+UTC#12801461
阅读建议：
如果您刚刚接触DeFi，可以从头开始看起，但是文章较长，看不下去记得点个关注再走
如果您对Sushiswap、AMM、DEX等比较了解，可以直接从「0x1攻击分析」开始
0x0.背景介绍
ChainSwap是一个跨链资产桥。所谓跨链资产桥，本质上就是为了解决在多个智能合约链的资产转移问题。举例来说，在币安智能链链上的USDT代币，想要转换到以太坊主链上进行交易，则必须通过跨链资产桥进行转换。ChainSwap、RenProtocol等是目前具有代表性的跨链资产桥项目，其上承载了数千万美元的跨链交易，也使得这次攻击造成的损失极为惨重。
①跨链资产桥ChainSwap
随着以太坊及基于以太坊的去中心化金融生态的不断发展壮大，越来越多基于以太坊虚拟机的智能合约区块链应运而生，这其中就包括了币安智能链、火币生态链及波场链。
在多种智能合约链共存的场景下，出于在不同链上进行代币交换的需求，跨链资产桥项目逐渐进入人们的视野。传统的跨链资产桥如Shapeshift、ChangeNOW等是中心化的服务，在去中心化的大背景下，去中心化的跨链资产桥项目不断出现，而ChainSwap正是其中的代表服务之一。
设计一个跨链资产桥，最大的难点在于如何在不同链之间验证交易。针对这个问题，ChainSwap采取了PoA机制。
整个ChainSwap网络中存在一组验证者节点，这些节点的工作是验证一条链上的交易并在另一条链上提供证明。举例来说，假设用户A希望将以太坊链上的1000USDT转移到BSC链上，这一步转移操作实现如下：
首先在以太坊链上，服务调用链上合约的send方法，把用户的1000USDT发送给以太坊上的ChainSwap合约，生成一个发送交易。
随后，ChainSwap会将这笔交易的信息发送给一组验证者，这些验证者会将这笔交易验证并返回一组签名。
最后在BSC链上，服务调用链上合约的receive方法，在BSC链上收到1000USDT发回给用户。这个调用会发送以太坊上交易的签名以验证在以太坊链上的交易。
②ChainSwap的实现机制概述
从本质上来说，ChainSwap是不同链上交易的撮合方。拿以上的转移操作为例，第二步需要有一个独立的验证者对以太坊链上用户的转账操作进行证明。那么怎样实现高效安全的签名机制呢？
让我们回归以太坊的基本知识。以太坊用户生成地址的过程如下：首先生成一个巨大的随机数作为私钥，该私钥经过一定的单项算法可以得到公钥，再通过某个单向哈希算法生成地址。所以本质上来说，地址的背后对应私钥。
私钥不仅可以用来解密，还可以用来签名。具体来说，任何人可以将某个消息序列化，并用私钥生成对应的签名。签名包括四个部分：消息的摘要和三个参数。
签名之后，怎样验证签名的有效性呢？智能合约的Solidity编程语言提供了ecrecover函数，可以通过以上四个参数计算得到签名这个消息的地址。合约的实现方必须自行验证这个地址是否有效。后文我们将看到，正是由于没有验证地址的有效性，导致了ChainSwap的这次攻击。③ChainSwap的实现机制概述在分析代码和攻击之前，首先概述一下ChainSwap的实现机制：
ChainSwap作为一个跨链资产桥，其设置了一个Factory用于管理和查询下属的项目，即找到跨链币种在以太坊主链上的地址。
每个项目可以向ChainSwap申请对接，自动成为跨链代币。ChainSwap会为这些代币创建一个映射Token用于代表该Token在链上的“映射”。
上文说到，为了跨链地证明交易，ChainSwap设置了几个验证者来进行交易验证。ChainSwap代码中将验证者命名为签名者，且为每一个验证者限定了配额，也就是说每个验证者验证的交易额在一段时间内是有限制的。但验证者会有一定的初始配额，且该配额会随着时间累积。
0x1.代码分析
ChainSwap会为该项目承接的每一个代币创建一个TokenMapped合约来代表该代币在链上的映射。攻击者的入口即为TokenMapped合约的receive方法。下面我们逐步分析相关代码，看看攻击是如何实现的。
①攻击入口分析
上图展示了receive函数的全部代码。正常情况下，用户在其他链上向ChainSwap发送某种Token之后，交易经过签名者验证，用户可以将验证信息发给以太坊主链上的ChainSwap合约，后者会在验证之后将Token转账给给用户。receive实现的正是这样一个流程。
该函数的实现较为复杂，在开头首先收取0.05ETH的费用。接下来，合约向ChainSwapFactory请求参数，获得最小签名个数，对传入签名个数进行验证。从交易记录中可以查到这个值为1，也就是说跨链交易只需要一个签名者的签名即可通过。在后文中会对这个参数的修改过程进行描述。
然后对每一个签名，首先常规验证传入的签名数组是否有重复。其次，通过ecrecover验证签名的有效性。这一步是常规的的签名验证过程，由于和攻击本身无关，不再赘述。最后，通过_decreaseAuthQuota减少验证者的配额。看到这里，整个实现逻辑似乎是完整且清晰的。
但是通过以上分析过程我们发现，入口函数receive并没有对签名者的身份进行验证，Signatory参数的存在仅仅用于配合ecrecover函数验证消息是否确实是由Signatory进行签名。也就是说，任何人都可以生成一个签名。也许在receive函数调用的内部函数中对Signatory进行了验证？我们继续往下看。
上图展示了第一个内部函数_decreaseAuthQuota的实现，该函数的主要功能为减少记录在_authQuotas映射中对应Signatory的配额值。实现本身非常简单，但是红线部分展示的modifier部分引起了我们的注意。_decreaseAuthQuota并没有对Signatory的合法性进行检查，那么这个modifier是否有验证呢？
上图展示了updateAutoQuota(signatory)的实现。modifier是Solidity语言的一种语法糖，以上图展示的modifier为例，这个modifier修饰的函数会将自己添加在函数中，最后一行的短划线表示modifier标注的函数的真正函数体将会出现的位置。可见该modifier的实现方式是先调用authQuotaOf函数更新Signatory的配额，并根据条件进行更新。注意到这里在调用authQuotaOf之后也没有做Signatory的合法性进行验证。
最后来看authQuotaOf的实现。首先直接获取_authQuotas映射中Signatory的配额。不同于Python等主流编程语言，Solidity是没有类似Python中KeyError的概念的，如果映射中不存在这个键，则会返回0，然而这里没有对返回值进行检查。接下来，通过autoQuotaRatio和autoQuotaPeriod两个参数计算新的最大配额quotaCap。通过搜索以太坊交易记录，这两个参数的值分别为1e15和86400。
因此倒数第三行计算得出的quotaCap是一个很大的值。因此quotaCap的理论最大值为代币供应量的0.1%。
倒数第二行，由于lasttimeUpdateQuotaOf中找不到这个Signatory，因此返回0，因此在Signatory非法时delta可以比quotaCap更大。最后一行通过计算返回更新后的配额，通过以上的分析不难看出，在攻击中返回的正是quotaCap。
总结一下，receive函数实现的整个过程，都没有对传入的Signatory的合法性进行检查。因此攻击者只需要随机生成一个地址并生成对应的签名，即可过ChainSwap，自己为自己提供签名。同时，由于authQuotaOf在实现逻辑上的错误，在Signatory不合法时会返回一个非常大的值，导致了这次攻击事件的发生。而本次攻击事件发生的本质，是没有对映射索引的值进行验证。由于Solidity并不会在映射的键不存在时触发任何错误，因此这类检查就显得非常重要。正是由于缺少这样的检查，导致了这次损失超过800万美元的攻击。
③番外篇1：参数minSignatures的修改
通过以上的分析不难看出，攻击发生的主要原因是缺少对映射索引返回值的检查。但参数参数minSignatures的值同样引起了我们的注意。我们发现在交易0x50d462f4中，参数minSignatures的值被修改成1：
这个交易出现在区块12377182，这是攻击发生的65天前。这种针对协议底层参数的修改只能由官方进行，通过阅读代码也验证了这一点：
Factory合约继承了Configurable合约以提供参数配置功能。图中函数声明中的governancemodifier代表该函数仅能通过管理者进行修改。我们并不知道为什么ChainSwap官方修改了这个参数，但这个修改一方面增加了系统的不可靠性，另一方面为攻击者提供了便利，因为攻击者只需构造一个签名便可过ChainSwap系统，直接提取代币。
④番外篇2：虚假的验证
有趣的是，在管理者Factory的合约实现中，ChainSwap设计了一个变量来保存Signatory构成的数组，代码如下图所示：
但很遗憾的是，通过对Factory合约实现的审计，我们发现这个变量仅仅是在管理Signatory配额的时候被使用，并没有验证一个任意地址是否包含在这个数组中的代码实现，因此任何一个人都可以创造一个地址并为自己生成签名。
0x2.攻击分析
经过以上的代码分析，不难得出一个最简单的攻击流程：只需要自己批量创建多个地址，生成并提交签名即可。由于TokenMapped并不会进行任何验证，可以将合约中锁仓的代币直接获得，实现空手套白狼。攻击者的真实攻击就是这样实现的。以其中一笔攻击交易为例，交易执行Trace如下：
可以看出，攻击只是简单地调用了以上展示的有bug的receive函数，传入了虚假的签名，就套到了攻击者本不应获得的代币。通过这样的攻击方式，攻击者攻击了基于ChainSwap的20+个项目，盗走了价值800万美元以上的代币，造成了极为严重的损失。
BlockSec团队以核心安全技术驱动，长期关注DeFi安全、数字货币反和基于隐私计算的数字资产存管，为DApp项目方提供合约安全和数字资产安全服务。团队发表20多篇顶级安全学术论文(CCS,USENIXSecurity,S&P)，合伙人获得AMiner全球最具影响力的安全和隐私学者称号(2011-2020排名全球第六).研究成果获得中央电视台、新华社和海外媒体的报道。独立发现数十个DeFi安全漏洞和威胁，获得2019年美国美国国立卫生研究院隐私计算比赛(SGX赛道)全球第一名。团队以技术驱动，秉持开放共赢理念，与社区伙伴携手共建安全DeFi生态。扫描二维码，关注更多精彩
https://www.blocksecteam.com/
contact@blocksecteam.com
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。