背景介紹

2025年2⽉21⽇晚,我們監測到⼀筆涉及Bybit交易所的重⼤安全事件。當晚02:16 UTC ,我們監測到Bybit Cold Wallet 發起⼀筆⼤額轉賬, https://etherscan.io/tx/0xb61413c495fdad6114a7aa863a00b2e3c28945979a108585b

轉出401,346 ETH 、8,000 mETH、90,375 stETH 和15,000 cmETH 價值約1.5 BillionUSD 。經過多⽅確認,確定這是⼀起針對Bybit 的攻擊。

背景知識

交易所錢包架構

通常,交易所能直接存取互聯⽹的錢包為熱錢包( Hot Wallet ),因為需要頻繁轉賬,通常熱錢包的私鑰都是在線的,⽽且熱錢包資⾦⼀般較少,只需要滿⾜交易所的⽇常流⽔即可。 ⽽交易所的冷錢包( Cold Wallet )⼀般存放著交易所的⼤部分資⾦,相當於交易所的企業帳戶。冷錢包只需要在特殊的條件下才會使⽤,例如:補充熱錢包資⾦等。所以,冷錢包⼀般都是離線錢包,不會直接接觸互聯⽹;⽽且絕⼤多數交易所使⽤的冷錢包都是多簽錢包( multisign wallet )。這次Bybit 的冷錢包也不例外,使⽤的是safe 公司的多簽錢包。

代理合約

因為區塊鏈上部署的智慧合約不可修改,但是相同通常會遇到業務變化的問題,所以催⽣出⼀種設計機制,就是代理合約。代理合約是⼀種設計模式,允許將智慧合約的業務邏輯和儲存資料分開。其核⼼機制是透過⼀個「代理合約」作為中間層,將⽤戶的交易請求轉送到邏輯合約執行,但最終狀態(資料和資產)保存在代理合約內。通常情況下代理合約分為transparent proxy ,UUPS , Beacon 等。其中最常⻅的就是Transparent Proxy 和UUPS 。所有的Proxy 合約都需要設定implementation ,也就是邏輯合約。

攻擊及事件分析

經過我們詳細分析,攻擊者的攻擊分為了3個階段。

階段1

攻擊者在2025-02-18 03:29:11 UTC 部署了⼀個攻擊合約0x96221423681A6d52E184D440a8eFCEbB105C7242x ,部署合約的交易為https://dferscan. 053ed98042febd489ef3d51a3ed3652d40 。後續我們稱為攻擊合約7242 。

隨後,攻擊者在2025-02-18 06:00:35 UTC ⼜部署了⼀個攻擊合約0xbDd077f651EBe7f7b3cE16fe5F2b025BE2969516 ,部署合約的交易為93120x231720x272020201720202720202000x 309a645c5a4fa9df1b4858634ae596ccc2aee5e 。後續我們稱為攻擊合約9516 。

階段2

攻擊者使Bybit 的三個多簽錢包簽署了⼀筆交易,交易哈希為https://etherscan.io/tx/0x46deef0f52e3a983b67abf4714448a41dd7ffd6d32d32da69d62081c68a41dd7ffd6d32d32da69d62081c687888我們詳細分析⼀下這筆交易。

零時科技 || Bybit 攻擊事件分析

透過交易的執⾏流,我們可以看出,這比交易其實很簡單。就是拿到了多簽錢包針對交易的簽名,然後調⽤Safe錢包執⾏這筆交易。執⾏的交易同樣也很簡單,就是調⽤了攻擊合約7242 的transfer 函數,然後transfer 函數的_to 為攻擊合約9516 ,_value 為0 。

那麼,我們透過反編譯看⼀下攻擊合約7242的邏輯。

零時科技 || Bybit 攻擊事件分析

隨後,我們看到創建好的Token 的owner 同樣也是launchpad 官網的智能合約。

我們可以看到,攻擊合約7242的transfer函數很簡單,就是將該合約的slot0 改為transfer 函數的第⼀個參數recipient 。接下來,我們繼續觀察執⾏流程。 ⾸先,safe 錢包的proxy 合約透過delegatecall 調⽤ safe 錢包的impl 合約,隨後, impl 合約⼜透過delegatecall 調⽤了攻擊合約transfer 函數。因為delegatecall 的原理是⽤調⽤者的上下⽂,執⾏被調⽤的代碼。所以,執⾏攻擊合約的上下⽂為safe 錢包的proxy 合約,所以修改後的slot0也為safe錢包proxy 合約的slot0 。我們繼續看⼀下safe 錢包的proxy 合約的代碼。

零時科技 || Bybit 攻擊事件分析

我們發現, safe 錢包的proxy 合約的slot0 為safe 錢包的邏輯合約位址。 ⼜因為攻擊合約7242 的transfer 函數的功能為修改slot0 。那麼,執⾏完上述的流程後,safe 錢包的邏輯合約地址已經被攻擊者修改為了攻擊合約9516 。 ⾄此,Bybit 的這個冷錢包已經完全被攻擊者接管。

階段3

攻擊者在接手了Bybit 的這個冷錢包之後,調⽤了攻擊合約9516 的函數sweepERC20 和sweepETH 將該冷錢包的所有ERC20 Token 和ETH 全部轉走。 ⾄此,攻擊完成。我們看⼀下sweepERC20 的具體實作。

