作者：yudan@慢霧安全團隊
公眾號：慢霧科技

事件背景：

據慢霧區情報，今日凌晨，攻擊 BetDice、ToBet 等游戲的黑客團伙再次對 LuckyMe、GameBet 發動攻擊，造成數千 EOS 的損失。

經過慢霧安全團隊的分析，此次黑客采用的手法有別于上一次的攻擊。本次的攻擊為針對項目方的重放攻擊。

攻擊回顧：

據慢霧安全團隊威脅情報分析，截止北京時間上午8時，攻擊者ultnavrzhium此次攻擊共投入金額3773.95 EOS，收入6906.6 EOS，共獲利3132.65 EOS。

攻擊手法：

本次攻擊手法與上一篇文章有所不同。但依然利用到了黑名單的手法。以下是攻擊詳細過程。

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

(2)第二步，游戲節點讀取到了這筆交易，立刻進行開獎，如果中獎，將對攻擊者控制的非黑名單帳號發送 EOS。到這里和上一篇黑名單篇的第一步和第二步都是一樣的。

(3)第三步，因為項目方開獎和交易id綁定，所以按照上一篇文章的說法,下注交易和開獎交易都會被回滾。即使項目方給攻擊者開獎了，到了bp節點的時候，由于查詢不到開獎id，開獎交易也會失敗。所以為什么還是能攻擊成功呢？答案在第四步

(4)上一篇文章說到，在攻擊者攻擊的時候，所有的邏輯都是在項目方的節點完成的，根據這一點，攻擊者就可以在項目方節點廣播交易時監聽到開獎結果，如果這筆下注是中的，立馬以同樣的參數（如種子）使用攻擊者控制的同一合約帳號發起相同的交易，actor為合約帳號本身，即可成功中獎。

本次攻擊可以參考下面的圖：

防御建議：

  1. 節點開啟 read only 模式，防止節點服務器上出現未確認的塊
  2. 建立開獎依賴，如訂單依賴，開獎的時候判斷訂單是否存在，就算在節點服務器上開獎成功，由于在 bp 上下注訂單被回滾，所以相應的開獎記錄也會被回滾。
  3. 項目方在玩家下注的時候校驗交易中的actor和from是否是同一帳號。
  4. 接入慢霧安全團隊孵化的DApp防火墻--FireWallX(體驗地址：https://firewallx.io/console/index.html)，本次LuckyMe攻擊者帳號（ultnavrzhium）在LuckyMe被攻擊前已在防火墻合約監控名單中。

查詢地址：https://www.eosx.io/account/firewall.x?mode=contract&sub=tables&table=contractlst&lowerBound=&upperBound=&limit=10000

參考鏈接：

慢霧安全團隊分析文章：https://mp.weixin.qq.com/s/WyZ4j3O68qfN5IOvjx3MOg

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.jmbmsq.com/776/