2024 年 6 月 2 日，Velocore 的 CPMM 池遭受攻擊，造成約 680 萬美元的財務損失。此次攻擊的根本原因是ConstantProductPool中計算交易費的邏輯錯誤，以及整數下溢。

概述

• 攻擊者的錢包：0x8cdc37ed79c5ef116b9dc2a53cb86acaca3716bf

• 攻擊者的合約：0xb7f6354b2cfd3018b3261fbc63248a56a24ae91a

• 攻擊交易： 0xed11d5b013bf3296b1507da38b7bcb97845dd037d33d3d1b0c5e763889cdbed1

漏洞分析

在技​​術文檔中，Velocore 建議用戶直接與Vault 合約交互來執行操作。從用戶的角度來看，最重要的函數是Vault.execute() 。此功能允許用戶交換、質押、轉換或投票，而無需知道內部池、路由器ETC的地址。此外，它支持批處理操作，允許用戶在單個交易中執行多個操作。

代幣交換操作的典型執行流程如下：

1. 用戶使用tokenRef數組和操作列表（ ops ）調用SwapFacet.execute() 。

2. 然後， SwapFacet調用其內部的_execute()函數來處理用戶的操作。

   1. _execute()遍歷ops並根據其類型處理每個操作。

   2. 如果當前操作是交換請求， _execute()會調用相應池的velocore__execute()來模擬交換並返回餘額增量。然後它調用_verifyAndApplyDelta()來驗證和應用結果。

3. 返回外部execute()函數後，它會檢查用戶的餘額並處理向用戶錢包的轉賬或從用戶錢包的提款。

Velocore 中有兩種類型的池：易變池（CPMM）和穩定池（Wombat 池）。被攻擊的池是一個易變池，因此我們回顧了ConstantProductPool.sol中的實現。

ConstantProductPool中的velocore__execute()函數負責計算交換結果，每當用戶在 Velocore 上發起交換時， SwapFacet合約都會調用該函數。然而，這個函數有幾個缺陷：

1. 缺少調用者驗證： velocore__execute()應僅從 Vault 合約（例如本例中的SwapFacet ）調用，但缺少此驗證。這允許任何人調用該函數，從而引入潛在的攻擊媒介。

2. feeMultiplier無上限： feeMultiplier無上限檢查。邏輯表明， feeMultiplier每次調用velocore__execute()時都會增加，並且只有在The Block時間戳發生變化時（第三個代碼塊）才會重置為1e9 。由於feeMultiplier用於計算交易費用（第一個代碼塊中的effectiveFee1e9 ），因此當feeMultiplier超過 3.33e11 時， effectiveFee1e9將至少為3.33e11 * 3e6 / 1e9 = 1e9 ，這意味著費用超過 100% 。這會嚴重影響unaccountedFeeAsGrowth1e18 ，從而導致requestedGrowth1e18發生變化，最終影響池的餘額。

3. 未經檢查的算法： unaccountedFeeAsGrowth1e18的計算被放置在未經檢查的塊（第二個代碼塊）內。結合第二個缺陷，表達式1e18 - ((1e18 - k) * effectiveFee1e9) / 1e9可能會下溢，從而導致意外行為。

通過以上信息，我們現在可以瞭解黑客的策略：

1. 操縱feeMultiplier ：黑客直接多次調用velocore__execute()來人為提高feeMultiplier ，導致effectiveFee1e9超過 100%。這是在以下步驟中執行整數溢出攻擊所必需的。在實際攻擊中， velocore__execute()被調用了三次，參數相同。通過測試，我們通過僅調用velocore__execute()一次並使用略有不同的參數實現了相同的效果。重要的是要注意，這不會立即影響池餘額，因為velocore__execute()不執行任何轉移；它只更新feeMultiplier 。

2. 耗盡USDC流動性：黑客利用閃電貸功能，試圖使用 LP 代幣從池中提取幾乎所有USDC ，造成USDC稀缺，並顯著影響兌換價格。在實際攻擊中，黑客執行了三次操作，每次耗盡了池中 98% 的USDC 。在我們的測試中，我們發現我們可以在一次操作中實現相同的結果，結果沒有差異。

3. 利用整數下溢：最後，黑客進行了另一次單代幣提取，選擇了觸發整數下溢的精確數量的USDC ，導致rpow()返回異常大的值。這導致礦池計算錯誤，向黑客獎勵 LP 代幣，而不是執行正確的提取。這使得黑客擁有足夠的 LP 代幣來償還他們在前面步驟中借入的金額。

結論

儘管ConstantProductPool SwapFacet邏輯來更新池的餘額並執行代幣轉移。但是， ConstantProductPool使用其自己的內部變量（獨立於SwapFacet ）計算增量並僅返回結果。這種設計造成了合約之間的脫節，導致溝通不暢，並最終導致漏洞利用。為了減輕未來的風險，我們建議 Velocore 重構其代碼庫，以在內部組件之間建立清晰而強大的邏輯。