现在，随着人们对 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为了盈利，金额比正常兑换多。

图1 Uniswap的tokenToEthInput函数

图2 imBTC的transferFrom函数

图3 imBTC的__callTokensToSend函数

具体攻击流程如下：

图4 ETH-imBTC事件流程图

那为什么第二次调用呢？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值校验，很容易成为攻击点。

图5 Uniswap的价格波动

以Impossible Finance以事件为例，这个项目是Uniswap仿盘实现了两种兑换代币的函数：cheapSwap和swap。其中cheapSwap函数少了k值验证(如图6所示)，但项目方知道不足K值校验的后果，特别是cheapSwap函数增加了onlyIFRouter修饰，限制cheapSwap函数只能指定Router合约调用。

图6 合同未检查k值的cheapSwap函数

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

图7 Router01合约的swapExactTokensForTokens函数

但是，由于cheapSwap函数缺少了K如果攻击者部署恶意代币合同，则进行值检查Router合约调用safeTransferFrom函数时，回调正常pair由于回调后的交换使用了相同的交换合同amounts以前的数据还没有更新，不符合变更账本状态后的验证，所以攻击会导致目标代币以错误的价格兑换，从而获利。

图8 合同进行k值校验的Swap函数

具体攻击步骤如下：

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

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

3. 执行AAA-IF-BUSD代币兑换的路径，当Router合约调用AAA代币合约的transferFrom攻击者的恶意代码将在函数中执行，并重新进入IF-BUSD的pair合同，另一半IF221897个代币正常兑换BUSD。

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

5. 返还闪电贷款并完成攻击。

图9 事件流程图

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

必须在关键交换函数中进行k值得验证，不要为了省钱gas还有代码量K价值验证和安全验证依靠外部验证，实现自身功能的完善。

Part.3

-Decentralized Exchange

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

通缩代币在交易过程中会产生额外的股息和手续费。如果此类代币包含在交易合同中，没有特殊处理，则合同记录的代币储量可能与实际代币余额不一致。

以XSquid事件为例，XSquid它是一种通缩代币，没有与之相比WHT代币组成的pair合同地址增加了奖励例外列表pair除了正常的代币兑换和流动性存储外，合同还有多余的XSquid奖励代币。因此，攻击者可以调用Swap函数将pair合约多余的XSquid代币转换为WHT提取(如图11所示)，或通过skim函数将是多余的XSquid直接提取代币(如图12所示)。

图10 XSquid除非交易对合同没有奖励

图11 Swap多余的函数可以兑换WHT代币

图12 skim提取函数可以大于reserve的部分

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

DEX增加通缩分红代币时，要多注意手续费和分红的处理。在创建通缩分红代币交易时，可以增加奖励例外，避免此类代币的分红问题。

另外，以下两类不属于DEX本身的安全问题了自己的安全问题DEX的特性实施诈骗，所以写在文章末尾。

PART.1

诈骗交易池

这类问题主要是指项目方在自己发行的代币中留下后门，创建与主流代币的交易池，诱使投资者使用有价值的代币购买项目方代币，并不断拉动投资者的投资欺骗。

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

图13 TRTC合约的transfer函数

图14 TRTC合约的ensure修饰

图15 TRTC合约的transferFrom函数

PART.2

项目方Rug Pull

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

写在最后

成都链安建议项目方使用锁仓和多个签名来控制代币流动性，避免砸盘跑路。投资者不投资者不应被天空中的馅饼所迷惑，以防止虚假宣传。