本文為社區投稿。作者為CertiK的審計師Minzhi He。
本文的觀點是投稿人/作者的觀點,未必反應幣安學院的觀點。
摘要
區塊鏈橋是區塊鏈領域實現互通性的根本所在。因此,跨鏈橋接技術的安全至關重要。一些常見的區塊鏈橋安全漏洞包括鏈上和鏈下驗證不足、原生代幣處理不當以及配置錯誤。為了確保驗證邏輯合理,建議針對所有可能的攻擊向量對跨鏈橋進行測試。
區塊鏈橋是連接兩個區塊鏈橋是連接兩個區塊鏈橋,讓二者實現互動的協定。透過區塊鏈橋,用戶如要參與以太坊網路的DeFi活動,只需持有比特幣,無需出售即可達成目的。
區塊鏈橋是區塊鏈領域實現互通性的根基。它們使用各種鏈上和鏈下驗證來發揮作用,因此也可能存在不同的安全漏洞。
區塊鏈橋通常會持有用戶想從一條鏈轉移到另一鏈的代幣。區塊鏈橋通常以智慧合約的形式部署,隨著跨鏈轉移的持續積累,橋上會持有大量的代幣,這筆巨額的財富就會使它們成為駭客覬覦的目標。
此外,由於涉及許多元件,區塊鏈橋的攻擊面往往很大。因此,不法分子有著強烈的動機把跨鏈應用作為目標,以期攫取大量資金。
根據CertiK的估計,在2022年,區塊鏈橋攻擊造成了超過13億美元的損失,佔當年總損失的36%22年,區塊鏈橋攻擊造成了超過13億美元的損失,佔當年總損失的36%22年,區塊鏈橋攻擊造成了超過13億美元的損失,佔當年總損失的36% 。
為了增強區塊鏈橋的安全性,了解常見的跨鏈橋接安全漏洞並在啟動前測試區塊鏈橋十分重要。這些漏洞主要來自以下四個面向:
對於簡單的區塊鏈橋,尤其是專為特定dApp設計的區塊鏈橋,通常只有最低程度的鏈上驗證。這些橋樑依靠集中式後端來執行基本操作,例如鑄幣、銷毀和代幣轉移,所有驗證都是在鏈下進行的。
而其他類型的橋則使用智能合約來驗證訊息並在鏈上進行驗證。在這種情況下,當用戶將資金存入鏈中時,智能合約會會產生簽名的訊息並在交易中返回簽名。這個簽章就會用來當儲值的證明,用來驗證使用者在另一條鏈上的提現請求。這個流程應該能夠防止各種安全攻擊,包括重播攻擊和偽造儲值記錄。
但是,如果鏈上驗證過程有漏洞,攻擊可能會造成嚴重損失。例如,如果區塊鏈用梅克爾樹來驗證交易記錄,那麼攻擊者就可以產生偽造證明。這意味著,如果驗證過程有漏洞,攻擊者可以繞過證明驗證,並在其帳戶中鑄造新的代幣。
某些區塊鏈橋會實施「包裝代幣(wrapped tokens)」的概念。例如,當使用者將DAI從以太坊轉移到BNB Chain時,他們的DAI將從以太坊合約中取出,並在BNB Chain上發行等量的包裝DAI。
但是,如果此交易沒有正確驗證,攻擊者就可以部署惡意合約,透過操縱該功能,將包裝的代幣從橋接路由到錯誤的位址。
攻擊者還需要受害者先批准跨鏈橋合約,才能使用「TransferFrom」功能轉移代幣,從而從跨鏈橋合約中捲走資產。
但棘手的是,許多跨鏈橋都會要求dApp用戶無限地批准代幣,這種做法很常見,它可以降低燃料費,但允許智慧合約從用戶的錢包中存取不限量的代幣,會帶來額外的風險。攻擊者會利用這些驗證不足和批准過度,將代幣從其他用戶轉移給自己。
在某些跨鏈橋系統中,鏈下後端伺服器在驗證從區塊鏈發送的訊息的合法性時起著至關重要的作用。在這種情況下,我們要專注於儲值交易的驗證。
有鏈下驗證的區塊鏈橋的工作原理如下:
用戶與dApp交互,將代幣存入源鏈上的智能合約。
然後,dApp透過API將儲值交易雜湊傳送到後端伺服器。
交易雜湊需要經過伺服器的多次驗證。如果被認為合法,則簽署者會簽署一則訊息,並將簽名透過API傳回使用者介面。
收到簽名後,dApp會對其進行驗證,並允許用戶從目標鏈中提取代幣。
後端伺服器必須確保其處理的儲值交易是真實發生而並非偽造的。此後端伺服器會決定用戶是否可以在目標鏈上提取代幣,因此成為首當其衝的攻擊目標。
後端伺服器需要驗證交易發起事件的結構,以及發起此事件的合約位址。如果忽視後者,攻擊者就可能會部署惡意合約,來偽造與合法儲值事件結構相同的儲值事件。
如果後端伺服器不驗證哪個位址發起了該事件,它就會認為這是有效交易,並且簽署訊息。攻擊者就可以向後端伺服器發送交易哈希,繞過驗證,使其從目標鏈中提取代幣。
跨鏈橋採用不同的方法來處理原生代幣和效用代幣。例如,在以太坊網路上,原生代幣是ETH,大多數效用代幣都符合ERC-20標準。
如果使用者打算把自己的ETH轉移到另一鏈,必須先將其存入跨鏈橋合約。為此,用戶只需將ETH附到交易中,即可透過讀取「msg.value」交易欄位來檢索ETH的數量。
存入ERC-20代幣與存入ETH有很大差別。要存入ERC-20代幣,用戶必須先允許跨鏈橋合約使用他們的代幣。在他們批准並將代幣存入跨鏈橋合約後,合約將用 “burnFrom()”函數銷毀用戶的代幣,或用“transferFrom()”函數將用戶的代幣轉移到合約中。
要區別是哪一種操作,可以在同一個函數中使用if-else語句。或者建立兩個單獨的函數來處理每個場景。由於處理方式不同,如果使用者嘗試使用ERC-20充值函數來存入ETH,那麼這些ETH可能會遺失。
在處理ERC-20充值請求時,使用者通常提供代幣位址作為輸入參數傳遞給儲值函數。這會構成重大風險,因為在交易過程中可能會發生不可信的外部呼叫。使用白名單來只包含跨鏈橋支援的代幣,是把風險降到最低的常見做法。只有列入白名單的地址會作為參數傳遞。這樣可以防止外部調用,因為專案團隊已經過濾了代幣地址。
但是,當跨鏈橋處理原生代幣跨鏈傳輸時,也有個麻煩,因為原生代幣沒有地址。原生代幣可以使用一個特殊的地址來代表,即「零地址」(0x000... 0)。但這樣做存在一個問題,如果未正確實作白名單驗證邏輯,使用零位址傳遞給函數可能會繞過白名單驗證。
當跨鏈橋合約呼叫「TransferFrom」將使用者資產轉移到合約時,對零位址的外部呼叫會傳回false ,因為零位址中沒有實作“transferFrom”函數。但是,如果合約沒有正確處理回傳值,交易仍可能繼續發生。這就會為攻擊者創造機會,使其不用向合約轉移任何代幣就能執行交易。
9f5963d在大多數區塊鏈橋中,有一個特權角色負責將代幣和地址列入白名單或黑名單,分配或改變簽名者,以及其他關鍵配置。確保所有配置準確無誤非常關鍵,因為看似微不足道的疏忽也可能導致重大損失。
實際上,曾經真的發生過攻擊者由於配置錯誤而成功繞過傳輸記錄驗證的事件。該專案團隊在駭客攻擊發生前幾天實施了協議升級,其中更改了某個變數。此變數是用來表示可信任訊息的預設值。這個變更導致所有訊息都被自動認為是經過驗證的,因此使攻擊者隨便提交一個訊息就能通過驗證。
上面所述的四個常見跨鏈橋漏洞表明,在互聯區塊鏈生態系統中安全所面臨的挑戰不可小覷。要應付這些漏洞,需要「因地制宜」地考慮,沒有任何方法可以全能地對付所有漏洞。
例如,由於每個跨鏈橋都有獨特的驗證要求,因此僅僅提供通用準則就想確保驗證過程沒有錯誤,這很難做到。防止繞過驗證的最有效方法,是針對所有可能的攻擊向量對跨鏈橋進行全面測試,並確保驗證邏輯是合理的。
總而言之,必須針對潛在攻擊進行嚴格的測試,並特別注意跨鏈橋中最常見的安全漏洞。
由於資金量龐大,跨鏈橋長期以來一直是攻擊者的目標。建構者可以透過進行全面的部署前測試和納入第三方審計來加強跨鏈橋的安全,從而降低過去幾年來籠罩在跨鏈橋上的災難性駭客攻擊的風險。跨鏈橋在多鏈的世界中至關重要,但在設計和建構有效的Web3基礎架構時,安全性必須是首要考慮因素。
什麼是區塊鏈橋?
什麼是跨鏈互通性?
三大人氣加密貨幣橋及工作原理
什麼是包裝代幣?