CertiK：重新部署其一号池事件分析
“亡羊补牢，为时未晚”，这句话在生活中的大部分时候均适用。然而，在面临网络安全时，牢破也许就会造成无法挽回的损失。
在安全问题未造成不可弥补的损失前就被发现，或是一开始便做好万全准备，才是身为区块链从业者的安全第一要义。
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安全技术团队建议：
部署智能合约时应准备好初始化智能合约所需要的命令脚本等工具，及时初始化智能合约，避免攻击者利用部署操作和初始化操作之间的时间差抢先初始化或者操纵智能合约。
了解智能合约的运行原理和技术细节，不要盲目的采用其他的智能合约代码。
邀请专业的安全团队对其智能合约进行审计，保证智能合约的安全性和可靠性。
更多linux咨询请查看www.linuxprobe.com
