Cobo 區塊鏈安全月報——盤點解析 1 月典型安全事件 – 幫助中心

跨鏈橋 Multichain 漏洞

1月18日知名跨鏈橋 Multichain（前身 Anyswap）發現並修復了一個針對 WETH, PERI, OMT, WBNB, MATIC, AVAX 共 6 種代幣有重要影響的漏洞。凡對 Multichain Router 授權過上述代幣的用戶均受影響，攻擊者可直接利用漏洞轉走用戶授權的代幣。根據 19 日的官方公告，由於部分用戶未及時取消授權，有約 445 WETH 被攻擊者盜走。

漏洞發生在 AnyswapV4Router 合約上的 anySwapOutUnderlyingWithPermit 函數中，由於函數對 Token 參數的合法性沒有校驗，攻擊者可傳入偽造的 Token 合約來代替原本官方的 AnyswapV1ERC20 Token。另一方面 WETH 等代幣合約沒有實現 permit 方法但是實現了 fallback 函數，因此在後續調用 permit 時不會發生 revert，可以繼續成功執行下去。最終導致攻擊者可以將受害者 approve 給 AnyswapV4Router 合約的 Token 盜走。

關鍵代碼如下：

function anySwapOutUnderlyingWithPermit(
        address from,
        address token,
        address to,
        uint amount,
        uint deadline,
        uint8 v,
        bytes32 r,
        bytes32 s,
        uint toChainID
    ) external {
        address _underlying = AnyswapV1ERC20(token).underlying();
        IERC20(_underlying).permit(from, address(this), amount, deadline, v, r, s);
        TransferHelper.safeTransferFrom(_underlying, from, token, amount);
        AnyswapV1ERC20(token).depositVault(amount, from);
        _anySwapOut(from, token, to, amount, toChainID);
    }

Cobo Comment

對於普通用戶來說，需要特別留意 Token 無限授權（ERC20 Infinite Approval ）所帶來的風險。授權盡可能保證只授權用到的 Token 數量，而不要使用默認的無限授權，避免節約了 gas 卻丟失了本金。對已有的無限授權要及時撤銷，查詢賬戶的授權情況可以使用 Etherscan 的工具 https://etherscan.io/tokenapprovalchecker 。

Reference

https://github.com/W2Ning/Anyswap_Vul_Poc

https://theblockbeats.info/news/28774

https://hackernoon.com/erc20-infinite-approval-a-battle-between-convenience-and-security-lk60350r

BSC 上的 DEX Crosswise 遭攻擊

1月18日 BSC 上的 DEX 項目 Crosswise 遭受攻擊，損失約 30 萬美金，並造成 CRSS Token 幣價閃崩。

問題是因 MasterChef 合約的 setTrustedForwarder 函數沒有正確進行權限校驗。當攻擊者修改了 TrustedForwarder 後，可以實現偽造 msg.sender 的效果，從而直接獲取到 MasterChef 的 owner 權限。然後再利用 owner 權限調用 set 函數設置 strategy 為攻擊者的惡意參數 0xccddce9f0e241a5ea0e76465c59e9f0c41727003 。修改 strategy 後通過少量 deposit 即可 withdraw 大量的 CRSS Token 獲利。

相關代碼如下：

function setTrustedForwarder(address _trustedForwarder) external {
    require(_trustedForwarder != address(0));
    trustedForwarder = _trustedForwarder;
    emit SetTrustedForwarder(_trustedForwarder);
}

function _msgSender() internal override virtual view returns (address payable ret) {
    if (msg.data.length >= 24 && isTrustedForwarder(msg.sender)) {
        // At this point we know that the sender is a trusted forwarder,
        // so we trust that the last bytes of msg.data are the verified sender address.
        // extract sender address from the end of msg.data
        assembly {
            ret := shr(96,calldataload(sub(calldatasize(),20)))
        }
    } else {
        return msg.sender;
    }
}

官方公告也承認這個漏洞過於明顯，似乎是開發者有意為之，其內部調查後開除了 4 個開發者。目前已經對鏈上數據進行了快照，後續將進行重新部署。官方 git 上已經開始進行整體的代碼審計，據稱後續會再聯合 Certik 進行審計。

Cobo Comment

