10月6日，BNB Chain推特發文稱,由於平台上的異常攻擊, 現在BSC網絡已經暫停服務. 攻擊者利用跨鏈橋BSC Token Hub (BSC Token Hub 是BNB 信標鍊和BNB 鏈之間的跨鏈橋) 的漏洞, 套利了大約$70 billion - $80 billion 。
交易地址: Transaction Address
https://bscscan.com/tx/0xebf83628ba893d35b496121fb8201666b8e09f3cbadf0e269162baa72efe3b8b
錢包地址: Wallet Address
https://bscscan.com/address/0x489a8756c18c0b8b24ec2a2b9ff3d4d447f79bec
Hyperlab 安全實驗室根據@samczsun的分析，此次攻擊發生的要原因在於
BSC 跨鏈橋的驗證方式存在BUG，該BUG 可能允許攻擊者偽造任意消息；本次攻擊中，攻擊者偽造信息通過了BSC 跨鏈橋的驗證，使跨鏈橋向攻擊者地址發送了200 萬枚BNB。
幸運的是，攻擊者顯然沒有足夠快地將代幣轉移到鏈外，因為BNB Chain在大部分代幣被轉移之前就凍結了所有交易活動。
Hyperlab 安全實驗室提醒: 當前區塊鏈行業發展迅猛，跨鏈技術的發展使得用戶對於不同區塊鏈之間的互操作成為可能。跨鏈橋作為應用範圍最廣的跨鏈解決方案（大多數雙向跨鏈橋使用lock 和mint 以及burn 和mint 模型的組合），同時成為了一個非常吸引力的目標（對於對黑客來說）。後端漏洞，多重簽名隱患，智能合約漏洞是三種跨鏈橋常見的安全風險。此次BSC 跨鏈橋的攻擊事件也是針對跨鏈合約協議漏洞（驗證方式）而發起的。這讓人不由地聯想到了另一起跨鏈橋攻擊事件：由於執行不善的智能合約更新未能正確驗證交易輸入，Nomad被盜竊了近$190M。總的來說，針對合約的攻擊向量很難緩解。 Hyperlab建議採取更強大的安全審計來應對這些風險。協議開發人員需培養足夠的安全意識，充分了解跨鏈橋設計的攻擊風險，並更加關注代碼底層的邏輯細節。
附錄
@samczsun的分析詳情如下: (https://twitter.com/samczsun/status/1578175778314780673原文帖鏈接)
起初，以為@VenusProtocol 又一次被黑了。然而, 後面證實攻擊者將2億多美元存入Venus。
攻擊者向Binance Bridge發送100萬BNB兩次。
首先比較了攻擊者的交易和合法提款的交易。注意到的一點是，攻擊者使用的高度總是相同的- 110217401。合法取款人使用的高度要大得多，如270822321
同時，攻擊者的證明明顯比合法提款的證明短。攻擊者已經找到了一種方法來偽造該特定區塊的證明--110217401。接下來須弄清楚這些證明是如何工作的
在Binance中，有一個特殊的預編譯合約，用於驗證IAVL樹, 如下圖所示
基本上，當你驗證一個IAVL樹時，你指定一個"操作"列表。 Binance Bridge通常期望其中的兩個：一個"IAVL:V "操作和一個"multistore "操作。以下是它們的實現方式
(https://github.com/cosmos/iavl/blob/de0740903a67b624d887f9055d4c60175dcfa758/proof_iavl_value.go#L61-L82)
為了偽造一個證明，我們需要兩個操作都成功，而且我們需要最後一個操作（multistore）返回一個固定值（指定塊的哈希值：110217401）。
根據下圖的實現代碼，要操縱根哈希值是不可能的，或者至少是非常困難的
"multistore "操作的輸入值是"iavl:v "操作的輸出值。這意味著我們要在這里以某種方式控制根變量，同時還要傳遞驗證值
根哈希值是通過COMPUTEHASH的函數金進行激素. 它遞歸到每個路徑和葉子上，做了一堆散列，實際上實現細節並不重要
(https://github.com/cosmos/iavl/blob/de0740903a67b624d887f9055d4c60175dcfa758/proof_range.go#L237-L290)
重要的是，由於哈希函數的工作方式，我們基本上可以肯定地說，任何（路徑，Nleaf）對都會產生一個唯一的哈希值。如果我們想偽造一個證明，這些就需要保持不變。
在合法交易中證明的佈局方式中，我們看到它有一個很長的路徑，沒有內部節點，只有一個葉子節點。這個葉子節點包含了我們的惡意有效載荷的哈希值! 如果我們不能修改這個葉子節點，那麼我們就需要添加一個新的葉子節點
如果我們讓添加一個新的葉子節點, 那麼我們也同樣需要添加一個與之匹配的內部節點
我們怎樣才能讓COMPUTEHASH返回我們想要的根哈希值？請注意，最終我們需要一個路徑包含一個非零的右邊哈希值。當我們找到一個這樣的路徑時，我們斷言它與中間的根哈希值相匹配
讓我們對代碼進行一下分析，以便弄清楚我們需要什麼哈希值
剩下的就是把這一切放在一起。我們將採取一個合法的證明，並對其進行修改，以便。
1）我們為我們的偽造的有效載荷添加一個新的葉子
2) 我們添加一個空白的內部節點以滿足驗證者的要求
3) 我們對我們的葉子進行調整，使其提前退出正確的根哈希值
(https://gist.github.com/samczsun/8635f49fac0ec66a5a61080835cae3db)
(值得注意的是，這並不是攻擊者使用的確切方法。他們的證明路徑要短得多，我不確定他們到底是如何生成的。然而，該漏洞的其餘部分是相同的，我相信展示如何從頭開始構建它是有價值的)
總之，Binance Bridge驗證證明的方式有一個錯誤，可能允許攻擊者偽造任意信息。幸運的是，這裡的攻擊者只偽造了兩條信息，但損失可能會更大。
APP 
