EOS:慢霧：破解造成 BetDice 項目恐慌的交易回滾攻擊手法_BET

2018年12月19日，眾多游戲類DApp遭遇交易回滾攻擊，其中包括BetDice，EOSMax，ToBet等。按當時18元人民幣的價格計算，損失超過500萬人民幣。期間BetDice通過鏈金術平臺發出多次公告,一度造成恐慌。

與此同時，慢霧安全團隊對交易所和中心化錢包給出了暫時性的方案。此刻，攻擊手法依舊是一個謎團。那么，攻擊手段究竟是怎樣的呢？在進行攻擊回顧之前，需要先了解一點技術背景。

技術背景

1、我們知道EOS采用的共識算法是DPOS算法，采用的是21個超級節點輪流出塊的方式。除了21個超級節點外的其他全節點，并沒有出塊的權限。起到的作用是將收到的交易廣播出去，然后超級節點將其進行打包。

說到這里，很容易看出，如果一筆交易是發給除了超級節點外的其他全節點，這筆交易會經歷兩個過程。首先，這筆交易先被全節點接收，然后交易再被節點廣播出去進行打包。而一筆交易是需要超級節點中超過2/31的節點進行確認之后才是不可回滾的，也就是不可逆的。

這個過程大概需要3分鐘左右，也就是說，交易發到除了超級節點外的全節點的時候，由于全節點沒有打包的權利，此時此刻交易仍然處于可逆狀態。這是一個核心關鍵點。

慢霧：發現BNB Chain上一惡意合約地址，建議用戶快速驗證并撤銷異常授權:8月20日消息，慢霧在推特發文提醒：請用戶檢查是否已將資產授權到BNB Chain上的一惡意合約地址：0x75117c9158f53998ce8689B64509EFf4FA10AD80。

該惡意合約尚未通過開源進行驗證，但反編譯顯示其存在針對授權資產的任意轉賬后門。這種類型的后門讓用戶錢包在很長一段時間內保持正常使用，但當某天轉移一筆金額稍大的資產時，它會突然被盜，而鏈上不會顯示任何最近的異常授權。

用戶可使用Revoke.cash和Rabby Wallet進行快速驗證并撤銷異常授權。以下是與上述合約相關的惡意地址：0xE2A178C2C5C4920C1b2B947A35edDb4f8EcBb7dD、0xB88457b62491CBcEc42203672cFcb4269d64c7e。請用戶保持警惕。[2023/8/20 18:11:40]

2、每一個bp，都可以在自己的節點的config.ini文件內進行黑名單的配置，在黑名單中的帳號是不能進行交易的，也就是說無論怎樣，黑名單的交易都會被回滾。

慢霧：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]

黑名單配置路徑：

MacOS：

~/Library/ApplicationSupport/eosio/nodeos/config/config.ini

Linux:

~/.local/share/eosio/nodeos/config/config.ini

配置方法：將config.ini文件內的actor-blacklist填入黑名單帳號，如下圖中，將attacker這個帳號作為黑名單帳號。

慢霧：2021年上半年共發生78起區塊鏈安全事件，總損失金額超17億美元:據慢霧區塊鏈被黑事件檔案庫統計，2021年上半年，整個區塊鏈生態共發生78起較為著名的安全事件，涉及DeFi安全50起、錢包安全2起，公鏈安全3起，交易所安全6起，其他安全相關17起，其中以太坊上27起，幣安智能鏈(BSC)上22起，Polygon上2起，火幣生態鏈(HECO)、波卡生態、EOS上各1起，總損失金額超17億美元(按事件發生時幣價計算)。

經慢霧AML對涉事資金追蹤分析發現，約60%的資金被攻擊者轉入混幣平臺，約30%的資金被轉入交易所。慢霧安全團隊在此建議，用戶應增強安全意識，提高警惕，選擇經過安全審計的可靠項目參與；項目方應不斷提升自身的安全系數，通過專業安全審計機構的審計后才上線，避免損失；各交易所應加大反洗錢監管力度，進一步打擊利用加密資產交易的洗錢等違規行為。[2021/7/1 0:20:42]

了解了以上的知識點之后，我們就可以進行整個攻擊事件的回顧了。

攻擊回顧

跟蹤攻擊者的其中一個攻擊帳號，發現帳號合約內只有一個transfer函數

慢霧：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]

同時，我們可以通過復盤這個帳號的所有交易記錄發現，這個帳號只有開獎記錄，而沒有下注記錄，看起來就好像項目方故意給這個帳號進行開獎一樣。然而事實上并非如此。那為什么會出現這樣的情況呢？這就需要上面的技術背景的知識了。以下是詳細的攻擊手法：

動態 | 慢霧：巨鯨被盜2.6億元資產，或因Blockchain.info安全體系存在缺陷:針對加密巨鯨賬戶（zhoujianfu）被盜價值2.6億元的BTC和BCH，慢霧安全團隊目前得到的推測如下：該大戶私鑰自己可以控制，他在Reddit上發了BTC簽名，已驗證是對的，且猜測是使用了一款很知名的去中心化錢包服務，而且這種去中心化錢包居然還需要SIM卡認證，也就是說有用戶系統，可以開啟基于SIM卡的短信雙因素認證，猜測可能是Blockchain.info，因為它吻合這些特征，且歷史上慢霧安全團隊就收到幾起Blockchain.info用戶被盜幣的威脅情報，Blockchain.info的安全體系做得并不足夠好。目前慢霧正在積極跟進更多細節，包括與該大戶直接聯系以及盡力提供可能需求的幫助。[2020/2/22]