此次攻擊針對的是 MasterChef 合約，其實不會直接盜取用戶的 LP 或者 CRSS token，但幣價大跌還是會讓持有 CRSS 的用戶造成實際的損失。查看官方 doc 上無法找到項目審計報告，此漏洞比較明顯，如果經過安全公司審計的話，很大概率可以暴露出來。對於個人投資者來說，未經過審計的項目還需謹慎。用戶的 LP 或者 CRSS token，但幣價大跌還是會讓持有 CRSS 的用戶造成實際的損失。查看官方 doc 上無法找到項目審計報告，此漏洞比較明顯，如果經過安全公司審計的話，很大概率可以暴露出來。對於個人投資者來說，未經過審計的項目還需謹慎。

Reference

https://twitter.com/peckshield/status/1483340900398895105

https://crosswise.medium.com/post-exploit-update-2a24c3370466

https://bscscan.com/address/0x70873211cb64c1d4ec027ea63a399a7d07c4085b#code

https://github.com/crosswise-finance/crosswise-code-review-1.1

Rari #90 即 Float Protocol Pool 遭受預言機操縱攻擊

1月15日，RariCapital 上的 90 號池即 Float Protocol 池遭受預言機操縱攻擊。

該池使用 Uniswap V3 FLOAT/USDC 交易對報價，而在攻擊發生之前幾天，FLOAT/USDC 池中流動性下降（只剩下約 ~$550k），低流動性給了攻擊者進行進行預言機操縱攻擊的機會。攻擊者使用 47 ETH（價值約 $120k）在池中使用 USDC 兌換 FLOAT，導致 FLOAT 報價升高。之後再使用 FLOAT 抵押到 Rari #90 池中借出其他資產實現獲利。攻擊手法與 2021 年 11 月發生的 Rari #23 池 Vesper Lend Beta 攻擊一致。

Cobo Comment

對於一些無法使用 ChainLink 預言機報價的小幣種，DeFi 合約中通常會使用 DEX 作報價。目前 UniswapV2/V3 延時報價雖然可以抵抗閃電貸攻擊，但無法抵抗真實的大資產操縱；而 TWAP 時間加權機製雖然可以在一定程度上提高操縱難度，但只能緩解不能根除。從開發者角度，可以考慮在合約中添加一定風控類代碼針對惡意報價進行檢查。對普通用戶而言，則要留意相關的流動性池，提防價格操縱風險。

Reference

https://twitter.com/FloatProtocol/status/1482184042850263042

https://medium.com/vesperfinance/on-the-vesper-lend-beta-rari-fuse-pool-23-exploit-9043ccd40ac9

DefiDollar 發現潛在攻擊

1月8日 DefiDollar Finance (@defidollar) 發推表示在 DUSD 合約中發現一個潛在漏洞，合約已經暫停，所有資金安全。據稱該漏洞可能是使用了區塊鏈監測系統自動發現的。其思路是監測鏈上 Tornado.Cash 轉賬到新地址並部署合約的行為（這是許多真實攻擊中的典型初期準備行為）。進一步通過對合約和相關交易的分析來發現潛在的攻擊行為，發現問題時將立刻通知相關項目方進行預防。有人已經在 Forta 上實現了類似的 Agent.

Cobo Comment

項目方可以考慮類似的方式，通過監測鏈上的新合約和內存池中的交易，對於可疑的合約或交易可以進行靜態分析或模擬執行，檢查是否會對自身項目關聯合約中的資產有不良影響。隨著區塊鏈攻防的升級，可以預見類似的監測告警系統將會越發成熟，當然攻擊者也會挖掘到更多 bypass 監測的攻擊方式。在傳統安全中攻防持續對抗的局面在區塊鏈安全中也將不斷重現。

Reference

https://twitter.com/AndreCronjeTech/status/1479778350084333574

https://connect.forta.network/agent/0x2fbec7dcd4eebf34c5b94d899109057eea3642a2400b7143e64873d453b7ba61

Rari pool #19 攻擊失敗

知名區塊鏈安全白帽 @samczsun 發布了針對 Rari #19（Index Coop Pool）的預警推文，但後面攻擊沒有實際發生。

攻擊手法與前面提到的 Float Protocol Rari #90 預言機攻擊是類似的。攻擊者在 Uniswap V3 將約 300 個 ETH 兌換成了 BED，實現對幣價的操縱。由於 Uniswap V2/V3 Oracle 都是在第二個區塊才會更新幣價，使攻擊者無法在一個交易內完成對幣價的操縱，從而可以對抗閃電貸攻擊。而當使用真實的大資金進行操縱時，攻擊者則需要至少等待到第二個區塊才能看到幣價的反應。由於 TWAP 的存在，通常攻擊者還需要多等待幾分鐘，以使幣價變得更加明顯。對於此次攻擊來說，攻擊者也確實是這樣做的。然而尷尬的是，在第二個區塊出現了疑似套利機器人的存在，此地址在第二個區塊立刻將將手中的大量 BED 兌換成了 ETH，維持住了原本幣價的穩定。使得攻擊者無法繼續攻擊，並且還要承擔 swap 的 gas、手續費與大單交易滑點的損失。

