By：yudan@慢霧安全團隊

據慢霧區消息，2021 年06 月16 日，以太坊DeFi 項目Alchemix 的alETH 合約疑似出現安全問題。 17 日，Alchemix 發布了事故分析報告，慢霧安全團隊迅速介入分析，並在官方分析報告的基礎上梳理了本次事件的整個脈絡和核心關鍵點，供大家參考。

太長不看系列

本次分析文章很長。這裡先說結論，方便大家有個大概的理解。本次事故的主要原因在於Alchemix 通過transmuter 添加了3次vault，導致收益信息記錄在了一個錯誤的元素上，而在調用transmuter 的harvest 函數時也沒有傳入正確的index 值，導致通過錯誤的元素獲取了錯誤的收益，將錯誤的4300 ETH 的收益發送到adapter 合約，幫助用戶償還了alETH 的貸款，造成收益增多的問題，導致了悲劇。

核心分析——Round 1

根據官方發布的事故分析報告，本次事故的原因是官方的alETH 的部署腳本意外地創建了額外的vaults，導致Alchemix 使用了vaults 數組中錯誤的索引併計算出了錯誤的獎勵，導致transmuter 把所有的獎勵用於償還了用戶的所有負債。我知道單單是這句簡短的分析讓人有點雲裡霧裡，摸不著頭腦，所以我們只能把目標放在官方給出的交易中，看看能不能找到真相。

根據官方給出的交易，通過ethtx.info 分析工具進行分析，我們不難發現，這筆交易調用了AlchemistEth 合約的harvest 函數，並且傳入了_vaultId=0 這個參數，最後返回了

'4308144937764982868765' 和'4308144937764982866415' 這兩個值。

為了更加了解harvest 函數的作用，我們需要對整個函數進行分析：

不難發現，harvest 函數其實包含兩個重要的操作，分別是收穫獎勵和將獎勵分發給transmuter 合約。其中vault 是一個library 庫合約，其中的harvest 邏輯實現如下：

通過代碼分析不難發現，vault 庫合約的harvest 函數其實是檢查了外部的adapter 的總的資金量，然後根據adapter 中的資金量減去用戶的充值數量計算出收益的部分。

這裡我們可以將這個adapter 理解為一個策略池，用於管理用戶的資金和收益。然後我們回到用戶一開始的AlchemistEth 合約中的harvest 函數,發現返回的'4308144937764982868765' 和

'4308144937764982866415' 這兩個值其實對應的就是vault 庫合約的harvest 函數計算出的需要提現的代幣數量和從adapter (策略池) 中取回的代幣的數量。由於這個adapter 對應的收益代幣是WETH，精度為18 位，那麼 '4308144937764982866415' 這個數值換算過來就是'4308.144937764982866415' 個WETH。

也就是說，本次harvest 操作，收益了超過4300 個ETH 的收益，然後這個收益在下一步中通過_distributeToTransmuter 函數給到了transmuter 合約進行分發，我們看下分發過程中的邏輯是怎樣的：

_distributeToTransmuter 函數的邏輯只有簡單的3 行，我們主要關注的是最後的外部調用—— lowerHashMinted 函數。該函數所對應的xtoken 在這裡指的是alETH 本身。因為alETH 本身是用戶通過借貸借出來的，所以lowerHashMinted 這裡的操作其實是使用harvest 的收益將alETH 總的貸出數量減少了，從而減少了每個用戶的貸款。總結來說就是用harvest 4300 ETH 的收益償還用戶的alETH 貸款。

打個小總結

這裡先總結下這個流程，就是AlchemistEth 合約通過harvest 函數，得到了4300 ETH 的收益，並將這個收益分發出去了，用於償還用戶的alETH 貸款，導致了我們看到的情況—— 已經貸出alETH的用戶在不需要還款的情況下就可以拿回他們質押的ETH。那究竟是為什麼，會有這4300 ETH 的收益呢？這多出來的4300 ETH 的收益是怎麼來的？針對這個問題，我們開始下一輪的分析。

核心分析——Round 2

