移花接木：Revest Finance 被黑分析

By：九九@慢霧安全團隊

2022 年 03 月 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 代幣就成功鑄造了代表自己具有 360001 枚 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 合約中存在，故此攻擊者利用該問題直接修改了 1028 號 NFT 的信息，使得該 NFT 雖然在 doMint 操作時第一次記錄的 depositAmount 為 0，但是在重入後卻修改成了 1

4. 最後調用 withdrawFNFT 函數進行提取 NFT 中所代表的 ERC20 代幣資產

該函數燃燒掉指定的 NFT 後，會調用 tokenVault 合約中的 withdrawToken 函數進行提款

因為 depositAmount 在回調後被修改了為了 1，故此最後提款的 RENA 數量計算出來約為 360000 枚

5. 攻擊者歸還閃電貸後獲利離場

總結

本次攻擊事件是由於在 tokenVault 合約中的 handleMultipleDeposits 函數中沒有判斷該新鑄造的 NFT 是否存在，故此攻擊者利用該點直接修改了已經鑄造過的 NFT 的信息，並且在 Revest 合約中關鍵的函數沒有做重入鎖的限制，導致了被回調利用。慢霧安全團隊建議在進行鑄造 NFT 等敏感操作時需增加對 NFT 是否已經存在的判斷，且在合約關鍵函數中必須添加重入鎖的限制，避免再次出現此類問題。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。