CertiK：Based智能合約出現漏洞 重新部署其一號池事件分析
“亡羊補牢，為時未晚”，這句話在生活中的大部分時候均適用。然而，在面臨網絡安全時，牢破也許就會造成無法挽回的損失。
在安全問題未造成不可彌補的損失前就被發現，或是一開始便做好萬全準備，才是身為區塊鏈從業者的安全第一要義。
北京時間8月14日下午，CertiK安全技術團隊發現DeFi匿名耕種項目Based官方宣布有攻擊者通過調用Based智能合約中的某一個函數，將一號池(Pool 1)凍結，同時宣布將重新部署其一號池。
官方發布推特稱，有黑客試圖將“Pool1”永久凍結，但嘗試失敗。而“Pool1”將繼續按計劃進行。
CertiK通過分析該智能合約，認為這次凍結Based項目一號池事件，是一次由于存在智能合約漏洞導致的事故。
事件經過
- Based團隊部署一號池智能合約，部署地址為0x77caF750cC58C148D47fD52DdDe43575AA179d1f。
- Based官方通過調用智能合約中的renounceOwnership函數來聲明智能合約所有者，但未進行智能合約初始化。
- 由于在Based智能合約中initialize函數被錯誤的設置為可以被外部調用，因此造成在初始化智能合約過程中，一號池的智能合約被外部攻擊者用錯誤的值初始化。
- 錯誤的初始化造成Based官方無法再次初始化一號池的智能合約，因此造成一號池被凍結，任何質押行為都無法完成。
- Based官方決定放棄該智能合約，重新部署一號池智能合約。
智能合約技術細節
(1) Based團隊在部署智能合約后，沒有及時的調用下圖的initialize函數來初始化智能合約的設置：
(2) 外部調用者利用Based團隊在部署和初始化智能合約之間的時間差，乘機調用了下圖中671行被錯誤設置調用范圍的initialize函數，搶先初始化了一號池的智能合約：
(3) 上圖兩個initialize函數都是由initializer的修飾符修飾。根據其中代碼，如果調用了其中一個initialize函數，另外一個initialize函數就無法被調用。initializer修飾符代碼如下圖所示，這造成了Based官方失去了初始化函數的機會：
(4) 綜上因素，Based智能合約無法被官方正確初始化，因此任何質押行為都無法進行。
質押失敗的交易記錄：
如何避免事件發生
該次事件本質上是由智能合約漏洞導致的，但如果Based團隊提早注意到這個漏洞，提前初始化智能合約，可以完全規避這次危險，避免一號池被凍結。因此，CertiK安全技術團隊建議：
- 部署智能合約時應準備好初始化智能合約所需要的命令腳本等工具，及時初始化智能合約，避免攻擊者利用部署操作和初始化操作之間的時間差搶先初始化或者操縱智能合約。
- 了解智能合約的運行原理和技術細節，不要盲目的采用其他的智能合約代碼。
- 邀請專業的安全團隊對其智能合約進行審計，保證智能合約的安全性和可靠性。
