表里不一:Sanshu Inu的Memestake合约遭袭事件分析

首页 > 狗狗币 > 表里不一:Sanshu Inu的Memestake合约遭袭事件分析

前言

北京时间2021年07月21日03:40,我们的攻击检测系统检测到某个交易异常。通过对该交易进行扩展分析,我们发现这是一起利用通缩代币(deflation token)KEANU的机制对Sanshu Inu部署的Memestake合约的奖励计算机制的漏洞进行攻击的事件,攻击者最后获利ETH约56个。下面详细分析如下:

0x0. 背景介绍

今年以来爆火的狗狗币(DOGE)、柴犬币(SHIB)引发了广泛的关注,同时带火了其他相关的meme币,更引发了大量的项目方开发自己的meme币及围绕meme币提供服务,其中Sanshu Inu就是其中一员。Sanshu Inu不仅发行meme币SANSHU,还创建了合约Memestake作为meme币的耕种池。用户只要往Memestake中质押meme币,就可以获得代币Mfund作为奖励。

另一方面,大量的meme币都是通缩代币,即该种代币的发行量会逐渐减少。其中部分meme币的通缩实现形式是在用户每次进行交易转账(transfer)的时候扣取一定比例的币用于销毁和再分配,这将导致接收方实际收到的token数量小于支出方实际支付的数量。本次涉及的通缩代币KEANU就是采用这种实现。

该攻击的大致原理就是通过控制Memestake进行KEANU的多次转入转出减少其持有的KEANU数量,从而利用其奖励计算函数的漏洞致使Memestake给攻击者发送大量Mfund。

0x1. 代码分析

为了便于理解,我们首先简要地介绍一下和此次攻击相关的两个实体合约:KEANU代币的 KeanuInu 合约和 Memestake 合约。

KeanuInu 合约

正如前面所说,KeanuInu在实现代币KEANU的转账时,会扣取一定比例的币用于销毁和再分配,其中用于销毁的比例设置为定值——2%。如图,在调用KeanuInu的transfer()及transferFrom()函数的时候,函数调用中显示的转账数量跟emit的事件log中记录的数量并不一致。

其由于其实际代码实现较为复杂,此处不再展示,感兴趣的朋友可以根据后面附录给出的合约地址在etherscan.io自行查看合约实现。另外,上面两张截图来源于我们自行开发的交易解析工具,目前开放公测中。欢迎各位点击https://tx.blocksecteam.com:8080/试用。我们的工具将函数调用与过程中产生事件log结合展示的方式,对于分析通缩代币等问题更有帮助。

Memestake 合约

下图是MemeStake的deposit函数。函数首先调用updatePool更新资金池状态,然后将用户的token转账给自己。当传入的_amount大于0时会在代码的1295行进行转账。

然而,由于KEANU token的通缩特性,虽然调用safeTransferFrom函数时传入的金额是amount,但是实际上转入资金池的金额小于amount。并且在代码分析中我们注意到,transfer的目的地是自己,也就是说对于MemeStake来说,所有用户的某个币种(如KEANU token)的存款都属于MemeStake。

在转账后的1296行,MemeStake会对用户的存款进行登记,但这里登记采用的仍然是amount(而真实的转账量小于amount),因此用户真正的存款量比登记的user.amount更小。

最后在1299行,可以看出user.rewardDebt参数也是根据(比真实值要大的)user.amount来计算的。

下图是MemeStake的withdraw函数。该函数首先会检查user.amount是否还有足够的余额,但由于user.amount本身比真实值大,因此这里的检查是不准确的。接下来,同样会调用updatePool函数更新资金池状态。

在1321行,withdraw函数会先扣除在user.amount中登记的余额,然后调用transfer函数把token转回用户。和deposit函数一样,这里的逻辑同样存在问题,由于每次转账都会造成通缩,因此转给用户的数量会小于实际的转账量。

最后来看MemeStake的updatePool函数。首先从1255行可以看出,每次调用会记录上一次更新的blockNumber,如果此次调用的区块和上次更新时相同,则会直接返回,也就是说updatePool对每个区块只会更新一次资金池状态。

接下来在1259行,会获取MemeStake自身在token合约中的余额(上文提到,每次用户deposit都会将token转给MemeStake)。最后在1275行,会利用这个余额作为分母,计算该资金池每一次deposit和withdraw的奖励(也就是pool.accMfundPerShare参数)。计算方式如下:

pool.accMfundPerShare += mFundReward / token.balanceOf(MemeStake)

回到withdraw,我们来看存取款奖励代币Mfund是怎样转账的。首先在上图withdraw函数的第1325行,计算用户是否有pending的Mfund token没有发放,计算公式为:

rewardMfund = user.amont * pool.accMfundPerShare / 1e18 – user.rewardDebt。

而rewardDebt是这样计算的(图中第1325行):

user.rewardDebt = user.amount * pool.accMfundPerShare / 1e18

因此,从代码中我们不难构造出一种可能的攻击:

首先,在一个交易内,通过反复调用deposit和withdraw函数,榨干MemeStake的资金池。这个操作利用了三个代码问题:

首先,user.amount的记账比真实值多,因此每次withdraw都可以成功。

第二,MemeStake中所有用户的资金都在一个池子中,因此每一笔转账实际上Burn掉的是池子中其他用户存入的KEANU token。

第三,由于updatePool在同一个块中不会进行状态更新,因此不会影响pool.accMfundPerShare参数,也不会产生Mfund token的reward。

接下来,在下一个区块时,直接调用withdraw函数。

通过对updatePool函数的分析可知,此时会产生池子状态的更新,且由于前一步操作榨干了MemeStake的资金池,token.balanceOf(MemeStake)极低,产生了巨大的pool.accMfundPerShare。