要了解為什麼會多出來4300 ETH，就必須了解AlchemistEth 的資金存儲過程。在AlchemistEth 合約中，合約總的充值情況是使用Vault library 庫的Data 結構體進行記錄的，然後通過flushActiveVault 函數更新對應的充值數量(totalDeposit)。

然後depositAll 函數會將充值的代幣金額打到對應的adapter(策略池) 中，那麼在下一次harvest 的時候，通過adapter(策略池) 獲取的totalValue，就會是用戶的本金加上策略池的收益。為了計算收益過程中的本金部分，我們對官方給出的交易進行debug，發現本金僅為9000 ETH，從adapter 獲取的收益加上本金共有13000 ETH，也就是說9000 ETH 的本金產生了4300 ETH 的收益。

但是，按照上面分析的邏輯，用戶的本金是不會產生那麼大的收益的，問題肯定是出在了adapter 獲取的totalValue。也就是說adapter 不止只有AlchemistEth 充值代幣，還存在其他的收益渠道。為了驗證我們的想法，慢霧安全團隊分析了adapter 的所有代幣收入，果然發現了一筆異常的轉入行為，並且金額也能剛好對上多出的4300 ETH 的收益。也就是說，問題就在這裡了。

通過查看交易數據，發現這是一筆調用harvest 操作的交易，調用的合約是transmuter 合約：

也就是說，是這個harvest 函數出問題了，harvest 函數的邏輯如下：

同樣是調用了vault 的harvest 函數，熟悉的配方，熟悉的味道。我們再次進行debug，發現一個驚人的事實—— 在進行收益的時候，vault 的totalDeposit 竟然為0，導致4300 ETH 的收益直接分發給了adapter，導致了adapter 獲取的totalValue 錯誤了，多了4300 個ETH ，原因就是在這裡。

到了這裡，我們已經很接近真相了，剩下要解決的就是為什麼totalDeposit 會為0？我們查詢了transmuter 合約中能改變totalDeposit 的地方，發現只有_plantOrRecallExcessFunds 函數可以改變這個值，而這個函數上層調用的又是distribute 函數。而transmuter 合約的distribute 函數是AlchemistEth 合約在收益的時候進行調用的。也就是說本身的流程應該是：

1. AlchemistEth 合約調用harvest 進行收益

2. AlchemistEth 合約調用transmuter 合約的distribute 函數記錄收益情況，並把收益部分給adapter

3. adapter 收到了transmuter 的收益，根據收益償還用戶的alETH 的貸款

但是問題就出在了_plantOrRecallExcessFunds 函數中。由於在記錄充值信息的時候，用的是_vaults.last() 來獲取最新的vault，所以其實充值信息疊加在了最後一個元素上。但是項目方調用了三次setActiveVault 函數，所以其實充值信息是疊加到了_vaults 數組的3 號元素，也就是index 為2 的vault 元素上。但是在transmuter 合約在harvest 的時候傳入的_vaultId 卻是0，0 號元素是沒有任何充值記錄的，所以transmuter 合約就誤將所有的收益都給了adapter 了。導致了悲劇的發生。

總結

到這裡，整個事情已經變得很清晰了，Alchemix 項目方由於某種原因，通過transmuter 添加了3 次vault，導致收益信息記錄在了一個錯誤的元素上，而在調用transmuter 的harvest 函數時也沒有傳入正確的index 值，導致通過錯誤的元素獲取了錯誤的收益，錯誤收益被發送到adapter 合約，造成收益增多，導致了悲劇。

慢霧安全團隊在此提醒，DeFi 是一個複雜的系統，在進行DeFi 操作的時候，要記得檢查好業務邏輯中的每一個流程，防止意外的發生，在必要的時候可以聯繫專業的安全團隊進行專業的安全審計，防止事故的發生。

【參考鏈接】

官方事故分析報告：

https://forum.alchemix.fi/public/d/137-incident-report-06162021

收益計算錯誤交易：https://etherscan.io/tx/0x3cc071f9f40294bb250fc7b9aa6b2d7e6ca5707ce4d6d222157d7a0feef618b3