header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
掃碼下載APP
Partnered With:

Fairyproof分析:一起三明治交易機器人被攻擊案例

閱讀本文需 9 分鐘
攻擊原因疑似為函數調用權限驗證不充分

原文來源:Fairyproof


三明治機器人交易是區塊鏈生態的日常交易中非常普遍的交易行為。通過機器人進行交易不僅能極大地提高交易效率,還能盡快發現交易中存在的套利機會。


安全的機器人交易當然能達到上述目的,可不安全的機器人交易則有可能「偷雞不成反蝕把米」。 UTC 時間 8 月 29 日 06:04:39,BNB Chain 鏈上便發生了一起三明治交易機器人被攻擊的案例。


在該起案例中被攻擊的交易機器人總共損失了207 個WBNB、184900 個BSC-USD 和158900 個BUSD ,總資產價值約39 萬美元。


Fairyproof 在第一時間對該事件進行了分析,發現攻擊原因疑似為函數調用權限驗證不充分。


通常在DEX(去中心化交易平台)的鏈上交易中,為了節省gas,交易機器人會直接和交易對進行交互,而不通過DEX 的Router 合約。在基於Uniswap 交易邏輯實現的DEX 中,其交易對為先借後還,即調用交易者的特定回調函數(在本例中為pancakeV3SwapCallback)來通知交易者代幣已經借出,需要交易者進行相關操作以歸還借出的代幣。


因此,在交易合約中必須驗證回調函數pancakeV3SwapCallback 的調用者(msg.sender)為真正的交易對和交易的發起者(tx.origin)權限。由於 msg.sender 的驗證相對複雜(有時要考慮兼容 Uniswap V2 導致驗證邏輯複雜),因此大多數合約只驗證了 tx.origin。


通常這麼做是沒有問題的。然而如果交易的某一步涉及到了惡意合約(在本例中就是攻擊代幣合約),則會發生風險,因為惡意合約調用 pancakeV3SwapCallback 時,tx.origin 是可以通過權限驗證的。


在本次事件中,正是由於未驗證msg.sender 是否是pancakeV3 交易池,攻擊代幣直接調用了pancakeV3SwapCallback 函數並偽造了交易參數,從而通過了tx.origin 驗證並竊取了資產。


在本次攻擊中,三明治交易的相關哈希值如下:


< /p>


三明治機器人的合約地址如下:


· 執行合約(存在漏洞):0x5C936E535Bb591C979a7c8D36C48a6B31808Cef9


· 保險庫合約:0x6E47b1123ddcF74E853516F934f5296cEb17D404


攻擊代幣的合約地址:0xb4864E14467B0D1a2AfB1F70b3f04D4aCd635e06


攻擊代幣交易對的地址:0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93


攻擊者的地址:0x30BA49Ca659B70d3723E3cA6ed96EA4EF0249893


本次攻擊的主要內部交易流程如下圖所示:


注,上圖截取自此處


從上述流程中,我們可以分析攻擊交易的具體步驟如下:


步驟1:攻擊者部署攻擊代幣合約並進行相關準備工作,發起一筆購買交易暴露給三明治交易機器人。


步驟 2:三明治機器人在 FrontRun 中調用 PancakeV3 交易池 0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93 的 swap 函數來獲取攻擊代幣。


步驟3:交易池0xf61F401041a1AF03875B0E0d4AAa9749a57AEB93 將攻擊代幣轉給三明治機器人(Uniswap 系列的先藉機制),這個過程會調用攻擊代幣的transfer 函數。


步驟 4:攻擊代幣的 transfer 函數調用三明治機器人的 pancakeV3SwapCallback() 函數,並附帶偽造的請求參數。


步驟5:三明治機器人的pancakeV3SwapCallback() 函數tx.origin 驗證通過,然後將資產從保險庫中轉移到攻擊代幣合約中(因為pancakeV3SwapCallback 函數通常會將資產發送給msg.sender)。


步驟 6:接下來是正常三明治交易流程。三明治機器人獲利約 25 個 USDC。


步驟 7:攻擊者提取代幣合約中竊取的多種資產。所提取的竊取資產如下圖所示,包括WBNB、BSC-USD 和BUSD:


注,上圖截取自此處


本次攻擊警示合約開發者合約接口一定要驗證調用者的權限,也就是驗證msg.sender,僅僅驗證tx.origin 是不夠的。


在類似的情景中,Fairyproof 建議首先驗證tx.origin,再驗證下列兩種情形之一:


1.初始調用合約的外部接口進行交易時,將交易對地址寫入合約,在回調函數中對此進行驗證。交易執行完畢後再重置這個交易對參數。雖然這樣的操作會額外消耗 gas,但能極大提升安全性。


2.在合約中固定存入Factory 地址,在回調函數中計算相應的交易對地址並進行相應的驗證。


除此以外,對合約進行審計是確保項目安全的必要步驟。本例中出現的安全事故是完全可以通過安全審計發現並避免的。


Fairyproof 為區塊鏈生態提供專業、完善、嚴謹的安全服務,涵蓋合約審計、安全諮詢、安全方案、實時監測、被盜資產追踪等。我們一直致力與生態中的合作夥伴共同攜手,傾力打造安全的生態環境、保護用戶的加密資產。


本文來自投稿,不代表 BlockBeats 觀點  


歡迎加入律動 BlockBeats 官方社群:

Telegram 訂閱群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方帳號:https://twitter.com/BlockBeatsAsia

举报 糾錯/舉報
選擇文庫
新增文庫
取消
完成
新增文庫
僅自己可見
公開
保存
糾錯/舉報
提交