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

撰文：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的結果都是一致的。

慢霧：Poly Network再次遭遇黑客攻擊，黑客已獲利價值超439萬美元的主流資產:金色財經報道，據慢霧區情報，Poly Network再次遭遇黑客攻擊。分析發現，主要黑客獲利地址為0xe0af…a599。根據MistTrack團隊追蹤溯源分析，ETH鏈第一筆手續費為Tornado Cash: 1 ETH，BSC鏈手續費來源為Kucoin和ChangeNOW，Polygon鏈手續費來源為FixedFloat。黑客的使用平臺痕跡有Kucoin、FixedFloat、ChangeNOW、Tornado Cash、Uniswap、PancakeSwap、OpenOcean、Wing等。

截止目前，部分被盜Token （sUSD、RFuel、COOK等）被黑客通過Uniswap和PancakeSwap兌換成價值122萬美元的主流資產，剩余被盜資金被分散到多條鏈60多個地址中，暫未進一步轉移，全部黑客地址已被錄入慢霧AML惡意地址庫。[2023/7/2 22:13:22]

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

慢霧：pGALA合約黑客已獲利430萬美元:11月4日消息，安全團隊慢霧在推特上表示，pGALA合約黑客已將大部分GALA兌換成13,000枚BNB，獲利超430萬美元，該地址仍有450億枚Gala，但不太可能兌現，因為資金池基本已耗盡。此外，黑客的初始資金來自幾個幣安賬戶。

今日早些時候消息，一個BNB Chain上地址在BNB Chain上地址憑空鑄造了超10億美元的pGALA代幣，并通過在PancakeSwap上售出獲利。pNetwork表示此為跨鏈橋配置錯誤所致，GALA跨鏈橋已暫停，請用戶不要在BNB Chain上DEX中交易pGALA。[2022/11/4 12:16:04]

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

處理方式分析：瀏覽器js

GoPlus與慢霧提出合約可限時授權EIP提案，以降低遺留授權導致的被盜風險:10月6日消息，安全機構GoPlus與慢霧提出可限時授權的EIP標準，以降低遺留授權導致的被盜風險。標準中提到，包括TransitSwap事件在內，反復發生的資產盜竊是由于用戶對合約的過度授權造成的，如果合約出錯，所有沒有召回授權的用戶都會受到攻擊。

GoPlus與慢霧提出的解決方案可以為ERC-20Token設置Approv，以在默認時間段內自動撤回授權，或者使用自定義的時間限制來召回授權并及時避免風險，并提交了一份新的EIP，目前正在由以太坊研究部門審查。[2022/10/6 18:41:11]

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

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

慢霧: 警惕比特幣RBF風險:據BitMEX消息，比特幣于區塊高度666833出現陳腐區塊，并產生了一筆 0.00062063 BTC 的雙花交易。根據 BitMEX提供的交易內容來看，雙花的兩筆交易的nSequence字段的值都小于0xffffffff -1。慢霧安全團隊初步認為此次雙花交易有可能是比特幣中的RBF交易。[2021/1/20 16:38:01]

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

分析 | 慢霧分析 MimbleWimble攻擊思路：本質上是一種中間人攻擊思路:慢霧關于Dragonfly Capital研究員披露MimbleWimble隱私缺陷的一些補充觀點：

1. 攻擊思路本質上也是一種中間人攻擊思路：通過需要付出一些成本的“嗅探節點”技術監聽MimbleWimble的聚合前的交易流量，以此分析發現from/to兩個關鍵隱私因子的值，雖然不知道 value(金額)，但有能力知道許多交易的來源與去向，但不是完全；

2. 這種“嗅探”思路類似美國等國家針對暗網Tor網絡的溯源思路，通過部署或控制的足夠多的節點來抓取Tor網絡里的IP連接。但針對MimbleWimble網絡，由于節點P2P通信特點，倒是不需要部署或控制許多節點；

3. MimbleWimble協議需要進化以應對這種“嗅探”技術，但我們都知道 Grin、Beam 不僅 MimbleWimble 協議，隱私策略在上層也有加強空間；

4. 隱私幣在鏈上本質要解決的核心問題是：from/to/value 的隱私問題，但隱私不僅是鏈上的，還有鏈下部分，比如IP等隱私，這是所有隱私幣都需要面對的問題。雖然MimbleWimble 這個純鏈上的隱私技術不完美，這是必然的，完美是不存在的，不僅是MimbleWimble；

5. 隱私是一個工程級問題，Dragonfly Capital研究員的對抗思路也是工程級的，在工程級對抗上，不存在完美的隱私幣；

5. 期待隱私幣的一系列進化，在超級對抗中能進化的都是好隱私幣。[2019/11/19]

接下來分析如何將轉換后的字符填充進入的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：FERBUFFUFFMBLfer幣多少美金BUFFS價格Buffed KishuMBLOX幣

FTX