DeFi浪潮下的“狠角色”DEX够安全吗？

如今，随着人们对 DeFi 的兴趣日益浓厚，DEX（即去中心化交易所）风靡一时。它们解决了常见的 CEX （即中心化交易所）问题，那我们也会问，DEX够安全吗？

在上一篇说明了代币本身的安全问题后（纯干货分享（一） | DEFI安全问题之基础篇），现在来聊聊DEX在兑换代币时可能产生的安全问题。目前DEX主要面临的安全问题大致可分成两类：

（1）DEX项目本身存在的安全问题。

（2）作为第三方协议，与其他DEFI项目交互时产生的安全问题。

本文将对第一类安全问题进行介绍。

Part.1

-Decentralized Exchange

重入漏洞

重入漏洞在上一篇我们也提到过，它属于需要防范的经典漏洞。与普通代币的重入相比，Uniswap的重入漏洞的主要表现形式为：攻击者在一笔兑换交易中利用Uniswap未及时更新价格前发起二次兑换，由于此时Uniswap未更新价格，使得二次兑换可兑出的代币数量比正常兑换的多。此外，在Uniswap的重入攻击中，攻击者利用单笔交易可能只能获得微小的收益，因此攻击者往往倾向于使用闪电贷或者循环套利扩大战果。

以imBTC攻击事件为例，该事件是由于Uniswap V1在调用ERC777系列代币时，未充分考虑合约回调的情况。

具体表现为：攻击者使用imBTC代币兑换ETH时（如图1），合约先通过self.getInputPrice函数计算正确的ETH数额并将ETH发送到目标地址，然后调用self.token.transferFrom函数时，会调用imBTC合约的_callTokensToSend函数（如图2），而_callTokensToSend函数会调用用户指定存储imBTC代币的合约。因此，如果攻击者部署存储合约，并改写其中TokensToSend函数，那么当兑换代币时，pair(两种代币组成的交易对)合约调用攻击者部署的存储合约，就可以回调pair进行二次兑换，而二次兑换时pair合约账本还未更新，使得计算的ETH数额比正常兑换要多，以此来获利。

详细攻击流程如下：

那么，为什么在第二次调用tokenToEthSwapInput函数兑换代币时，发送的ETH会比正常兑换要多呢?我们可以用公式来还原可兑换代币数量的代码逻辑：

首先，正常兑换下，getInputPrice函数计算可兑换的ETH数量为:

且正常第二次可兑换的ETH数量为：

但重入后第二次可兑换的ETH数量为：

由此可知，在重入后第二次兑换中只有ETH的储备量减少，而imBTC储备量未增加。这样在分母不增加的情况下，导致了等量的imBTC可以兑换更多的ETH。

针对此类安全问题，成都链安建议：

当合约涉及到资产转移时，使用“检查-生效-交互”模式来处理逻辑，对关键的业务操作可以使用OpenZeppelin官方的ReentrancyGuard进行修饰。

Part.2

-Decentralized Exchange

swap函数未对K值进行校验

Uniswap的核心是常量乘积模型K=x*y，其中的K值是该pair合约持有代币数量的乘积，且要求之后的每一笔交易完成后K值必须增加(考虑手续费)。因此如果不进行K值校验，将很容易成为攻击点。

以Impossible Finance事件为例，该项目是Uniswap的仿盘，实现了两种兑换代币的函数：cheapSwap和swap。其中cheapSwap函数少了k值校验（如图6），但是项目方知道缺少K值校验的后果，专门为cheapSwap函数增加了onlyIFRouter做修饰，来限制cheapSwap函数只能被指定的Router合约调用。

正常情况下，当用户使用Router合约兑换代币时，首先会使用getAmountsOut函数来计算正确的代币数量amounts；然后调用safeTransferFrom将用户的兑换消耗代币转入目标pair合约；最后，通过内部调用_swap函数来执行cheapSwap函数将兑换代币转至目标地址。

