區塊鏈安全:實現公鏈雙花攻擊的多種方法

區塊鏈社群HiBlock發表於2018-11-28

image

針對 EOS、NEO 等大公鏈平臺的多個雙花攻擊漏洞的案例,360 區塊鏈實驗室總結出了多種造成數字貨幣雙花攻擊的多種原因,並提出了一種通用的安全減緩措施。各種大公鏈專案實際上都產生過能夠產生雙花攻擊之類的嚴重安全問題,盜取加密貨幣對黑客來講不是難事。

而在幾個月的區塊鏈安全研究中,360 區塊鏈實驗室收到了來自各個專案方價值超過 30 萬美金的數字貨幣漏洞報告獎勵。

2008 年,中本聰提出了一種完全通過點對點技術實現的電子現金系統(比特幣)。該方案的核心價值在於其提出了基於工作量證明的解決方案,使現金系統在點對點環境下執行,並能夠防止雙花攻擊。如今比特幣已經誕生十年,無數種數字貨幣相應誕生,但人們對雙花攻擊的討論似乎仍然停留在比特幣 51% 攻擊上。實際上,我們的研究發現,實用的數字貨幣雙花攻擊還有很多種其他形式。在本文中,我們通過介紹我們發現的針對 EOS、NEO 等大公鏈平臺的多個雙花攻擊漏洞,總結出多種造成數字貨幣雙花攻擊的多種原因,並提出一種高效的減緩措施。

1

工作量證明和雙花攻擊

2008 年,中本聰提出了一種完全通過點對點技術實現的電子現金系統,它使得線上支付能夠直接由一方發起並支付給另外一方,中間不需要通過任何的金融機構。雖然數字簽名部分解決了這個問題,但是如果仍然需要第三方的支援才能防止雙重支付的話,那麼這種系統也就失去了存在的價值。比特幣的工作量證明機制 (PoW) 的本質,就是要使現金系統在點對點的環境下執行,並防止雙花攻擊。

工作量證明機制的原理如下:網路中每一個區塊都包含當前網路中的交易和上一個區塊的區塊頭雜湊。新區塊產生,其區塊頭雜湊必須滿足工作量證明條件(需要進行大量的雜湊計算)。整個網路將滿足工作量證明的雜湊鏈連線起來,從而形成區塊鏈。除非攻擊者重新完成全部的工作量證明,否則形成的交易記錄將不可更改。最長的區塊鏈不僅將作為被觀察到的交易序列的證明,而且被看做是來自算力最大的群體的共識。只要整個網路中大多數算力都沒有打算合作起來對全網進行攻擊,那麼誠實的節點將會生成最長的、超過攻擊者的鏈條,從而實現對雙花攻擊的抵抗。

雙花攻擊實際上是一個結果。如果一個攻擊者 A 將同一個比特幣同時支付給 B 和 C 兩個使用者,並且 B 和 C 兩個使用者都認可了這筆交易。那麼我們說 A 將該比特幣花了兩次,A 實現了一次雙花攻擊。針對工作量證明機制的雙花攻擊中,51% 攻擊是被討論的最多的一種攻擊形式。但針對工作量證明機制的雙花攻擊實際上有多種形式,包括芬妮攻擊、競爭攻擊、Vector76 攻擊等。這些攻擊實際上也得到了充分的關注和討論,本文中不做贅述。實際上,實用的數字貨幣雙花攻擊還有很多種其他形式。下文中,我們將通過多個我們發現的多個安全漏洞,討論多種數字貨幣雙花攻擊的多種原因,並提出一種高效減的緩措施。

2

雙花攻擊的新分類

智慧合約平臺,本質上是要在全網共享一個賬本。這可以看成是一個分散式狀態機複製問題。當前的賬本狀態,我們可以認為是 State_n。當一個新交易 Tx_ 產生的時候,Tx_ 將對 State_n 產生一個作用。從而使 State_n 狀態過渡到 State_ 狀態。這個過程我們可以用公式表示:

