2019年09月13日AirSwap团队公布了一个AirSwap智能合约中存在致命的漏洞，这一漏洞可以使得用户的资产在某些情况下被对手恶意吃单『偷盗』，PeckShield安全人员独立分析了该漏洞，并与AirSwap团队沟通了细节和修复方案。
漏洞影响概述
PeckShield安全人员深入分析AirSwap智能合约后发现，这一漏洞只对最近上线的Wrapper有影响，AirSwap团队在发现该问题后第一时间下线当前合约，并将AirSwap网站回退到之前使用的合约，从合约上线到问题修复整个过程仅持续了24小时，可见AirSwap团队对于合约安全的重视程度之高。
PeckShield安全人员独立分析了漏洞细节，并与AirSwap团队沟通细节和修复的方案，同时将该漏洞命名为“ItchySwap”。
PeckShield在此提醒，由于这一漏洞可使用户的资产被攻击者恶意偷盗，受此次影响的账号一共有18个，其中有部分账号有数万至数十万美元的资产，这些账号需要尽快完成升级，或与AirSwap团队联系。
ItchySwap漏洞详解
一、AirSwap合约
在分析之前，为方便起见，我们先定义几个概念：
1.maker：出售资产的一方；
2.taker：购买资产的一方；
3.order:maker与taker之间发生资产交割的订单；
4.Indexer:AirSwap中的订单簿，汇聚了当前正在出售及需要购买的资产信息。
下图说明了maker、taker和Indexer之间的交互流程：
AirSwap是一个基于Ethereum的点对点去中心化交易所，它集成了SwapProtocol，在其中作为一个自动托管服务，允许交易的双方在以太坊上安全地交易任何资产。与许多去中心化交易所不同，AirSwap虽然没有对资金进行托管控制，但仍然有一个用于匹配目的的集中式订单簿，它实现了一个用于交易和订单匹配的完全对等模型。
特别值得一提的是，有一个名为Indexer的链下服务，可以聚合来自maker和taker的交易意图，然后为他们提供匹配的服务。特别是，一旦taker找到了合适的maker，他们就会开始进行场外价格的谈判。一旦达成协议，订单将由Taker通过SwapProtocol在链上进行填充和资产交割。
在AirSwap智能合约中，taker将订单上链及资产交割的过程在AirSwapswap(Types.Ordercalldata_order)函数之中，这一函数实现如下所示：
1）验证订单有效性
订单order参数有效性检查，这些信息均由taker上链的时候指定的，也意味着这些信息都可以由taker篡改，具体包含：
1.订单还在有效期内；
2.订单还没有被其它的taker吃单；
3.订单还没有被取消；
4.订单的nonce大于最小值；
5.设置订单状态为TAKEN状态。
2）验证taker信息
确立有效的taker，根据order中指定或者等同于合约的调用方msg.sender。
3）验证maker信息
验证maker的有效性，这里的验证分为两种情况考虑：
1.没有maker签名的订单：需要保证msg.sender有权限操作这个maker地址即可，即这笔order发起者有权限操作maker的资产；
2.order中指定了maker的签名信息：验证签名的有效性。
4）资产交割
如果上述的验证流程没有问题，那么直接执行maker和taker的资产交割。
二、Wrapper合约
在上述的AirSwap合约中，用户通过swap()函数执行资产互换，这一流程非常清晰，没有问题。但是这一合约存在一点不完美的地方，用户只能通过Token进行资产互换，无法直接用ETH平台币参与其中。用户可以先把ETH转换成WETH,再用WETH参与互换，但无论如何，用户使用体验上多了一步。
为了降低用户使用体验上的摩擦，AirSwap团队与2019年09月12日推出了Wrapper合约，其使用是自动将用户转入的ETH转换成WETH之后再参与资产互换的过程，其关键流程如下：
1.验证swap()发起方与taker是相同的；
2.如果用户发起swap()有携带了ETH资产，并且需要转换的token为WETH,那么就自动将ETH转换成WETH；
3.直接调用AirSwap合约的swap()操作。
考虑到一种特殊的场景，Alice希望通过Wrapper合约执行AirSwap资产互换，这一过程需要先由Alice自行在AirSwap合约中授权Wrapper合约，以允许Wrapper合约可以执行各自的资产交割流程。
由于区块链的透明性，Eve看到了Alice的授权操作，那么他就可以向Wrapper合约发起一笔恶意的订单，其包含的内容如下：
1.order中的有效时间、nonce为一个非常大的数值；
2.order中的maker对应的账号为Alice的账号；
3.order中的taker为空；
4.order的signature为空。
将上述构造好的order代入AirSwap的swap()函数，其中1，2两步的验证由于是taker控制的，不会有问题，我们重点看下第三步验证maker信息：
由于此时AirSwap合约是由Wrapper合约调用的，那么msg.sender即Wrapper合约的地址，前文讲到，Wrapper合约是经过Alice授权可直接控制Alice的资产，此时虽然Eve没有权限操作Alice的资产，但此时可以通过Wrapper控制，也就间接地控制了Alice的资产。
安全规避
PeckShield安全人员分析发现，截止至2019年09月28日为止，共有6个账号执行了revoke()操作，以解除对Wrapper合约的授权，还有12个账号存在安全风险，这剩下的所有账号应当立即执行revoke()操作，或者将账号中的资产转移至未对Wrapper授权过的安全账号。
任何的代码在上线生产环境之前都应当得到充分的测试和验证，特别是承载着用户价值的DEX平台。在产品增加新特性之时，一定要考虑到旧特性的兼容性与安全，新特性的引入不应该触发旧产品中设计不完备的地方。
附录
备注：AirSwap官方漏洞细节链接：https://medium.com/fluidity/critical-vulnerability-in-a-new-airswap-smart-contract-c1204e04d7d3
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。