移花接木盜走 200 萬美元 — Revest Finance 被駭分析

2022 年 3 月 27 日，據慢霧區消息，Revest Finance 的 Revest 合約遭到駭客攻擊，駭客盜取了近 770 萬枚 ECO、579 枚 LYXe、近 7.15 億枚 BLOCKS 以及超 35 萬枚 RENA。慢霧安全團隊第一時間介入分析，並將結果分享如下。

Revest Finance 提出了一種新協議，用於將可替代的 ERC-20 代幣作為不可替代的代幣化金融工具進行打包、轉移和存儲，利用 ERC-1155 非可替代代幣（NFT）標準來簡化訪問和商業通用性。使用該產品，資產的所有權可以以不影響資產價值的方式進行交易，從而形成一個新的商業模式。透過有針對性的用例發現該協議的機制、治理和貨幣化。

以下是本次攻擊涉及的相關地址：

攻擊者地址：

https://etherscan.io/address/0xef967ece5322c0d7d26dab41778acb55ce5bd58b

攻擊合約：

https://etherscan.io/address/0xb480ac726528d1c195cd3bb32f19c92e8d928519

被攻擊合約：

https://etherscan.io/address/0x2320a28f52334d62622cc2eafa15de55f9987ed9#code

攻擊交易：

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

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

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

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

攻擊核心點

在被攻擊的 Revest 合約中，用戶調用 mintAddressLock 函數來將一定數量的 ERC-20 代幣存入 Revest Smart Vault 時，就會創建 FNFT。該 NFT 代表了用戶擁有的代幣資產數額，後續可以調用 withdrawFNFT 函數將代幣贖回。

攻擊核心點就在於攻擊者利用 ERC1155 標準鑄造 NFT 時會調用接受者地址的 onERC1155Received 函數，因此攻擊者利用該點回調重入了 Revest 合約中的 depositAdditionalToFNFT 函數，該函數會鑄造一個新的 NFT，接著會調用 tokenVault 合約的 handleMultipleDeposits 函數記錄新的 NFT 的訊息，而handleMultipleDeposits 函數中缺少了對該新鑄造的 NFT 是否存在的判斷，故此攻擊者利用重入修改了已經鑄造過的 NFT 的訊息，而用戶鑄造 NFT 打入 ERC20 資產代幣的流程是在重入操作之前的，故此用戶無需打入 ERC20 代幣就成功鑄造了代表自己具有 360,001 枚 ERC20 代幣資產的 NFT。

具體細節分析

此處拿獲取 RENA 代幣的攻擊進行分析，其他幾個攻擊手法一致，不做過多贅述。

1. 攻擊者首先從 Uniswap 池子中閃電貸借出 2 枚 RENA 代幣

2. 接著調用 Revest 合約中的 mintAddressLock 函數，傳入 quantities 為 2，該函數進行加鎖操作後會調用doMint 函數來鑄造 NFT。

在 doMint 函數中，會調用 tokenVault 合約的 createFNFT 函數記錄所鑄造的 NFT 函數訊息，接著用戶給tokenVault 合約轉帳相應的 ERC20 代幣，最後調用 FNFTHandler 合約中的 mint 函數來發放 NFT。

所鑄造的 NFT 的 fnftId 為 1027，所記錄的該 NFT 相關訊息如下：

因為 depositAmount 為 0，故此 NFT 代表用戶擁有的 ERC20 代幣資產為 0，故無需轉相關資產代幣給合約。

3. 再次調用 Revest 合約中的 mintAddressLock 函數，傳入 quantities 為 360000，與上面相同的步驟調用 doMint 進行鑄造 NFT，所鑄造的 NFT 的 fnftId 為 1028，記錄的 NFT 訊息如下：

因為 depositAmount 為 0，故仍然無需轉帳代幣資產給 tokenVault，但是與之前不同的是，這一次鑄造 NFT 的操作中，因為在調用 FNFTHandler 合約的 mint 函數時會調用_doSafeTransferAcceptanceCheck 函數。

該函數會調用攻擊合約的 onERC1155Received 函數，故此攻擊者利用攻擊合約中的重寫的onERC1155Received 函數回調重入了 Revest 合約的 depositAdditionalToFNFT 函數。

在 depositAdditionalToFNFT 函數需要傳入指定的fnftId（此處是1027）、NFT 數量 quantity（此處是 1）與單個 NFT 中需要存款的資產數額 amount（此處是1），該函數會 burn 掉傳入的fnftId 的指定數量的 NFT，接著用戶轉入指定數量的 ERC20 代幣資產並 mint 新的 NFT，需要轉帳的數量是 quantity * amount 為 1，最後調用 tokenVault 合約中的 handleMultipleDeposits 記錄新的 NFT 的存款數量為上面傳入指定 fnftId 的 NFT 的 depositAmount 值 + 傳入的 amount 的值。

而在 handleMultipleDeposits 函數 mint 新的 NFT 時沒有判斷該 NFT 的訊息是否在 tokenVault 合約中存在，故此攻擊者利用該問題直接修改了 1,028 號 NFT 的訊息，使得該 NFT 雖然在doMint 操作時第一次記錄的 depositAmount 為 0，但是在重入後卻修改成了 1 。