UPP:慢霧：Lendf.Me被盜全過程分析及防御建議

編者按：本文來自慢霧科技，Odaily星球日報授權轉載。

據慢霧區情報，以太坊DeFi平臺Lendf.Me遭受重入漏洞攻擊。慢霧安全團隊在收到情報后隨即對此次攻擊事件展開分析，并快速定位了問題所在。據慢霧科技反洗錢(AML)系統初步統計分析，Lendf.Me被攻擊累計的損失約24,696,616美元，具體盜取的幣種及數額為：WETH:55159.02134,WBTC:9.01152,CHAI:77930.93433,HBTC:320.27714,HUSD:432162.90569,BUSD:480787.88767,PAX:587014.60367,TUSD:459794.38763,USDC:698916.40348,USDT:7180525.08156,USDx:510868.16067,imBTC:291.3471之后攻擊者不斷通過1inch.exchange、ParaSwap、Tokenlon等DEX平臺將盜取的幣兌換成ETH及其他代幣。以下是詳細分析過程：

慢霧：Uwerx遭受攻擊因為接收地址會多銷毀掉from地址轉賬金額1%的代幣:金色財經報道，Uwerx遭到攻擊，損失約174.78枚ETH，據慢霧分析，根本原因是當接收地址為 uniswapPoolAddress（0x01）時，將會多burn掉from地址的轉賬金額1%的代幣，因此攻擊者利用uniswapv2池的skim功能消耗大量WERX代幣，然后調用sync函數惡意抬高代幣價格，最后反向兌換手中剩余的WERX為ETH以獲得利潤。據MistTrack分析，黑客初始資金來自Tornadocash轉入的10 BNB，接著將10 BNB換成1.3 ETH，并通過Socket跨鏈到以太坊。目前，被盜資金仍停留在黑客地址0x605...Ce4。[2023/8/2 16:14:10]

攻擊細節

本次對Lendf.Me實施攻擊的攻擊者地址為0xa9bf70a420d364e923c74448d9d817d3f2a77822，攻擊者通過部署合約0x538359785a8d5ab1a741a0ba94f26a800759d91d對Lendf.Me進行攻擊。通過在Etherscan上查看攻擊者的其中一筆交易：https://etherscan.io/tx/0xae7d664bdfcc54220df4f18d339005c6faf6e62c9ca79c56387bc0389274363b

慢霧：Gate官方Twitter賬戶被盜用，謹慎互動:10月22日消息，安全團隊慢霧發文稱：加密平臺Gate官方Twitter賬戶被盜用，謹慎互動。半小時前，攻擊者利用該賬戶發文，誘導用戶進入虛假網站連接錢包。此外，慢霧科技創始人余弦在社交媒體上發文表示：注意下，Gate官方推特應該是被黑了，發送了釣魚信息，這個網址 g?te[.]com 是假的（之前談過的 Punycode 字符有關的釣魚域名），如果你去Claim會出現eth_sign這種簽名釣魚，可能導致ETH等相關資產被盜。[2022/10/22 16:35:14]

我們發現，攻擊者首先是存入了0.00021593枚imBTC，但是卻從Lendf.Me中成功提現了0.00043188枚imBTC，提現的數量幾乎是存入數量的翻倍。那么攻擊者是如何從短短的一筆交易中拿到翻倍的余額的呢？這需要我們深入分析交易中的每一個動作，看看究竟發生了什么。通過把該筆交易放到bloxy.info上查看，我們能知道完整的交易流程

慢霧：疑似Gemini相關地址在過去5小時內共轉出逾20萬枚ETH:金色財經消息，慢霧監測顯示，疑似加密交易所Gemini相關地址（0xea3ec2a08fee18ff4798c2d4725ded433d94151d）已在過去5小時內歸集并轉出逾20萬枚ETH（超3億美元）。[2022/7/19 2:22:08]

通過分析交易流程，我們不難發現攻擊者對Lendf.Me進行了兩次supply()函數的調用，但是這兩次調用都是獨立的，并不是在前一筆supply()函數中再次調用supply()函數。緊接著，在第二次supply()函數的調用過程中，攻擊者在他自己的合約中對Lendf.Me的withdraw()函數發起調用，最終提現。

慢霧：Cover協議被黑問題出在rewardWriteoff具體計算參數變化導致差值:2020年12月29日，慢霧安全團隊對整個Cover協議被攻擊流程進行了簡要分析。

1.在Cover協議的Blacksmith合約中，用戶可以通過deposit函數抵押BPT代幣；

2.攻擊者在第一次進行deposit-withdraw后將通過updatePool函數來更新池子，并使用accRewardsPerToken來記錄累計獎勵；

3.之后將通過_claimCoverRewards函數來分配獎勵并使用rewardWriteoff參數進行記錄；

4.在攻擊者第一次withdraw后還留有一小部分的BPT進行抵押；

5.此時攻擊者將第二次進行deposit，并通過claimRewards提取獎勵；

6.問題出在rewardWriteoff的具體計算，在攻擊者第二次進行deposit-claimRewards時取的Pool值定義為memory，此時memory中獲取的Pool是攻擊者第一次withdraw進行updatePool時更新的值；

7.由于memory中獲取的Pool值是舊的，其對應記錄的accRewardsPerToken也是舊的會賦值到miner；