State_n × Tx_{n+1} → State_{n+1}

智慧合約平臺共識機制,本質上是將所有的交易【Tx_1 Tx_2 ……. Tx_n】按順序作用到初始 State_0 上,使全網始終保持相同的狀態。區塊鏈中的每一個區塊,實際上將交易序列【Tx_1 Tx_2 ……. Tx_n】按順序拆分成不同的區塊 Block1,Block2 並按順序連結起來。在全網狀態機複製的過程中,如果一旦因為某些原因產生了全網狀態不一致,則我們可以認為全網產生了一個分叉。分叉被攻擊者利用,可進一步實現雙花攻擊。

本文中,我們將我們發現的這些雙花攻擊漏洞分成 3 類:

  • 驗證不嚴格造成的雙花攻擊。

  • 狀態機 State_n × Tx_{n+1}→State_{n+1}不一致執行造成的雙花攻擊。

  • 共識機制造成的雙花攻擊。

驗證不嚴格造成的雙花攻擊,主要原因在於具體實現邏輯校驗問題。比特幣的漏洞 CVE-2018-17144 實際上就是這樣一個漏洞。

狀態機不一致執行造成的雙花攻擊,主要是由於智慧合約虛擬機器因為各種原因導致直接結果不一致,從而在整個網路中創造分叉,造成雙花攻擊。

共識機制漏洞可能產生整個網路的分叉,從而進一步造成雙花攻擊。人們常說的 51% 攻擊,實際上就是 PoW 共識機制的分叉漏洞。

3

驗證不嚴格造成的雙花攻擊

驗證不嚴格造成的雙花攻擊,主要原因在於具體實現邏輯校驗問題。這裡我們介紹兩個關於區塊與交易繫結時校驗不嚴格,從而產生雙花攻擊的漏洞。

在區塊鏈專案中,一筆交易 Tx_1 被打包的某個區塊 Block_1 中的方式如下:首先計算交易 Tx_1 的雜湊值 Hash_1,然後用 Hash_1 與其他交易的雜湊值 Hash_2…Hash_n 組合構成 Merkle Hash Tree。計算出雜湊樹的根節點 root,然後將 root 打包到 Block_1 中。這樣即形成一筆交易與區塊的繫結。一般來講,除非攻擊者能夠攻破雜湊函式的抗碰撞性,否則無法打破一筆交易與區塊的繫結。如果攻擊者能夠打包交易與區塊的繫結,則攻擊者能通過造成全網的分叉從而實現雙花攻擊。下面我們介紹兩個我們在 NEO 上發現的雙花攻擊漏洞:

3.1 NEO 虛擬機器 GetInvocationScript 雙花攻擊漏洞:

區塊鏈專案中,一個交易一般是由未簽名的部分(UnsignedTx,交易要執行的內容)和簽名的部分(交易的 witness)構成的。在如比特幣之類的區塊鏈專案中,交易的 hash 計算實際上是包含了該交易的簽名部分的。而在如 NEO、ONT 等多種區塊鏈平臺中,交易的計算公式為 hash=SHA256(UnsignedTx)。即交易的雜湊是由未簽名的部分計算的來的,與交易的 witness 無關。而 NEO 智慧合約在執行的時候,能夠通過 Transaction_GetWitnesses 方法,從一個交易中獲得該交易的 witnesses。其具體實現如下:

image

某個合約交易獲得自己的 witness 之後,還能夠通過 Witness_GetVerificationScript 方法獲得該 witness 中的驗證指令碼。如果攻擊者針對同一個未簽名交易 UnsignedTx1,可以構造兩個不同的驗證指令碼。則可以造成該合約執行的不一致性。正常情況下,合約的 VerificationScript 是由合約的輸入等資訊決定的,攻擊者無法構造不同的驗證指令碼並通過驗證。但是我們發現在 VerifyWitness 方法中,當 VerificationScript.length=0 的時候,系統會呼叫 EmitAppCall 來執行目標指令碼 hash。

