表裏不一：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. 第1步（准備），首先攻擊者創建了兩個合約並進行初始化，其中合約一為表現正常的投資合約，攻擊者通過合約一往Memestake存入約2,049B KEANU ，為步驟3獲利大量MFUND獎勵做好鋪墊。合約二為操縱Memestake的獎勵計算的合約，先進行了相關token的approve操作。

2. 第2步（操縱），攻擊者先從uniswapV2中flash loan大量的KEANU代幣，然後通過合約二往Memestake中多次deposit 和withdraw大量KEANU，導致Memestake被迫大量交易KEANU。由於KEANU是一種通縮代幣，每次交易會燒掉2%的交易額，導致用戶真正存入Memestake的量比登記的user.amount更小，取出時又是按照user.amount轉給用戶（詳見代碼分析），導致Memestake池子中KEANU的代幣持有量不斷減少，最終為1e-07。如下圖所示，涉及交易為0x00ed，交易截圖未完全，請自行根據交易查看。

3. 

4. 第3步（獲利），攻擊者首先通過合約二調用了Memestake.updatePool()函數，修改了KEANU所在池子的accMfundPerShare，由於該值依賴於池子所持有的KEANU的代幣量，而這在第二步中被操縱了（具體公式見下方代碼分析）。這使得合約二在接下來withdraw的時候可以獲得遠超正常值的Mfund（約61M）這種token作為獎勵。第3步發生於交易0xa945中，同時攻擊者开始將部分獲得的MFund換成WETH等代幣。

5. 

6. 第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

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。