随后在withdraw函数的第1315行,计算出的Mfund reward量非常大,导致巨额的Mfund回报。

0x2. 攻击分析

前面介绍了漏洞成因及漏洞的利用方式,我们接下来介绍攻击者实际是如何进行攻击的。

如图所示,攻击可以分为4步,其中关键攻击步骤为第2步,利用通缩代币的特性操纵Memestake的奖励计算。

第1步(准备),首先攻击者创建了两个合约并进行初始化,其中合约一为表现正常的投资合约,攻击者通过合约一往Memestake存入约2,049B KEANU ,为步骤3获利大量MFUND奖励做好铺垫。合约二为操纵Memestake的奖励计算的合约,先进行了相关token的approve操作。

第2步(操纵),攻击者先从uniswapV2中flash loan大量的KEANU代币,然后通过合约二往Memestake中多次deposit 和withdraw大量KEANU,导致Memestake被迫大量交易KEANU。由于KEANU是一种通缩代币,每次交易会烧掉2%的交易额,导致用户真正存入Memestake的量比登记的user.amount更小,取出时又是按照user.amount转给用户(详见代码分析),导致Memestake池子中KEANU的代币持有量不断减少,最终为1e-07。如下图所示,涉及交易为0x00ed,交易截图未完全,请自行根据交易查看。

第3步(获利),攻击者首先通过合约二调用了Memestake.updatePool()函数,修改了KEANU所在池子的accMfundPerShare,由于该值依赖于池子所持有的KEANU的代币量,而这在第二步中被操纵了(具体公式见下方代码分析)。这使得合约二在接下来withdraw的时候可以获得远超正常值的Mfund(约61M)这种token作为奖励。第3步发生于交易0xa945中,同时攻击者开始将部分获得的MFund换成WETH等代币。

第4步(收尾),攻击者将获得的MFund、KEANU等代币换成ETH,并通过Tornado.Cash转移走,至此攻击结束,攻击者从中获利ETH 55.9484578158357个(攻击者的EOA地址及部署的攻击合约还残留有部分SANSHU和KEANU代币未计入),约10万美元。

下面附上攻击地址0x0333的交易截图,交易截图未完全,请根据地址自行查看详情(具体地址及交易详见文章末尾)。

Others:

有趣的是,攻击的第2、3步都与flashbots交易有关。

其中第2步涉及的交易0x00ed由于采用了UniswapV2 flashloan,且交易前后相当于用约38ETH去购买了KEANU,由此产生了很大的套利空间。因此该笔交易受到另一名攻击者的三明治攻击(sandwich attack),即本事件的攻击者也是另一个三明治事件的受害者。该三明治攻击者获利3.2769697165652474ETH,但是给了矿工2.405295771958891249ETH,净获利0.8716739446063562ETH。

而第3步攻击涉及的交易0xa945则由于在uniswap池子中大量售出MFund,创造了套利空间,所以被back-running而成为flashbots交易。该searcher获利0.13858054192600666ETH,其中交给矿工0.099085087477094764ETH,净获利0.03949545444891189ETH。

由于UniswapV2中将flash loan的实现与普通的Swap结合在一起,具体的实现原理及为什么由此导致第2步存在套利空间可以参阅我们的paper Towards A First Step to Understand Flash Loan and Its Applications in DeFi Ecosystem (SBC 2021). 链接https://www.blocksecteam.com/papers/sbc21_flashloan.pdf

0x3. 总结及安全建议

攻击者利用通缩代币的特性控制了平台持有代币的数量,影响了奖励代币的计算发放,由此获利ETH 55.9484578158357个。而这原因在于,Sanshu Inu平台在引入通缩代币时缺乏一定的安全考量,导致攻击者有空可趁。

由此,我们给有关项目方的安全建议有:

1. 对项目引入的代币应当有足够的认识,或者通过建立白名单的机制对交互的token进行限制。近两年来,已经有多起安全事件与未加限制的token或者交互的token有问题有关,如最近的BSC链上的Impossible Finance事件,我们这个系列上一篇Akropolis攻击事件,2020-11-17的Origin Dollar事件及2020-06-28的Balancer事件等。特别是与通缩代币的交互,如在该事件发生不久后,PeckShield也报告了一起发生在polygon链上同样利用通缩代币及奖励计算漏洞的安全事件——PolyYeld事件。

2. 项目上线前,需要找有资质的安全公司进行安全审计。我们可以看到,由于defi的money lego属性,很多defi项目之间可以随意组合,从而产生了互相影响,而这正是defi领域安全事件频发的原因。因此,项目方所需关注的安全问题不仅仅局限于自己项目,也同样需要考虑在与其他项目交互过程中存在的安全漏洞。

0x4. 引用

攻击者EOA地址:

0x0333e323e61aa8afa38a1623604a165dcb9f4fec

攻击合约一:

0x67a54b340392e661af8f757ba03674ede40d9dc3

攻击合约二:

0xe30dc9b3c29534e9b4e9a166c2f44411163ad59f

攻击第2步交易0x00ed: 

0x00edd68087ee372a1b6e05249cc6c992bb7b8478cc0ddc70c2a1453428285808

攻击第3步交易0xa945:

0xa945b1857630e730bd3fac6459c82dee44da45e35cfbbd6dfb7b42146e8dde41

受害者Memestake地址:

0x35c674c288577df3e9b5dafef945795b741c7810

代币KEANU地址:

0x106552c11272420aad5d7e94f8acab9095a6c952

代币Mfund地址:

0xddaddd4f73abc3a6552de43aba325f506232fa8a

0 0 投票数
Article Rating
订阅评论
提醒
guest
0 Comments
内联反馈
查看所有评论