Cobo Comment

Uniswap V2/V3 Oracle 雖然可以抗閃電貸攻擊，但是無法直接對抗大資金操縱。因此對於流動性較小的交易對，仍然存在預言機價格被操縱的風險。從攻擊者的角度看，要進行對 Uniswap V2/V3 Oracle 操縱攻擊，需要較高的攻擊成本，而且需要保證自己持有市場中大部分所操縱的池子的目標代幣，否則就會出現上面的情況，被其他持有目標代幣的大戶套利，最終偷雞不成蝕把米。

Reference

https://twitter.com/samczsun/status/1486243806739587076

OpenSea 前端漏洞

@PeckShield 發文稱 OpenSea 可能有前端問題，有用戶利用該問題獲利 347 ETH。這個漏洞可能與 @yakirrotem 披露的問題有關。

OpenSea 的交易架構是：

賣家發起 listing（相當於報價），這時用戶會對報價數據進行簽名，表示同意以設置的價格出售其 NFT。
這個簽名數據會保存在 OpenSea 的鏈下數據庫中，當買家在 OpenSea 上購買該 NFT 時，OpenSea 會把這個簽名數據上鏈驗證，通過後即可完成 NFT transfer，OpenSea 也會收取一部分手續費。
售出前，賣家也可以取消之前的 listing，被 cancel 的 listing 會在鏈上驗簽時失敗，從而不會被出售。

這裏存在的問題是，OpenSea 允許在原有 listing 不取消的情況下，再次發起 listing（目前該問題已經修復）。這時雖然 OpenSea UI 上已經看不到賣家舊的報價，但其實舊的 listing 依然存在並有效。攻擊者可以在 https://orders.rarible.com 中查詢到舊的 listing。由於 OpenSea 的 listing 並沒有交易 Nonce 機製，舊的 listing 依然是有效的。攻擊者可以通過舊的 listing 直接購買 NFT，並以新的價格售出。由於 NFT 有劇烈的價格波動，通過這種方式可以實現巨額套利。

https://etherscan.io/token/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d?a=9991#inventory 就是一例子：1 月 24日 BAYC 的 NFT 在 OpenSea 上先以 0.77 ETH 買入，又以 84.2 ETH 賣出。

Cobo Comment

普通用戶建議登錄 https://orders.rarible.com 查詢自己是否有舊的 listing，並立刻進行取消處理。更穩妥安全的方式是直接將 NFT 轉移到新地址上。

Reference

https://twitter.com/PeckShieldAlert/status/1485547426467364864

https://twitter.com/yakirrotem/status/1485559864948629512

Metamask 泄露個人 IP 漏洞

@alxlpsc 在 medium 上披露稱 Metamask 存在嚴重的隱私泄露問題。漏洞主要是利用了 MetaMask 自動加載 NFT 圖片 URL。基本的攻擊思路：攻擊者在可以將 NFT 的 URI 設置成自己可控的服務器網址，並將 NFT transfer 給目標賬戶；當用戶登錄 Metamask 時，Metamask 會自動掃描賬戶上所擁有的 NFT，並發起指向攻擊者服務器的 HTTP 請求；攻擊者則可以從訪問日誌中得到受害者的 IP 信息。

Cobo Comment

區塊鏈的匿名性主要來自鏈上地址與鏈下身份的剝離。如果能夠通過鏈上的地址確認鏈下身份，在區塊鏈場景下確實是比較嚴重的危害。在傳統安全中泄露主機 IP 通常不被認為是特別嚴重的問題（畢竟一條釣魚短信或者郵件就可能做到），但在主張匿名性的區塊鏈世界，隱私的重要程度會再上一個臺階。相信類似的，因安全場景不同而導致漏洞級別不同的情況，在區塊鏈這個相對較新的領域還會不斷出現。

Reference

https://medium.com/@alxlpsc/critical-privacy-vulnerability-getting-exposed-by-metamask-693c63c2ce94

wxBTRFLY 漏洞披露與修復