image

所以當 VerificationScript=0,或者 VerificationScript 等於目標指令碼的時候,均可滿足 witness 驗證條件。即攻擊者可以對於同一個未簽名的交易 UnsignedTx_1,構造兩個不同的 VerificationScript。攻擊者利用這個性質,可以對 NEO 智慧合約上的所有代幣資產進行雙花攻擊,其具體攻擊場景如下:

步驟 1:攻擊者構造智慧合約交易 Tx_1(未簽名內容 UnsignedTx_1, 驗證指令碼為 VerficationScript_1)。在 UnsignedTx_1 的合約執行中,合約判斷自己的 VerficationScript 是否為 VerficationScript_1。如果為 VerficationScript_1,擇傳送代幣給 A 使用者。如果 VerficationScript 為空,則傳送代幣給 B 使用者。

步驟 2:Tx_1 被打包到區塊 Block_1 中。

步驟 3: 攻擊者收到 Block_1 後,將 Tx_1 替換成 Tx_2(Tx_1 具有與 Tx_1 相同的未簽名內容 UnsignedTx_1,但驗證指令碼為空) 從而形成 Block_2。攻擊者將 Block_1 傳送給 A 使用者,將 Block_2 傳送給 B 使用者。

步驟 4:當 A 使用者收到 Block_1 時,發現自己收到攻擊者傳送的代幣。當 B 使用者收到 Block_2 時,也會發現自己收到了攻擊者傳送的代幣。雙花攻擊完成。

可見,該漏洞的利用門檻非常低,且可以對 NEO 智慧合約上的所有代幣資產進行雙花攻擊。危害非常嚴重。

3.2 NEO MerlkeTree 繫結繞過造成交易雙花攻擊漏洞:

智慧合約交易與區塊的繫結,通常通過 MerkleTree 來完成。如果攻擊者能繞過該繫結,則能實現對任意交易的雙花。這裡我們看看 NEO 的 MerkleTree 的實現如下:

image

在 MerkleTreeNode 函式中,NEO 進行了 MerkleTree 葉節點到父節點的計算。但這裡存在一個問題,當 leaves.length 為奇數 n 的時候。NEO 的 MerkleTree 會將最後一個葉節點複製一次,加入到 MerkleTree 的計算中。也就是說當 n 為奇數時,以下兩組交易的 MerkleRoot 值會相等:

【Tx_1 Tx_2 …… Tx_n】

【Tx_1 Tx_2 …… Tx_n Tx_】其中 Tx_= Tx_n

利用這個特性,攻擊者可以實現對任意 NEO 資產的雙花攻擊。其具體攻擊場景如下:

步驟 1:假設正常的一個合法 Block_1,包含的交易列表為【Tx_1 Tx_2 … Tx_n】。攻擊者收到 Block_1 後,將交易列表替換為【Tx_1 Tx_2 … Tx_n Tx_】,形成 Block_2。然後將 Block_2 釋出到網路中去。

步驟 2:一個普通節點收到 Block_2 後,會對 Block_2 的合法性進行校驗。然而因為【Tx_1 Tx_2 … Tx_n Tx_】與【Tx_1 Tx_2 … Tx_n】具有相同的 MerkleRoot。所以 Block_2 能夠通過區塊合法性校驗,從而進如區塊持久化流程。NEO 本地取消了普通節點對合法區塊中交易的驗證(信任幾個共識節點)。則 Tx_n 交易可以被普通節點執行兩次,雙花攻擊執行成功。

可見,該漏洞的利用門檻非常低,且可以對 NEO 上的所有資產進行雙花攻擊。危害非常嚴重。

4

虛擬機器不一致性執行

