藏在EOA地址裏的魔法：Qubit Finance 被黑分析

前言

2022 年 1 月 28 日，一大早醒來就看見 ps 那邊預警了 Qubit Finance 被黑了。有點慘，這是印象中 pancake bunny 項目不知道第幾次被黑了（這裏默哀。。）。然後順着 Qubit Finance 官方的推特，不難找到這次的攻擊者地址為

https://bscscan.com/address/0xd01ae1a708614948b2b5e0b7ab5be6afa01325c7

既然知道了地址，那么老樣子，話不多說，直接开始分析吧 :D

攻擊細節分析

由於通過 Qubit Finance 我已經拿到了攻擊者的具體地址，所以我就直接對 BSC 上的攻擊者地址進行查詢，看看是做了什么操作。

通過追查攻擊者在 BSC 鏈上的操作，發現攻擊者根本沒有什么准備資金啊，部署攻擊合約之類的操作，直接上來就是 borrow， 這種操作很陌生，只有兩種可能，要不就是這個 borrow 有問題，直接就是通過 borrow就借空所有資產，還有一種可能就是，這裏不是第一案發現場。為了驗證這種想法，就需要先看看對應的 borrow 函數是什么鬼。

簡單一看這個 borrow 函數，明顯是屬於 Compound 的架構，是有抵押品才能進行對應的抵押的，同時#238的 borrowAllowed 函數我也檢查過確實是有正確實現對代幣價值的檢查的。那就說明第一種假設不成立，也就是說，這裏確實不是第一案發現場。那么如果借貸的邏輯是正確的，那么攻擊者理論上來說，會收到由於第一案發現場弄過來的錢來進行借貸。那么攻擊者的錢又是怎么來的呢？帶着這個疑問，不妨看下攻擊者地址的代幣轉移情況。