@immunefi 的白帽黑客發現了 wxBTRFLY Token 合約中存在嚴重漏洞。合約中的 transferFrom 函數沒有正確更新 recipient 的授權，並且會錯誤更新 msg.sender 的授權。

相關代碼如下：

function transferFrom(address sender, address recipient, uint256 amount) public virtual override onlyAuthorisedOperators returns (bool) {
  _transfer(sender, recipient, amount);
  _approve(sender, msg.sender, allowance(sender, recipient ).sub(amount, "ERC20: transfer amount exceeds allowance"));
  // 应该使用 allowance(sender, **msg.sender**)
  return true;
}

漏洞本身雖然嚴重但成因並不復雜（更像是開發者筆誤產出的），比較有意思的是官方的修復方式。由於合約本身不支持升級，因此無法直接更新合約代碼；合約不支持暫停，因此也沒法用快照 + 遷移的方式轉移用戶資產。最終官方的措施是自己發動了攻擊交易，將所有受漏洞影響用戶的資產轉移到了一個多簽錢包中。待後面部署新 Token 合約後會再行分配。

Cobo Comment

ERC20 Token 已經有比較成熟的代碼模板，wxBTRFLY 是在重寫 transferFrom 時出現的問題。這個問題如果有完善的單元測試應該會很容易發現，項目方可能在開發過程中是缺少完善的測試流程。

Reference

https://discord.com/invite/rpkPDR7pVV

https://twitter.com/redactedcartel/status/1482497468713611266?s=20

https://etherscan.io/tx/0xf0e4ccb4f88716fa5182da280abdb9ea10ec1c61cfc5bbe87e10bdde07c229d6

Qubit 跨鏈橋被攻擊

1 月 28 日，BSC 上的 DeFi 平臺 Qubit Finance 的跨鏈橋 QBridge 遭受攻擊，損失約 8000 萬美金。

跨鏈橋一種常見的實現形式是在源鏈的合約中抵押資產，並 emit event。由監聽節點捕捉 event，向目標鏈的跨鏈橋合約發起調用，mint 等量的資產。來源鏈上只要有 event 事件產生，跨鏈橋系統就會認為有跨鏈資產需要轉移。但如果源鏈上跨鏈橋合約代碼存在問題，就可能出現沒有資產抵押進跨鏈橋合約但仍 emit event 的情況，產生漏洞，造成目標鏈 Token 的錯誤增發。

QBridge 就存在這樣的問題。QBridge 支持抵押 ETH 和 ERC20 Token 兩類資產。由於以太坊的 ETH 作為 native 代幣，與 ERC20 Token 由兩套單獨的代碼處理。在源鏈抵押 Token 時，會調用 deposit 方法，在抵押時 ETH 應該調用 depositETH 方法。QBridge 將零地址作為 ETH 的標識。但是實現時沒有完善的校驗，導致合約處理 ETH 時仍使用 deposit 方法，相當於將 ETH 當成了合約地址為零地址的 Token 處理。在轉賬時使用 transferFrom 則相當於是對零地址進行合約調用。而以太坊底層設計上，對 EOA 地址發起合約調用會默認成功，不會 revert。以上條件結合起來，最終的情況就是雖然攻擊者在源鏈沒有抵押任何資產，但仍可以在目標鏈上 mint 出大量 qXETH，實現獲利。

Cobo Comment

目前區塊鏈行業中多鏈並存，跨鏈橋已經是重要的基礎設施。跨鏈橋本身由於要進行鏈上鏈下配合，整體復雜度要比普通 dapp 高上許多，因此更容易出現問題。同時跨鏈橋上通常會抵押大量的資產，如果可以非法轉移那麽獲利頗豐。各個跨鏈橋系統似乎成為了攻擊者們最近一兩月中的重點目標。

Reference

https://mp.weixin.qq.com/s/PLbuI9JFxyFRlDlj9rPvmQ

https://mp.weixin.qq.com/s/-kTsAs2WH5_4N4_3-XIxag

360000089854

跨鏈橋 Multichain 漏洞

BSC 上的 DEX Crosswise 遭攻擊

Rari #90 即 Float Protocol Pool 遭受預言機操縱攻擊

DefiDollar 發現潛在攻擊

Rari pool #19 攻擊失敗

OpenSea 前端漏洞

Metamask 泄露個人 IP 漏洞

wxBTRFLY 漏洞披露與修復

Qubit 跨鏈橋被攻擊