零時科技 || Bybit 攻擊事件分析

其功能就是將指定的冷錢包中指定的token 餘額轉入⽬標錢包,攻擊者依次將冷錢包中的90 USDT ,

零時科技 || Bybit 攻擊事件分析

8,000 mETH

零時科技 || Bybit 攻擊事件分析

90,375 stETH

零時科技 || Bybit 攻擊事件分析

15,000 cmETH

零時科技 || Bybit 攻擊事件分析

依序轉走。接下來,我們看⼀下sweepETH 的具體實現,

零時科技 || Bybit 攻擊事件分析

可以看到,該函數的主要功能是轉走錢包中的所有ETH 到攻擊者指定的位址。攻擊者利⽤這個函數,將冷錢包的所有ETH 轉走,⾄此攻擊階段已經完成。

零時科技 || Bybit 攻擊事件分析

發現的攻擊技巧

我們在分析的過程中發現攻擊者的⼿法非常縝密,我們將詳細闡述我們在分析過程中的發現:

1. 攻擊者⾸先利⽤位址0x5C6120BA4C5B5E18DDcb9589e649e86EE6d540dD

零時科技 || Bybit 攻擊事件分析

創建了⼀個⽤於測試的safe 錢包,

零時科技 || Bybit 攻擊事件分析

接著,⼜將攻擊在鏈上進⾏了⼀遍演練,

零時科技 || Bybit 攻擊事件分析

我們可以看到該函數交易的執⾏流程,

零時科技 || Bybit 攻擊事件分析

隨後,同樣利⽤攻擊合約9516 的sweepERC20 和sweepETH 測試在⼀個區塊中提幣。

零時科技 || Bybit 攻擊事件分析

2. 攻擊合約7242 和攻擊合約9516 均有修改slot0 的功能,

零時科技 || Bybit 攻擊事件分析

零時科技 || Bybit 攻擊事件分析

攻擊者並沒有直接調⽤複雜的攻擊合約,攻擊合約9516 ,⽽是調⽤簡單的類似transparent proxy 的攻擊合約7242 ,修改冷錢包的impl 。據我們猜測,可能是攻擊者擔⼼調⽤的合約功能過於複雜可能會導致觸發未知的防護,或是引起相關⼈員的警覺。 ⽽且攻擊的函數命名也是極具迷惑性的transfer 。攻擊者在修改完冷錢包的impl 合約時,並沒有直接進⾏⼤額轉賬,⽽是⾸先轉了90 USDT 。後續才完成⼤額轉帳。

零時科技 || Bybit 攻擊事件分析

可以看到,攻擊者先轉帳了⼀筆很⼩的⾦額進⾏測試。為了防⽌意外發⽣,等成功上鍊後,才進⾏⼤額轉帳。我們可以看到,所有的⼤額轉帳均在⼀個區塊編號21895251 中完成。

未解之謎

為什麼多簽機制被攻擊者輕易突破?我們列出了⼏種可能:

1. ⾸先是safe 錢包的合約或前端遭受了供應鏈攻擊,據了解bybit 不僅僅是ETH 使⽤了safe,如果是這種情況使⽤ safe 的所有錢包均會被攻擊者掏空。 ⽽且事後safe 也發佈公告,經過深入調查,其前端、合約不存在供應鏈攻擊。

2. 多簽持有者之⼀被攻擊者突破,攻擊者利⽤其發起了⼀筆transfer 轉賬,其他⼈員沒有仔細審核變進⾏了簽名。我們分析,掌握如此⼤額的錢包的私鑰持有⼈,所進⾏的⼀切操作可能都需要進⾏溝通或者進⾏內部流程,所以應該不會出現不知道是什麼情況就進⾏簽名。

3. 多簽的所有持有者均被攻擊者突破,攻擊者利⽤所有多簽持有者進⾏簽名最後完成攻擊。

4. 多簽的UI界⾯被攻擊者針對性的修改,誤導了多簽持有⼈。

5. 攻擊者潛伏到內部的系統,發動了⼀套完整的流程。

⽬前,在沒有更多資訊揭露的狀態下,很難最終確定攻擊者使⽤的⽅法。但能確定的是,攻擊者是透過縝密的前期偵查、鏈上測試和實驗、到針對多簽持有⼈或者係統的複雜的攻擊,攻擊者非常精通鏈上和鏈下的攻擊⼿段。我們也期待後續bybit 能夠揭露更多的信息,我們也願意向bybit 提供相關的技術⽀持。

總結

在本次攻擊事件中, Bybit 交易所共損失15億美元,這次攻擊事件是史上損失最多的針對交易所的攻擊。其實,類似的攻擊還在印度交易所WarirX 中發⽣過。交易所由於擁有龐大的資⾦,往往是頂級攻擊者關注的⽬標,甚⾄會遭受國家⽀持的APT 攻擊。所以,交易所應該從多⽅⾯來提升安全級別,減少被攻擊的⻛險。但不限於,⽤於多簽的設備(計算機,移動設備)等離⽹;需要執⾏的交易先在本地進⾏模擬,來看是否符合預期;在整體運營和⽇常的內容流程中多次、多⽅進⾏驗證。最後,在Web3安全性中,沒有任何⼀種措施是sliver bullet 。需要在和攻擊者對抗中持續提升,才能立於不敗之地。