慢霧深度解析 Bitfinex 天價手續費轉賬：BUG+顯示錯誤「釀成大錯」_ETH

撰文：Thinking@慢霧安全團隊

事件背景

分析源自一筆轉賬金額10wUSDT，手續費卻高達7,676枚ETH的天價手續費交易。https://etherscan

將int轉成Hexhttps://github

判斷是否可以被2整除，如果不行需要在字符開頭添加一個0，這里主要是為了能夠成功的將數據2個1組寫入到buffer。https://github

if(a

returna;}

以出錯的示例數據：33974229950.550003進行分析，經過intToBuffer函數中的intToHex和padToEven處理后得到7e9059bbe.8ccd，這部分瀏覽器js和nodejs的結果都是一致的。

慢霧：仍有大部分錢包支持eth_sign，僅少部分錢包提供安全風險警告:金色財經報道，在加密貨幣NFT板塊，越來越多的釣魚網站濫用 eth_sign 簽名功能來進行盲簽欺詐，提醒或禁用這種低級的簽名方法對于保護用戶安全是至關重要的，不少 Web3 錢包已經采取相關措施來對這種危險的簽名方法進行安全提示和限制。仍有一大部分加密錢包支持 eth_sign，其中少部分錢包提供 eth_sign 安全風險警告。如果用戶仍想要使用 eth_sign，他們可以選擇支持該功能的加密錢包。但是，用戶在使用這些錢包時需要特別注意安全警告，以確保其交易的安全性。[2023/5/11 14:57:14]

不一致的地方是在newBuffer的操作：

newBuffer(padToEven(hex.slice(2)),'hex');

慢霧：Nomad事件中仍有超過9500萬美元被盜資金留在3個地址中:8月2日消息，慢霧監測顯示，Nomad攻擊事件中仍有超過9500萬美元的被盜資金留在3個地址中。其中0xB5C55f76f90Cc528B2609109Ca14d8d84593590E中仍有1084枚ETH、120萬枚DAI、103枚WBTC等約800萬美元的加密資產，該地址也負責將1萬枚WETH轉移到另一地址以及將其他USDC轉移；第二個地址0x56D8B635A7C88Fd1104D23d632AF40c1C3Aac4e3目前仍有1.28萬枚ETH、1.02萬枚WETH、80萬DAI等約4700萬美元的加密資產；第三個地址0xBF293D5138a2a1BA407B43672643434C43827179在收到3866.6萬USDC后兌換為了DAI，目前有約3970萬美元的加密資產。

目前慢霧經過梳理后，無法將地址3與其他兩個地址連接起來，但這些攻擊具有相同的模式。[2022/8/2 2:53:04]

處理方式分析：瀏覽器js

慢霧：Inverse Finance遭遇閃電貸攻擊簡析:據慢霧安全團隊鏈上情報，Inverse Finance遭遇閃電貸攻擊,損失53.2445WBTC和99,976.29USDT。慢霧安全團隊以簡訊的形式將攻擊原理分享如下：

1.攻擊者先從AAVE閃電貸借出27,000WBTC,然后存225WBTC到CurveUSDT-WETH-WBTC的池子獲得5,375.5個crv3crypto和4,906.7yvCurve-3Crypto,隨后攻擊者把獲得的2個憑證存入Inverse Finance獲得245,337.73個存款憑證anYvCrv3Crypto。

2.接下來攻擊者在CurveUSDT-WETH-WBTC的池子進行了一次swap,用26,775個WBTC兌換出了75,403,376.18USDT,由于anYvCrv3Crypto的存款憑證使用的價格計算合約除了采用Chainlink的喂價之外還會根據CurveUSDT-WETH-WBTC的池子的WBTC,WETH,USDT的實時余額變化進行計算所以在攻擊者進行swap之后anYvCrv3Crypto的價格被拉高從而導致攻擊者可以從合約中借出超額的10,133,949.1個DOLA。

3.借貸完DOLA之后攻擊者在把第二步獲取的75,403,376.18USDT再次swap成26,626.4個WBTC,攻擊者在把10,133,949.1DOLAswap成9,881,355個3crv,之后攻擊者通過移除3crv的流動性獲得10,099,976.2個USDT。

4.最后攻擊者把去除流動性的10,000,000個USDTswap成451.0個WBT,歸還閃電貸獲利離場。

針對該事件，慢霧給出以下防范建議：本次攻擊的原因主要在于使用了不安全的預言機來計算LP價格，慢霧安全團隊建議可以參考Alpha Finance關于獲取公平LP價格的方法。[2022/6/16 4:32:58]

通過webpack打包好js文件并對文件進行引用，然后在瀏覽器上進行調試分析。

慢霧：BSC項目Value DeFi vSwap 模塊被黑簡析:據慢霧區情報，幣安智能鏈項目 Value DeFi 的 vSwap 模塊被黑，慢霧安全團隊第一時間介入分析，并將結果以簡訊的形式分享，供大家參考：

1. 攻擊者首先使用 0.05 枚 WBNB 通過 vSwap 合約兌換出 vBSWAP 代幣；

2. 攻擊者在兌換的同時也進行閃電貸操作，因此 vSwap 合約會將兌換的 vBSWAP 代幣與閃電貸借出的 WBNB 轉給攻擊者；

3. 而在完成整個兌換流程并更新池子中代幣數量前，會根據池子的 tokenWeight0 參數是否為 50 來選擇不同的算法來檢查池子中的代幣數量是否符合預期；

4. 由于 vSwap 合約的 tokenWeight0 參數設置為 70，因此將會采用第二種算法對池子中的代幣數量進行檢查；