智慧合約平臺共識機制,本質上是將所有的交易【Tx_1 Tx_2 ……. Tx_n】按順序作用到初始 State_0 上,使全網始終保持相同的狀態。在狀態機複製過程中,我們要求 State_n × Tx_èState_ 是決定性的。State_n × Tx_èState_ 實質上就是智慧合約虛擬機器對 Tx_ 的執行過程,如果智慧合約虛擬機器中存在設計或者實現漏洞,導致虛擬機器不一致性執行(對相同的輸入 State_n 和 Tx_,輸出 State_ 不一致)。則攻擊者可以利用該問題在網路中產生分叉和並進行雙花攻擊。下面我們介紹多個 EOS 和 NEO 上我們發現的虛擬機器不一致執行漏洞和其產生原因。

4.1 EOS 虛擬機器記憶體破壞 RCE 漏洞:

此前,我們公開了文章《EOS Node Remote Code Execution Vulnerability --- EOS WASM Contract Function Table Array Out of Bound》(blogs.360.cn/post/eos-no…)。在該文中,我們發現了一個 EOS WASM 虛擬機器的一個記憶體越界寫漏洞,針對該漏洞我們編寫的利用程式可以成功利用該漏洞使 EOS 虛擬機器執行任意指令,從而完全控制 EOS 所有出塊和驗證節點。

究其本質而言,是在 State_n × Tx_{n+1} → State_{n+1}過程中。攻擊者能讓 EOS 虛擬機器完全脫離原本執行路徑,執行任意指令,自然可以完成雙花攻擊。其攻擊流程如下:

步驟 1:攻擊者構造能夠實現 RCE 的惡意智慧合約,並將該合約釋出到 EOS 網路中。

步驟 2:EOS 超級節點解析到該合約後,觸發漏洞,執行攻擊者自定義的任意指令。

步驟 3:攻擊者實現雙花攻擊。

該漏洞的危害非常嚴重,且是第一次智慧合約平臺受到遠端程式碼執行攻擊事件。讀者可以閱讀該文章瞭解相關細節,在此不再贅述。

4.2 EOS 虛擬機器記憶體未初始化造成雙花攻擊:

我們在編寫《EOS Node Remote Code Execution Vulnerability --- EOS WASM Contract Function Table Array Out of Bound》的利用程式的過程中,還利用了 EOS 中當時的一個未公開的記憶體未初始化漏洞。在記憶體破壞攻擊中,記憶體未初始化漏洞通常能夠造成資訊洩露、型別混淆等進一步問題,從而輔助我們繞過如 ASLR 之類的現代二進位制程式的緩解措施,進一步實現攻擊。然而在智慧合約虛擬機器中,記憶體未初始化漏洞有更直接的利用方式,可以直接造成雙花攻擊。以下為我們在 EOS RCE 中利用的一個記憶體未初始化漏洞的細節,其可以被用來直接實現 EOS 智慧合約代幣資產雙花攻擊。

當 WASM 虛擬機器通過 grow_memory 虛擬碼來申請記憶體新的記憶體。在 EOS WASM grow_memory 最初的實現中,未對申請到的記憶體進行清零操作。該塊記憶體的空間實際上是隨機的(依賴於合約執行機器的記憶體狀態)。則攻擊者可以構造惡意合約,實現對 EOS 上任意合約資產的雙花攻擊。其攻擊流程如下:

步驟 1: 攻擊者構造惡意智慧合約。合約中通過 grow_memory 獲得一塊新的記憶體地址。

步驟 2:合約中讀取該地址中的某個 bit 內容(此時該 bit 可能為 0,也可能為 1,依賴於合約執行機器的狀態)。

步驟 3:合約判斷該 bit 的內容,如果為 1 則傳送代幣給 A 使用者,如果為 0 則傳送代幣給 B 使用者,從而實現雙花攻擊。

4.3 EOS 虛擬機器記憶體越界讀造成雙花攻擊:

在傳統的記憶體破壞中,記憶體越界讀漏洞主要將會導致資訊洩露,從而輔助我們繞過如 ASLR 之類的現代二進位制程式的緩解措施,進一步與其他漏洞一起實現攻擊。然而在智慧合約虛擬機器中,記憶體越界讀漏洞有更直接的利用方式,可以直接造成雙花攻擊。下面為一個我們發現的 EOS 記憶體越界讀漏洞,我們可以利用該漏洞實現雙花攻擊。

當 EOS WASM 將一個 offset 轉換內 WASM 記憶體地址時,其邊界檢查過程如下:

image

在這裡|ptr|的型別實際上是一個 I32 型別,它可以是一個負數。那麼當:

-sizeof(T) < ptr < 0
複製程式碼

的時候,ptr+sizeof(T) 是一個很小的數可以通過該邊界檢查。在之後的定址中,我們看到程式碼:

T &base = (T)(getMemoryBaseAddress(mem)+ptr);
複製程式碼

|base|的地址將會超過 WASM 的記憶體基址,從而讓智慧合約實現記憶體越界讀(讀到的記憶體地址內容取決於虛擬機器當前執行狀態,可被認為使隨機的)。攻擊者可以利用該漏洞實現雙花攻擊。其攻擊過程如下:

步驟 1: 攻擊者構造惡意智慧合約。合約中利用記憶體越界讀漏洞,讀取超越 WASM 記憶體基址的某個 bit)此時該 bit 可能為 0,也可能為 1,依賴於合約執行機器的狀態)。

步驟 2:合約判斷該 bit 的內容,如果為 1 則傳送代幣給 A 使用者,如果為 0 則傳送代幣給 B 使用者,從而實現雙花攻擊。

4.4 標準函式實現不一致造成雙花攻擊:

總結上面雙花攻擊兩個例子的本質,實際上是 EOS 合約在執行過程中因為某些記憶體漏洞原因讀取到了隨機變數,從而打破了原本虛擬機器執行的一致性,造成了雙花攻擊。事實上,合約執行的不一致性,不一定完全依賴於隨機性。這裡我們介紹一個因為各個平臺(版本)對標準 C 函式實現不一致造成的雙花攻擊。

在 C 語言標準定義中,memcmp 函式的返回時被要求為:小於 0,等於 0,或者大於 0。然而各種不同的 C 版本實現中,具體返回的可能不一樣(但依然符合 C 標準)。攻擊者可以利用該標準實現的不一致性,造成執行在不同系統上的 EOS 虛擬機器執行結果不一致,進而實現雙花攻擊。其攻擊流程如下:

步驟 1:攻擊者構造惡意智慧合約,在合約中呼叫 memcmp 函式,並獲取返回值。

步驟 2:此時,不同的平臺和版本實現 Memcmp 的返回值不一致(即使 EOS 虛擬機器的二進位制程式碼是相同的)。惡意合約判斷 Memcmp 的返回值,決定轉賬給 A 或 B,從而完成雙花。

該漏洞的具體修復如下:

image

EOS 強制將 memcmp 的返回值轉換為 0,-1 或者 1,從而抵抗這種不一致執行。

Memcmp 這個問題,是同一種語言對相同標準實現的不一致性造成的。事實上,同一個區塊鏈專案經常會有多個不同版本語言的實現。

不同語言對相同標準的實現通常也會有偏差,比如一個我們發現的因標準定義實現不一致造成不一致執行是 ECDSA 函式。ECDSA 簽名標準中要求私鑰 x 不為 0。如 python、JS 中的多個密碼學庫中對該標準由嚴格執行,但是我們發現部分 golang 的 ECDSA 庫允許私鑰 x=0 進行簽名和驗證計算,惡意攻擊者利用該問題可以對同一個區塊鏈平臺的不同版本實現(比如 golang 實現和 python 實現)構造不一致執行惡意合約,從而進一步完成雙花攻擊。

4.5 版本實現不一致造成雙花攻擊:

同一個區塊鏈專案經常會有多個不同版本程式語言的實現。不同程式語言的實現同樣存在著各種這樣的不一致執行的可能性。上面 ECDSA 是一個例子。大整數運算也是一個常見的例子。比如在曾經的 NEO 的 C# 版本實現和 python 版本實現中,大整數 (BigInteger) 除法運算可導致不同程式語言實現版本見的不一致執行現象,從而造成雙花攻擊。類似的現象在多個區塊鏈專案中產生過。

4.6 其他問題不一致性問題

系統時間、隨機數、浮點數計算等因素也是可以造成虛擬機器不一致執行的原因。但是在我們的審計中,並沒有發現此類漏洞在大公鏈專案中出現。多數區塊鏈專案在設計之初就會考慮到這些明顯可能造成的問題。

但可能造成不一致執行的因素可能遠遠超過我們上面發現的這些問題。事實上,一些主觀因素(取決於機器當前執行狀態的因素,我們稱之為主觀因素)都可能造成虛擬機器的不一致執行。舉個例子,比如在 4G 記憶體,8G 記憶體的機器在執行過程中產生記憶體溢位 (OOM) 的主觀邊界就不一樣,攻擊者利用 OOM 可能造成虛擬機器的不一致執行。

5

共識機制造成的雙花攻擊

共識機制造成的雙花攻擊實際上是在業界中獲得充分討論的一個問題,然而各種公鏈方案在共識機制實現上仍然可能存在分叉問題,從而造成雙花攻擊。

5.1 ONT vBFT VRF 隨機數繞過漏洞

Long range attack 是目前所有 PoS 共識機制都面臨的一種分叉攻擊方法。攻擊者可以選擇不去分叉現有的鏈,而實回到某個很久之前的鏈狀態(攻擊者在這個狀態曾佔有大量貨幣),造一跳更長的新鏈出來讓網路誤以為是主鏈,從而完成雙花。目前業界針對 Long range attack 並沒有根本的解決辦法,只能保證在“Weak Subjectivity”不發生的情況下,防止分叉發生。

ONT 的 vBFT 共識演算法提出了一種依靠可驗證隨機函式(VRF)來防止惡意分叉擴充套件的方法。網路首先基於 VRF 在共識網路中依次選擇出一輪共識的備選區塊提案節點集,區塊驗證節點集和區塊確認節點集,然後由選出的節點集完成共識。由於每個區塊都是由 VRF 確定節點的優先順序順序的,對於惡意產生的分叉,攻擊者很難持續維持自己的高優先順序(如果攻擊者沒有控制絕大多數股權的話),因此惡意產生的分叉將很快消亡,從而使 vBFT 擁有快速的狀態終局性。

然而我們發現 vBFT 中的 VRF 實現存在一個漏洞,導致私鑰為 0 的使用者的可對任意區塊資料生成相同的 vrfValue。具體的,vBFT 中的 vrf 是對由波士頓大學提出的 VRF 標準草稿 (hdl.handle.net/2144/29225) 的一個實現。具體在該草案的 5.1 和 5.2 章節中,我們可以看到證明生成,和隨機數計算的演算法。如圖:

image

漏洞在於 x=0 時候,此時從計算上 y 仍然為一個合法的公鑰,且能通過 vBFT 實現中 ValidatePublicKey 的校驗。gamma 為橢圓曲線上固定的點(無窮遠點)。即對任意輸入 alpha,該 vrf 產生的值為固定一個值。完全沒有隨機性。該問題可導致攻擊者利用固定 vrf 破壞共識演算法隨機性,從而長期控制節點選舉。

5.2 NEO dBFT 共識分叉

