BCH 升級攻擊事件安全分析
節點專欄
8天前
2541

5 月 15 日 BCH 升級遭到攻擊,慢霧安全團隊及時跟進,並在社區里注意到相關分析工作,通過交流將此分析文完整轉載於此。這是一場真實攻擊,從行為上分析來看確實預謀已久,但 BCH 響應很及時,成功化解了一場安全危機。


螢幕快照 2019-05-16 下午16.55.56 下午.png


BCH 的 5 月 15日 升級遭到攻擊,導致節點報出 too many sigops 錯誤。經分析,攻擊載荷為一個精確構造的 P2SH Transaction,利用了 BCH 去年 11 月升級引入的 OP_CHECKDATASIG 操作碼。

攻擊導致了礦工節點無法打包,BCH 方面通過類似於空塊攻擊的方式,緊急挖出十個空塊以觸發滾動檢查點保證升級。攻擊發生約 1 小時後,BCH 礦池上線緊急修復後的代碼成功繼續出塊。

不過同時也有人觀察到,在 582698 區塊高度,有礦工挖出了哈希結尾為 6bf418af 的區塊,大小 139369 字節。但隨後該區塊被 10 分鐘後 BTC.top 挖出的哈希結尾為 449e2bb4 區塊所重組。或許是一次誤傷,不過可見 BCH 對於升級防守之嚴密。




攻擊原理分析


攻擊載荷

捕捉到的攻擊載荷 TXID 為

4c83ab55623633c86ec711b3d68ccdea506b228178ff1533f287ab744b006c44

其內容點擊閱讀原文查看。

該攻擊載荷由 1334 個 Input 構成,每一個 Input 均是 P2SH 格式。

其內容為


OP_FALSE OP_IF OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_CHECKDATASIG OP_14 OP_CHECKDATASIG OP_ENDIF OP_TRUE



可見其中包含 15 個 OP_CHECKDATASIG


該攻擊載荷利用了一個 CORE 曾經幫 ABC 修復,但未完全修復的漏洞,製造了組塊和驗證之間的差異,從而導致礦工組出的區塊不被節點接受。



漏洞背景


OP_CHECKDATASIG 是一種橢圓曲線簽名校驗指令(SigOP),這類指令由於需要進行橢圓曲線運算,執行開銷遠高於其他指令。因此在節點代碼中,對於這類指令的數量做出了限制,以避免拒絕服務攻擊。


相關代碼位置:

https://github.com/Bitcoin-ABC/bitcoin-abc/blob/f27da0752c0a3b7382df54a65ca3cf1c3629aad4/src/consensus/consensus.h#L27



螢幕快照 2019-05-16 下午17.00.27 下午.png



漏洞原理

細心的話,你已經發現了,攻擊載荷的 SigOP 數量為 1334 * 15 = 20010,這個攻擊載荷 TX 會被節點拒絕,報錯即是 too many sigops,這是導致節點拒絕包含該 TX 的區塊的原因。


相關代碼位置:

https://github.com/Bitcoin-ABC/bitcoin-abc/blob/f27da0752c0a3b7382df54a65ca3cf1c3629aad4/src/validation.cpp#L1936



螢幕快照 2019-05-16 下午17.01.39 下午.png



然而在組塊時為什麼沒有拒絕這個 TX 呢?我們可以在 Bitcoin-ABC 的補丁中發現端倪。

補丁位置:
https://reviews.bitcoinabc.org/D3053

相關代碼位置:

https://github.com/Bitcoin-ABC/bitcoin-abc/blob/f27da0752c0a3b7382df54a65ca3cf1c3629aad4/src/validation.cpp#L592



螢幕快照 2019-05-16 下午17.03.09 下午.png



所在的函數為:AcceptToMemoryPoolWorker

可見原代碼組塊過程中在計算 Transaction 中的 SigOP 數量時,錯誤地使用了 STANDARD_SCRIPT_VERIFY_FLAGS,而非 STANDARD_CHECKDATASIG_VERIFY_FLAGS。

這兩個標誌有什麼區別呢?

在 policy 中我們可以找到他們。

相關代碼位置:

https://github.com/Bitcoin-ABC/bitcoin-abc/blob/f27da0752c0a3b7382df54a65ca3cf1c3629aad4/src/policy/policy.h#L108



螢幕快照 2019-05-16 下午17.04.26 下午.png



所以我們可以見到,當僅使用了 STANDARD_SCRIPT_VERIFY_FLAGS 時,計算腳本中 SigOP 數量時,是不包含 OP_CHECKDATASIG 的。所以這個包含 20010 個 SigOP 的攻擊載荷,在組塊時,統計出來的 SigOP 數量為零。


因此,攻擊載荷會在礦工組塊的時候被包含進區塊中,然而,由於其他代碼正確地統計了 SigOP,節點會拒絕該區塊,這導致了 BCH 無法出塊。




總結


攻擊者利用了 BCH 引入 OP_CHECKDATASIG 時產生的,又未完全修復的漏洞,巧妙地構造了攻擊載荷。攻擊者應該高度瞭解客戶端代碼,並熟悉 OP_CHECKDATASIG 漏洞。


廈門慢霧科技有限公司,專注區塊鏈生態安全,總部位於廈門,由一支擁有十多年一線網絡安全攻防實戰的團隊創建,團隊成員曾為 Google、微軟、W3C、公安部、騰訊、阿里、百度等輸出過安全能力,團隊成員多項成果也曾進入過 Black Hat 等全球黑客大會。核心服務包括:安全審計、安全顧問、防禦部署、威脅情報(BTI)、漏洞賞金等。
新聞排行
熱門新聞

© blocktimes——專業的區塊鏈媒體平臺