1、首先：攻擊者調用非黑名單合約的transfer函數，函數內部有一個inlineaction進行下注，from填寫的是攻擊者控制的非黑名單合約帳號，to填寫的是游戲合約帳號。這時，攻擊者發送交易是發向游戲合約自己的全節點服務器。使用的是黑名單帳號進行。

2、游戲節點讀取到了這筆交易，立刻進行開獎，如果中獎，將對攻擊者控制的非黑名單帳號發送EOS。

3、在經歷了一個1，2兩個操作之后。理論上攻擊者控制的非黑名單帳號是進行了余額扣除。然后進行正常的開獎邏輯。到這里之前，一切都是正常的。也許有讀者會問，為什么配置了黑名單，交易還能正常發起？原因是這個黑名單生效范圍是在bp內，普通的全節點的config.ini內是沒有黑名單的配置的。所以攻擊者依然可以發起交易。

4、到此為止，攻擊正式開始，也到了最關鍵的地方，由于項目方節點在收到下注交易的時候已經立馬完成了開獎邏輯，而且采用的是線下開獎的模式，即下注交易和開獎交易是兩筆不同的交易。但是，這兩筆交易僅僅是在項目方的節點內完成，仍然是可逆的。當項目方節點向bp廣播這兩筆交易的時候，由于第一筆下注交易的發起者在bp節點的黑名單內，這一筆交易將被回滾，也就是打包失敗，而開獎交易的發起者是項目方，不在黑名單之內，會被正常打包。因此兩筆交易中的第一筆下注交易一定會被回滾，而開獎交易依舊會被打包，這也就解釋了為什么只有開獎記錄，而沒有下注記錄。因為下注記錄都被回滾了。

整個過程可以參考下面的圖：

攻擊復現

本次攻擊復現參考EOSLIVE錢包團隊的文章：https://eos.live/detail/19255

1、環境準備

本地準備兩個節點，一個出塊節點，一個同步節點，出塊節點用于模擬真實bp，而同步節點則用于模擬項目方，其中出塊節點需要開啟history插件，方便后續的debug，并且把attacker加入節點黑名單。方便后續的debug。打包節點則需要開啟自動開獎插件,自動開獎插件配置詳見：

https://github.com/superoneio/security

本次復現用到的代碼：

https://github.com/superoneio/security

本地多節點配置方法官方參考：

https://developers.eos.io/eosio-nodeos/docs/local-multi-node-testnet

三個測試帳號，分別是tobetioadmin,tobetiologs1,attackproxy1，分別為項目方帳號，項目方log帳號，和攻擊代理帳號，其中tobetioadmin部署tobet游戲合約，tobetiologs1部署logs合約，attackproxy1部署attack合約。注意除了攻擊代理帳號外的其他兩個帳號不要改為其他帳號，如果改為其他帳號需要對自動開獎插件進行修改，自動開獎插件是攔截tobetioadmin這個帳號的。

附上我的雙節點的配置：

其中nodeos_main為出塊節點，nodeos_second為同步節點。

2、啟動節點

看到以上信息則代表dice_plugin配置成功

3、首先對正常的邏輯進行測試。

使用attackproxy1對tobetioadmin帳號進行正常的轉賬交易

可以看到，攻擊代理合約進行了正常的轉賬。

4、開始攻擊，使用黑名單帳號調用攻擊代理合約，向項目方合約發起攻擊。查詢初始余額

為保證攻擊成功，連續向項目方發起4起攻擊

再次查詢余額

查詢attacker帳號記錄

可見，并沒有attacker對attackproxy1的調用記錄，最后兩條記錄是我測試直接使用黑名單向tobetadmin發起攻擊的時候留下的記錄。與本次測試無關。但是通過查詢發現，本地記錄和鏈上記錄是相吻合的，即無下注記錄。

查詢attackproxy1的帳號記錄

可以看到的是，這個也與鏈上記錄吻合，只有開獎記錄，就像tobetadmio故意給attackproxy1開獎一般。

通過以上的復現及和鏈上記錄的對比，我們可以證明上文說的攻擊手法，就是黑客本次進行攻擊的手法，采用的就是使用黑名單進行回滾的操作。

防御建議

1、針對DApp的防御建議

節點開啟readonly模式，防止節點服務器上出現未確認的塊建立開獎依賴，如訂單依賴，開獎的時候判斷訂單是否存在，就算在節點服務器上開獎成功，由于在bp上下注訂單被回滾，所以相應的開獎記錄也會被回滾。

2、針對交易所和中心化錢包的防御建議

慢霧安全團隊建議EOS交易所及中心化錢包在通過RPC接口get_actions查詢熱錢包充值記錄時，應檢查充值transaction所在的block_num是否小于last_irreversible_block，如果block_num大于last_irreversible_block則表示該區塊仍然是可逆的，存在「假充值」風險。

本文來源于非小號媒體平臺：

慢霧科技

現已在非小號資訊平臺發布1篇作品，

非小號開放平臺歡迎幣圈作者入駐

入駐指南：

/apply_guide/

本文網址：

/news/3627097.html

免責聲明：

1.資訊內容不構成投資建議，投資者應獨立決策并自行承擔風險

2.本文版權歸屬原作所有，僅代表作者本人觀點，不代表非小號的觀點或立場

上一篇：

再提Mt.Gox，糟糕的「里程碑事件」正提升區塊鏈世界的安全意識

下一篇：

復盤數十萬EOS被盜過程，背后是其架構設計缺陷？

Tags：EOSSWAPACKBETleos幣雷石鏈ESWAPV2價格EOSJacksBETA價格

比特幣價格今日行情