NEO 的 dBFT 共識機制,本質上可以看成是一個 POS+pBFT 方案。在原版 NEO 程式碼中,我們發現 NEO 和 ONT 在實現其 dBFT 共識機制的時候存在分叉問題。惡意的共識節點可以產生一個分叉塊,從而造成雙花的發生。具體細節可以參考我們之前的文章:《Analysis and Improvement of NEO’s dBFT Consensus Mechanism》(blogs.360.cn/post/NEO_dB…),在此我們不做贅述。

6

一種針對虛擬機器執行不一致雙花問題的高效減緩措施

對於校驗繞過之類的邏輯漏洞和共識機制問題產生的雙花漏洞,還是需要深入到業務邏輯中具體問題具體分析。這裡我們提出一種針對虛擬機器執行不一致的減緩措施。

一種簡單的解決虛擬機器執行不一致造成的雙花問題的方法是由出塊者將執行完交易後的全域性狀態 State_ 進行雜湊雜湊,然後將該雜湊打包到區塊中。普通節點在收到區塊後,將本地執行完交易後的狀態 State’_ 的雜湊雜湊與 State_ 的雜湊雜湊進行對比。如果相等,則說明沒有分叉產生。然而由於本地資料是先行增長的,所以每次對全域性狀態進行雜湊計算的開銷極大。針對這個問題,以太坊使用了 MekleTree 的結構來提高效能,同時應對分叉回滾問題。但以太坊的方案並不適用於採用其他資料結構儲存狀態資訊的區塊鏈專案。這裡我們提出一種新的解決方案,其工作流程如下:

  • 區塊生產者在區塊打包階段,將該區塊中所有的交易執行過程中的對資料庫的寫操作序列【write_db_1 write_db_2 …. write_db_n】記錄下來,並計算該序列的雜湊值 write_db_hash。

  • 普通節點收到新的區塊後,對區塊進行校驗。然後在虛擬機器中執行交易。同時本地記錄這些交易對資料庫的寫操作序列【write_db_1’ write_db_2’ …. write_db_n’】,然後計算 write_db_hash’。判斷其與 write_db_hash 是否相等。如果相等,則認為沒有不一致執行發生。如果不等,則拒絕對該寫操作序列進行 commit。

本方法的核心思路在於,智慧合約平臺虛擬機器執行不一致產生的原因在於:合約中各種功能函式和圖靈完備性的支援中,可能引入多種不確定因素,從而造成執行不一致。各種各樣複雜的小原因,可能導致這種不一致執行防不勝防。但是我們退一步看,雙花攻擊的本質是要對全域性狀態 State_ 進行修改,本質上就是一系列的簡單寫操作(簡單的寫操作往往並不會產生二義性)。要防止雙花,只需要對所有的寫操作序列進行匹配校驗便可。本地對這些寫操作進行匹配和記錄的開銷非常小,同時本地記錄這些寫操作序列,也方便應對分叉回滾等其他因素。

7

後記

在本文中,我們通過介紹我們發現的針對 EOS、NEO 等大公鏈平臺的多個雙花攻擊漏洞的案例發現,總結出多種造成數字貨幣雙花攻擊的多種原因,並提出了一種通用的安全減緩措施。從上面的分析中,我們可以看到,區塊鏈安全目前的形式仍然十分嚴峻。各種大公鏈專案實際上都產生過能夠產生雙花攻擊之類的嚴重安全問題。我們的職業道德經受住了無數次的考驗。 make a billion or work hard? Of course, work hard. 不過幸運的是,在幾個月的區塊鏈安全研究中,我們收到了來自各個專案方價值超過 30 萬美金的數字貨幣漏洞報告獎勵,感謝。hard work pay off。

本文中所有提到的漏洞均已被修復。在漏洞報告和解決的過程中我們發現 EOS 與 NEO 專案方對於安全問題處理專業高效,反應及時。專案安全性也一步一步得到完善。我們會繼續關注和研究區塊鏈相關技術的安全問題,推動區塊鏈技術向前發展。

內容來源:360區塊鏈實驗室

作者:Zhiniang Peng

課程推薦

image

相關文章