8.之后再進行新的一次updatePool時，由于攻擊者在第一次進行withdraw后池子中的lpTotal已經變小，所以最后獲得的accRewardsPerToken將變大；

9.此時攻擊者被賦值的accRewardsPerToken是舊的是一個較小值，在進行rewardWriteoff計算時獲得的值也將偏小，但攻擊者在進行claimRewards時用的卻是池子更新后的accRewardsPerToken值；

10.因此在進行具體獎勵計算時由于這個新舊參數之前差值，會導致計算出一個偏大的數值；

11.所以最后在根據計算結果給攻擊者鑄造獎勵時就會額外鑄造出更多的COVER代幣，導致COVER代幣增發。具體accRewardsPerToken參數差值變化如圖所示。[2020/12/29 15:58:07]

動態 | 慢霧：2020年加密貨幣勒索蠕蟲已勒索到 8 筆比特幣:慢霧科技反洗錢(AML)系統監測：世界最早的知名加密貨幣勒索蠕蟲 WannaCry 還在網絡空間中茍延殘喘，通過對其三個傳播版本的行為分析，其中兩個最后一次勒索收到的比特幣分別是 2019-04-22 0.0584 枚，2019-09-01 0.03011781 枚，且 2019 年僅發生一次，另外一個 2020 還在活躍，2020 開始已經勒索收到 8 筆比特幣支付，但額度都很低 0.0001-0.0002 枚之間。這三個傳播版本第一次發生的比特幣收益都是在 2017-05-12，總收益比特幣 54.43334953 枚。雖然收益很少，但 WannaCry 可以被認為是加密貨幣歷史上勒索作惡的鼻主蠕蟲，其傳播核心是 2017-04-13 NSA 方程式組織被 ShdowBrokers(影子經紀人) 泄露第三批網絡軍火里的“永恒之藍”(EternalBlue)漏洞，其成功的全球影響力且匿名性為之后的一系列勒索蠕蟲（如 GandCrab）帶來了巨大促進。[2020/2/23]

在這里，我們不難分析出，攻擊者的withdraw()調用是發生在transferFrom函數中，也就是在Lendf.Me通過transferFrom調用用戶的tokensToSend()鉤子函數的時候調用的。很明顯，攻擊者通過supply()函數重入了Lendf.Me合約，造成了重入攻擊，那么具體的攻擊細節是怎樣的呢？我們接下來跟進Lendf.Me的合約代碼。代碼分析

Lendf.Me的supply()函數在進行了一系列的處理后，會調用一個doTransferIn函數，用于把用戶提供的幣存進合約，然后接下來會對market變量的一些信息進行賦值。回顧剛才說的攻擊流程，攻擊者是在第二次supply()函數中通過重入的方式調用了withdraw()函數提現，也就是說在第二次的supply()函數中，1590行后的操作在withdraw()之前并不會執行，在withdraw()執行完之后，1590行后的代碼才會繼續執行。這里的操作導致了攻擊者可提現余額變多。我們深入分析下supply()函數：

根據上圖，可以看到，在supply()函數的末尾，會對market和用戶的余額進行更新，在這之前，用戶的余額會在函數的開頭預先獲取好并保存在localResults.userSupplyCurrent，如下：

通過賦值給localResults變量的方式，用戶的轉入信息會先暫時保存在這個變量內，然后此時攻擊者執行withdraw()函數，我們看下withdraw()函數的代碼：

這里有兩個關鍵的地方:1、在函數的開頭，合約首先獲取了storage的market及supplyBalance變量。2、在withdraw()函數的末尾，存在同樣的邏輯對market用戶的余額信息(supplyBalance)進行了更新，更新值為扣除用戶的提現金額后的余額。按正常的提現邏輯而言，在withdraw()單獨執行的時候，用戶的余額會被扣除并正常更新，但是由于攻擊者將withdraw()嵌入在supply()中，在withdraw()函數更新了用戶余額(supplyBalance)后，接下來在supply()函數要執行的代碼，也就是1590行之后，用戶的余額會再被更新一次，而用于更新的值會是先前supply()函數開頭的保存在localResults中的用戶原先的存款加上攻擊者第一次調用supply()函數存款的值。在這樣的操作下，用戶的余額雖然在提現后雖然已經扣除了，但是接下來的supply()函數的邏輯會再次將用戶未扣除提現金額時的值覆蓋回去，導致攻擊者雖然執行了提現操作，但是余額不但沒有扣除，反而導致余額增加了。通過這樣的方式，攻擊者能以指數級別的數量提現，直至把Lendf.Me提空。防御建議

針對本次攻擊事件慢霧安全團隊建議：在關鍵的業務操作方法中加入鎖機制，如：OpenZeppelin的ReentrancyGuard開發合約的時候采用先更改本合約的變量，再進行外部調用的編寫風格項目上線前請優秀的第三方安全團隊進行全面的安全審計，盡可能的發現潛在的安全問題多個合約進行對接的時候也需要對多方合約進行代碼安全和業務安全的把關，全面考慮各種業務場景相結合下的安全問題合約盡可能的設置暫停開關，在出現“黑天鵝”事件的時候能夠及時發現并止損安全是動態的，各個項目方也需要及時捕獲可能與自身項目相關的威脅情報，及時排查潛在的安全風險附：OpenZeppelinReentrancyGuard

Tags：UPPSUPPLYPPLDynamic Supply TrackerSUPESupplyConAPPLE價格

Gate.io