但是，由于cheapSwap函数缺少了K值检验，如果攻击者部署恶意代币合约，在Router合约调用safeTransferFrom函数时，回调正常的pair合约进行同种兑换，由于，回调后的兑换使用的amounts仍是未更新之前的数据，已不符合改变账本状态之后的校验，那么攻击会导致以错误的价格兑换出目标代币，以此获利。

该事件的具体攻击步骤如下：

1. 在准备阶段攻击者部署了AAA代币合约，并使用闪电贷借来1000WBNB，兑换65140个项目方的IF代币。

2. 使用其中一半的IF代币(32570个)与攻击者自己部署的AAA代币构建IF-AAA交易池。

3. 执行AAA-IF-BUSD路径的代币兑换，且当Router合约调用AAA代币合约的transferFrom函数时会执行攻击者的恶意代码，重入至IF-BUSD的pair合约，并将另一半IF代币正常兑换出221897个BUSD。

4. 回归到AAA-IF-BUSD路径的兑换，将之前计算的amounts值传入_Swap函数中执行这笔兑换，用一半的IF又兑换了2521897个BUSBD。

5. 归还闪电贷，完成攻击。

针对此类安全问题，成都链安建议：

在关键的兑换函数中必须做k值校验，不要为了节省gas和代码量就将K值校验和安全验证依赖外部验证，做到自身功能完善。

Part.3

-Decentralized Exchange

通缩代币未设置pair为分红例外

通缩代币在交易时会产生额外的分红与手续费。如果交易合约中包含了此类代币，且没有进行特殊处理，那么，就可能导致交易对合约记录的代币储量与实际的代币可用余额不一致。

以XSquid事件为例，XSquid是一种通缩代币，未将其与WHT代币组成的pair合约地址添加奖励例外列表，造成了pair合约除了正常代币兑换和流动性存储外，还存有多余的XSquid分红奖励代币。因此，攻击者就可以调用Swap函数将pair合约多余的XSquid代币转换为WHT提取（如图11），或者通过skim函数将多余的XSquid代币直接提取（如图12）。

针对此类安全问题，成都链安建议：

DEX在添加通缩分红型代币时多注意手续费以及分红的处理情况。在创建通缩分红型代币交易对时，可以添加奖励例外来避免此类代币的分红问题。

此外，以下两类不属于DEX本身的安全问题，但是被项目方借助了DEX的特性实施诈骗，所以将其写在文章末尾。

PART.1

诈骗交易池

这类问题主要是指项目方在自己发行的代币里留有后门，创建与主流代币的交易池，诱使投资者使用手里存在价值的代币买入项目方代币，并且不断拉盘对投资者进行投资欺骗。

以下面的TRTC项目方为例，项目方创建了ETH-TRTC的交易池。但是在TRTC的代币合约对transferFrom函数做了相关限制，要求代币的转出方为owner(管理员)或者为Uniswap。因此对于投资者，仅可以通过Uniswap买入TRTC代币，而不能卖出TRTC代币。最后由项目方把投资者投入的ETH提走跑路，给投资者带来了巨大的损失。

PART.2

项目方Rug Pull

Rug Pull是指项目方卷走投资者资金跑路的行为，目前已成为DeFi生态系统的最大骗局类型，项目方刻意制造代币价格暴涨的假象、许诺为提供流动性的投资者提供高回报等方式来大量聚集资金，一旦时机成熟就移除池子里的流动性或将代币卷走。这样的例子在DeFi屡见不鲜，AnubisDAO、Meerkat Finance、TurtleDEX、Squid token鱿鱼币等都是在卷款跑路之后，注销网站和社交媒体销声匿迹，导致投资者承担了巨大的损失。

写在最后

成都链安建议项目方使用锁仓和多重签名来控制代币流动性，避免出现砸盘跑路的情况。投资者不要被天上掉馅饼的事情冲昏头脑，防范虚假宣传。