CoinEx安全團隊：揭秘 THORChain (RUNE) 安全風險

THORChain 官方公佈了 2022 年 Q1 財報，在 2022 年初期持續性低迷的市場行情和高度不穩定的地緣政治雙重因素影響下，THORChain 營收實現了正增長。從公開數據顯示 THORChain 一季度收入 2.17 億美元。被譽為「跨鏈版 Uniswap」的 THORChain 憑藉自身的產品獨特性成功躋身跨鏈交易市場，受到投資者的青睞。

看似光鮮的背後，THORChain 也飽受駭客盜幣之苦。自 THORChain 在以太坊發行以來，安全事件頻發引起市場對 THORChain 安全性的質疑。4月11日，THORChain 官方推特發佈一則注意網路釣魚攻擊的貼文，警告用戶不要與 DeTHOR 或其他未知代幣進行互動，再次引發用戶對 THORChain 安全問題的擔憂。

CoinEx 安全團隊在專注自身產品的安全體系建設以外，同時保持對區塊鏈行業安全事件持續性關注，希望從技術安全的視角幫助用戶更好地瞭解不同項目的安全性，減輕項目投資風險。出於促進行業安全規範的角度出發，CoinEx 安全團隊對近期關注度較高的項目 – THORChain(RUNE) 進行了安全風險剖析。期望能夠引起項目方重視並進行合約代碼的優化，同時警醒用戶增強資產安全意識，規避資金損失風險。

THORChain（RUNE）的安全性如何？

CoinEx 安全團隊經過對 THORChain (RUNE) 合約代碼及邏輯進行分析，總結 THORChain (RUNE) 可能存在的風險：

首先，透過查看 THORChain (RUNE) 的合約代碼：

https://etherscan.io/address/0x3155ba85d5f96b2d030a4966af206230e46849cb#code

我們可以看到這是一個相對標準的 ERC-20 代幣。值得注意的是，除了標準的 ERC-20 標準接口，THORChain (RUNE) 還額外提供了一個接口：

如上圖所示，在 tranferTo 我們可以看到 THORChain (RUNE) 使用了 tx.origin，這是導致THORChain（RUNE）風險存在的因素之一。在這裡，我們需要解釋下 tx.origin 與 msg.sender 的區別：

下圖是普通地址直接調用合約的情況：

這種情況下，智能合約裡：msg.sender = account.address, tx.origin = account.address。 msg.sender 和 tx.origin 是一樣的。

接下來，我們再觀察下地址調用合約，合約再調用合約的情況如何：

如上圖所示，在合約再調用合約的情況下，我們看到對於合約 contractA， 其 msg.sender 和 tx.origin 沒有區別都是 account.address。

但是對於 contract B，結果顯示 msg.sender 等於合約 A 的地址，而 tx.origin 則為 account.address。因此，tx.origin 相當於一個全局變量，它遍歷整個調用棧並返回最初發送交易的帳戶地址。這就是問題的關鍵所在，截至目前為止，THORChain (RUNE) 已知的黑客攻擊事件幾乎都是因為 tx.origin。

接下來，讓我們看看攻擊者是如何通過 tx.origin 的特性盜取用戶的 RUNE 代幣：

第一種方式：「順手牽羊」

以太坊上地址分為：外部地址和合約地址。通過外部地址給兩種類型的地址轉帳 ETH 有著本質的區別。通過查看 solidity 的官方文檔，我們知道要給合約地址轉帳，合約地址必須實現 receive 方法。

結合 tx.origin 的特性，攻擊者可以構造一個 Attack 合約：

通過 Attack 合約，只要用戶給該合約轉帳 ETH，在轉帳過程中，Attack 合約就會順手牽羊，把用戶的帳上持有的 RUNE 同步順走。

第二種方式：珠聯幣合

「珠聯幣合」則相對比較特殊，攻擊者若通過本方式盜取用戶的 RUNE 不僅需要一個媒介代幣，還需要該代幣有機會調用第三方合約。通過觀察以太坊上 RUNE 的轉帳記錄，發現有攻擊者通過 AMP 代幣的轉帳盜取用戶 RUNE 的記錄。

AMP 代幣使用 erc1820 協議進行 hook 註冊管理，每次 transfer 時都會有檢測是否有註冊 hook。如有，則調用對應的 hook 回調。

透過查看 AMP 代幣的合約代碼，我們發現 transfer 最終執行的是：_transferByPartition，其中有兩處涉及 transferhook 的回調。一個是轉帳之前：_callPreTransferhooks，一個是轉帳之後：_callPostTransferhooks。_callPreTransferhooks 是針對 from 地址，而 _callPostTransferhooks 則針對的是 to 地址，即接收代幣的地址。

對普通用戶而言，薅自己的代幣並沒有任何意義。因此，對攻擊者而言，可以操作的是 _callPostTransferhooks。讓我們來查看 _callPostTransferhooks 的代碼：

注意看，唯一可能被利用的回調 IAmptokensRecipient(recipientImplementation).tokensReceived()

下面將詳細介紹如何利用該回調在轉帳 AMP 代幣的同時轉走用戶的 RUNE。

第一步：需要一個回調合約，如下所示:

第二步：部署第一步的合約得到地址 Attack Address

第三步：調用 erc1820 合約接口 setInterfaceImplementer 註冊接口

erc1820 地址：0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

合約接口：setInterfaceImplementer(address toAddr, bytes32 interfaceHash, address implementer)

其中：toAddr為轉走AMP的接收地址，interfaceHash 為 Amp 代幣 sRecipient 的 hash:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

Implementer：為第二步部署得到的 attack address

第四步：引誘用戶向 toAddr 轉 AMP 觸發回調，同時轉帳用戶的 RUNE。

第三種方式：「投懷送抱」

「投懷送抱」顧明思議是攻擊者通過贈送用戶一些可觀的福利從而引誘用戶進行合約操作。下面將介紹一種常見的方式。

第一步：攻擊者發行一個ERC-20 代幣，他可以寫入任何涉及到簽名的合約接口中；

第二步：在 Uniswap 或者其他 swap 創建交易對；

第三步：給所有持有 RUNE 代幣的用戶地址進行空投；

通過以上三步驟，前期的「投懷送抱」工作基本完成，接下來只需等待用戶去 swap 交易，用戶只要進行 approve、transfer 等操作都有 RUNE 丟失的風險。

此外，為進一步核實 THORChain 合約代碼的安全風險問題，CoinEx 安全團隊與行業兩家知名安全機構慢霧安全團隊及派盾安全團隊進行了討論，經慢霧安全團隊和派盾安全團隊驗證後，認為以上提到的安全風險確實存在。

那麼，項目方該如何優化合約代碼以提高項目的安全性，確保用戶資產安全呢？

無他，唯有慎用 tx.origin。

另一方面，作為普通用戶面對防不勝防的盜幣方式時，該如何規避風險保護自我資產。對此，CoinEx 安全團隊建議：

1. 針對第一種盜幣方式：在轉帳時需要注意預估的 gas 消耗。普通的ETH轉帳，21000 的 Gas 消耗足矣，若發現 Gas 消耗遠超於 21000，則需要加強警惕。

2. 針對第二種盜幣方式：建議進行錢包隔離。不同的代幣存放在不同的錢包地址，尤其是交易所的熱錢包地址，更應多加小心。

3、針對第三種盜幣方式：貪婪是萬惡之源，切勿盲目參與空投活動。

安全是區塊鏈行業亙古不變的話題，無論是項目方、交易所還是所有的行業參與者都應當將安全作為項目運營的重中之重，承擔起保護用戶資產安全的責任，共同推動行業良性發展。