通過追查攻擊者的代幣轉移情況，發現攻擊者在對 Qubit Finance 進行借貸之前，就已經在其他地方神祕的收到了好幾筆大額的 qXETH 代幣，那么這也驗證了我們的想法，說明借貸操作已經是攻擊後行為了，並不是第一案發現場，為了弄明白這些神祕的資金是怎么來的，我們需要選取其中的一筆交易進行分析(https://bscscan.com/tx/0x8c5877d1b618f29f6a3622cb610ace08ca96e04d8218f587072a3f91e8545bdc)

通過分析這筆交易，發現這筆交易其實是調用了 Qubit Finance 的 Qbridge 合約的 voteProposal 函數。

但是問題是這個 voteProposal 其實是只有合約指定的 relayer 才能進行調用的，難道是 Relayer 的私鑰泄漏了嗎？正常來說如果不了解 Qubit Bridge 的架構的話，得出這個結論是顯而易見的。

但是似乎事實並不是這么簡單。有一種神祕的感覺告訴我事情並不是這樣的。正常來說，對於這種 relayer 架構的跨鏈，如果是通過 relayer 進行的操作的話，那么一定會有一步在其他鏈進行的跨鏈操作，聲明了一個 event，然後才有 relayer 同步到這個 event 然後开始對應代幣的跨鏈，就像 anySwap 一樣，那么基於這種假設，同時攻擊者跨鏈的又是 ETH, 那么攻擊者是大概率在ETH 鏈上進行了一次跨鏈操作的。為了驗證這個想法，我去查了一下 ETH 鏈上的攻擊者的行為，果不其然。。。

可以看到攻擊者確實進行了很多筆跨鏈操作，調用了 QBridge 在以太坊上的合約進行代幣的跨鏈，看來這裏就是第一案發現場了 ，選取其中的一筆交易進行分析，發現更加異常的地方。

理論上攻擊者應該跨鏈ETH到BSC鏈上，但是這筆交易裏既沒有ETH的轉账，也沒有WETH的轉移，是怎么回事呢？這需要我們追蹤對應合約的 deposit 函數來進行分析

通過查看這個代碼，我們不難發現，如果要跨鏈接 ETH，根據代碼的函數命名來看，應該是要調用 depositETH 函數的，但是攻擊者卻調用了 deposit 函數來進行 ETH 的跨鏈？為什么可以這樣？回顧上文說的架構，我們知道，Relayer 架構是依賴 event 消息進行進行跨鏈的，而這 depositETH 和 deposit 這兩個函數，是聲明同一個 event 的，那么就是說，如果有機會能讓 deposit 函數聲明的 event 的參數就是 ETH 代幣跨鏈的參數的話，depositETH 和 deposit 這兩個函數實現的效果其實是一樣的，那么問題到這裏就簡化了，由於這兩個函數的傳參都是一樣的，只要按調用 depositETH 的參數來調用 deposit 不就好啦？

思路是對的，但是這裏還有一個問題，別忽略了 #208 行的 handler 檢查，這個檢查是 deposit函數和 depositETH 函數都有的，按上面的這個思路，能通過檢查嗎？為了驗證這個想法，我們要去看對應 handler 合約的的代碼

通過分析 handler 合約的代碼，發現 handler 同樣存在  deposit 函數和 depositETH 函數，同時，deposit 函數是在 #128行有白名單檢查的，配合圖中標注的 #135 行的 safeTransferFrom 調用也就是說，攻擊者理論上是要轉移代幣的，而攻擊者的的攻擊交易中，沒有出現代幣的轉移，理論上這裏應該要報錯才對？為什么成功了呢？回看代碼，tokenAddress 的獲取是通過 resourceIDToTokenContractAddress 進行獲取的，那么這個地址是啥呢？通過查詢合約，我們得到了 ETH 代幣對應的 resourceID 的代幣合約地址是 0x0000000000000000000000000000000000000000

哎，這裏就有同學想來問啦，0地址不就是沒有設置過的意思嗎？為什么一個沒有設置過的地址能通過檢查呢？於是我們就不死心的去查這個地址是不是真的是在白名單裏，結果一查，哎？結果還真是，芭比Q了 

為什么會有這個操作呢？回顧剛才的代碼，由於 QBirdgeHandler 的 depositETH 函數同樣是包含白名單檢查的，但是充值 native ETH 它沒有代幣合約哇，怎么做白名單檢查呢？QBridge 採用了一個大多數項目都會採用的辦法，那就是如果你充值的是 native ETH 代幣，那么我在合約裏就當你是充值 0 地址的代幣，也就是說，你充值 0 地址的代幣，就認為你充的是 ETH 啦。

那第二個問題來啦，0 地址的調用是怎么成功的？哎？這就是一個有趣的問題啦，我們知道，0地址其實是一個 EOA 地址，那么 EOA 地址中是沒有合約代碼的，那么在 evm 的實現中，對 EOA 地址的調用是不會報錯的，同時也不會執行任何操作。一個老 trick:D, 這個 trick在19年的 0x protocol 上出現過

也就是說， 0 地址直接就成功調用 safeTransferFrom 函數而沒有報錯啦，但是，handler 的檢查和調用結束後，對應的在 QBridge合約聲明出來的 event，卻是和轉入了 ETH 是一模一樣的哦。但是 relayer 哪知道這么多，它只是一個執行 event 捕獲的雲服務器而已 :D

總結

這次 Qubit Fiance 的被黑其實同時存在了好幾個問題

1. 最大的問題，自然是 EOA 調用的問題，其實是不會報錯的，這個問題沒有被意識到

2. 但是除了這個問題之外，還需要結合 depositETH 和 deposit 函數本身聲明的是同一個類型的事件，不然也是不會出問題的

彩蛋

經過查詢，deposit 函數以前是用來充值 WETH 的，而且用的 resourceID 和這次攻擊用的 ID 是一樣的，那么以前的調用是正常的，那么為什么現在就不正常呢？肯定是有人改過嘛 :D

然後果不其然，我還真的找到了 

而這個函數，只有 owner 才能調用，為什么要這樣搞呢？細節請大家發揮聯想，我的分析之旅到這裏就結束了 ;)

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。