5. 而漏洞的關鍵點就在于采用第二種算法進行檢查時，可以通過特殊構造的數據來使檢查通過；

6. 第二種算法是通過調用 formula 合約的 ensureConstantValue 函數并傳入池子中緩存的代幣數量與實時的代幣數量進行檢查的；

7. 在通過對此算法進行具體分析調試后我們可以發現，在使用 WBNB 兌換最小單位(即 0.000000000000000001) vBSWAP 時，池子中緩存的 WBNB 值與實時的值之間允許有一個巨大的波動范圍，在此范圍內此算法檢查都將通過；

8. 因此攻擊者可以轉入 WBNB 進行最小單位的 vBSWAP 代幣兌換的同時，將池子中的大量 WBNB 代幣通過閃電貸的方式借出，由于算法問題，在不歸還閃電貸的情況下仍可以通過 vSwap 的檢查；

9. 攻擊者只需要在所有的 vSwap 池子中，不斷的重復此過程，即可將池子中的流動性盜走完成獲利。詳情見原文鏈接。[2021/5/8 21:37:37]

首先輸入的示例字符33974229950.550003會進入到intToBuffer的函數中進行處理。

突發 | 慢霧區發布以太坊代幣“假充值”漏洞攻擊預警:慢霧區發布以太坊代幣“假充值”漏洞攻擊預警，稱相關交易所、中心化錢包、代幣合約需要特別警惕，盡快自查以太坊相關代幣的充值是否存在異常。此次受影響的主要是以太坊上基于ERC20、ERC721、ERC223等標準發行的代幣，已經發現有交易所及中心化錢包遭受此攻擊。這次攻擊事件的披露前后相關時間線大致如下：2018/6/28 USDT “假充值”漏洞攻擊事件披露；2018/7/1 開始分析知名公鏈是否存在類似問題；2018/7/7 捕獲并確認以太坊相關代幣“假充值”漏洞攻擊事件；2018/7/8 分析此次影響可能會大于 USDT “假充值”漏洞攻擊事件，并迅速通知相關客戶及慢霧區伙伴；2018/7/9 發出第一次預警。計劃：2018/7/11 不出意外，細節報告會正式公開。[2018/7/9]

同步分析intToBuffer的處理過程，這部分和」關鍵代碼分析「部分的代碼邏輯是一樣的，處理轉換部分得到的結果是7e9059bbe.8ccd。

接下來分析如何將轉換后的字符填充進入的buffer中，通過這步可以得到buffer的內容是126,144,89,187,14,140,205對應的是7e,90,59,bb,e,8c,cd。

>0x7e->126>0x90->144>0x59->89>0xbb->187>0xe->14>0x8c->140>0xcd->205

這里發現e.這部分的小數點消失了，于是開始解小數點消失之迷，追蹤到hexWrite這個函數，這個函數會將得到的數據2個一組進行切分。然后用了parseInt對切分后的數據進行解析。

然而parseInt('e.',16)->14===parseInt('e',16)->14消失的小數點被parseInt吃掉了，導致最終寫入到buffer中的數據發生了錯誤，寫入buffer的值是7e9059bbe8ccd。

處理方式分析：nodejs

由于瀏覽器上出問題的是7_**__**_e9059bbe.8ccd在寫入buffer的時候小數點被parseInt吃掉了導致數據出錯，但是經過分析，node的數據也是錯誤的，且產生錯誤的原因是和瀏覽器的不一樣。

首先我們先看下如下的示例：

node三組不同的數據填充到buffer得到的結果居然是一樣的，經過分析node的buffer有個小特性，就是2個一組切分后的數據，如果沒法正常通過hex解析的，就會把那一組數據以及之后的數據都不處理了，直接返回前面可以被正常處理的那部分數據。可以理解為被截斷了。這部分可以參考node底層的buffer中node_buffer.cc中的代碼邏輯。

>newBuffer('7e9059bbe','hex')>newBuffer('7e9059bbe.8ccd','hex')>newBuffer('7e9059bb','hex')

執行結果的比較

node由于會將原始數據7e9059bbe.8ccd中的e.及之后的數據進行截斷，所以最終錯誤的值是7e9059bb，相比正確的值07e9059bbe小。

node的執行結果：

瀏覽器由于會將原始數據7e9059bbe.8ccd中的.吃掉，所以最終錯誤的值是7e9059bbe8ccd，相比正確的值07e9059bbe大很多。

瀏覽器的執行結果：

問題的原因

ethjs-util的intToBuffer函數不支持浮點型的數據，且在這個函數中沒有判斷傳入的變量類型，來確保變量類型是預期內的。由于ethereumjs的toBuffer引用了ethjs-util的intToBuffer進行處理，也沒有對數據進行檢查。導致了這次事件的發生，所幸最終善良的礦工歸還了「天價手續費7626ETH」。

吸取的教訓

從第三方的庫的角度來看，在編碼過程中應該要遵循可靠的安全的編碼規范，在函數的開頭要對傳入的數據進行合法性的檢查，確保數據和代碼邏輯是按照預期內執行。

從庫的使用者的角度來看，使用者應該要自行閱讀第三方庫的開發文檔和對接文檔，并且也要對代碼中接入第三方庫的邏輯進行測試，通過構造大量的數據進行測試，確保業務上能夠正常按照期望執行，保證高標準的測試用例的覆蓋率。

參考資料:https://github.com/ethereumjs/ethereumjs-monorepo/issues/1497https://blog.deversifi.com/23-7-million-dollar-ethereum-transaction-fee-post-mortem/https://www.chainnews.com/news/611706276133.htm

Tags：ETHFERUFFBUFFYFETH價格REEFERRUFFBUFFDOGE價格

FTX