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

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

慢霧xToken被黑事件分析：兩個合約分別遭受“假幣”攻擊和預言機操控攻擊:據慢霧區消息，以太坊 DeFi 項目 xToken 遭受攻擊，損失近 2500 萬美元，慢霧安全團隊第一時間介入分析，結合官方事后發布的事故分析，我們將以通俗易懂的簡訊形式分享給大家。

本次被黑的兩個模塊分別是 xToken 中的 xBNTa 合約和 xSNXa 合約。兩個合約分別遭受了“假幣”攻擊和預言機操控攻擊。

一）xBNTa 合約攻擊分析

1. xBNTa 合約存在一個 mint 函數，允許用戶使用 ETH 兌換 BNT，使用的是 Bancor Netowrk 進行兌換，并根據 Bancor Network 返回的兌換數量進行鑄幣。

2. 在 mint 函數中存在一個 path 變量，用于在 Bancor Network 中進行 ETH 到 BNT 的兌換，但是 path 這個值是用戶傳入并可以操控的

3. 攻擊者傳入一個偽造的 path，使 xBNTa 合約使用攻擊者傳入的 path 來進行代幣兌換，達到使用其他交易對來進行鑄幣的目的。繞過了合約本身必須使用 ETH/BNT 交易對進行兌換的限制，進而達到任意鑄幣的目的。

二）xSNXa 合約攻擊分析

1. xSNXa 合約存在一個 mint 函數，允許用戶使用 ETH 兌換 xSNX，使用的是 Kyber Network 的聚合器進行兌換。

2. 攻擊者可以通過閃電貸 Uniswap 中 ETH/SNX 交易對的價格進行操控，擾亂 SNX/ETH 交易對的報價，進而擾亂 Kyber Network 的報價。從而影響 xSNXa 合約的價格獲取

3. 攻擊者使用操控后的價格進行鑄幣，從而達到攻擊目的。

總結：本次 xToken 項目被攻擊充分展現了 DeFi 世界的復雜性，其中針對 xSNXa 的攻擊更是閃電貸操控價格的慣用手法。慢霧安全團隊建議 DeFi 項目開發團隊在進行 DeFi 項目開發的時候要做好參數校驗，同時在獲取價格的地方需要防止預言機操控攻擊，可使用 Uniswap 和 ChainLink 的預言機進行價格獲取，并經過專業的安全團隊進行審計， 保護財產安全。詳情見官網。[2021/5/13 21:57:48]

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

慢霧：Polkatrain 薅羊毛事故簡析:據慢霧區消息，波卡生態IDO平臺Polkatrain于今早發生事故，慢霧安全團隊第一時間介入分析，并定位到了具體問題。本次出現問題的合約為Polkatrain項目的POLT_LBP合約，該合約有一個swap函數，并存在一個返傭機制，當用戶通過swap函數購買PLOT代幣的時候獲得一定量的返傭，該筆返傭會通過合約里的_update函數調用transferFrom的形式轉發送給用戶。由于_update函數沒有設置一個池子的最多的返傭數量，也未在返傭的時候判斷總返傭金是否用完了，導致惡意的套利者可通過不斷調用swap函數進行代幣兌換來薅取合約的返傭獎勵。慢霧安全團隊提醒DApp項目方在設計AMM兌換機制的時候需充分考慮項目的業務場景及其經濟模型，防止意外情況發生。[2021/4/5 19:46:39]

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

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

處理方式分析：瀏覽器js

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

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

聲音 | 慢霧科技余弦：門羅是暗網:5月16日杭州區塊鏈周圓桌會議上，慢霧科技余弦談到暗網和加密貨幣關系時表示大家知道暗網最支持的幣是什么？不是門羅幣，是比特幣，還支持來特幣、以太坊以及谷歌幣、門羅，但我為什么說門羅是暗網？第一，B網，它不僅在支付上有很大的生態。其實在支付上，第一是比特，第二是門羅。為什么說門羅是暗網之王？原因是暗網里面有很多做蠕蟲挖礦，就是入侵別人的IOT設備、服務器，各種挖礦的地下行為，都在挖，主要挖的幣種就是門羅幣。把這些全部加起來，我們覺得門羅在整個隱私自由的世界。[2019/5/16]

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

動態 | 慢霧區發布XRP假充值漏洞預警:據慢霧區披露，瑞波幣(XRP)存在假充值漏洞（類似于之前披露的 USDT 及以太坊代幣假充值漏洞），已有真實攻擊在發生，一旦攻擊成功，會非常嚴重。[2018/7/30]

接下來分析如何將轉換后的字符填充進入的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：FERUFFBUFFETHiBuffer Tokenluffy幣怎么了buff幣是什么YFETH幣

Filecoin