SharkTeam 针对此事件进行了技术指标分析，并总结了安全防护方式。希望未来的项目能以此为教训，共同构建区块链行业的安全屏障。
一、事件分析
攻击者详细地址： 0x08e80ecb146dc0b835cf3d6c48da97556998f599
攻击合约： 0x2b1a7a457a2c55ba1e03c087cc3e4e5b05b6360f
漏洞合约： 0xDE1E704dae0B4051e80DAbB26ab6ad6c12262DA0
攻击买卖： 0xde2c8718a9efd8db0eaf9d8141089a22a89bca7d1415d04c05ba107dc1a190c3
该攻击买卖交易执行过程： 1. 首先，攻击者（0x08e80ecb）启用了攻击合约（0x2b1a7a45）的攻击函数公式。 2. 在攻击函数中，启用漏洞合约（0xDE1E704d）的 approve->burnFrom->transferFrom 函数公式。 3. 在 transferFrom 函数公式中，将 110 万 DEI 迁移到我们的帐户，最后通过正确的 swap 将 DEI 换成 USD 并转移至攻击者（0x08e80ecb）。
漏洞剖析： 在 burnFrom 函数中，直接将 sender 对 account 的 allowance 与 account 对 sender 的 allowance 展开了拷贝。
攻击者主要对漏洞合约（0xDE1E704d）进行了 approve 的最高值，然后启用 burnFrom 函数公式键入 amount=0，即直接将漏洞合约对攻击合约的 approve 值设为最高。
接着立即启用 tranferFrom 函数公式将 110 万 DEI 迁移到我们的详细地址，最终通过 pair 买卖兑换为 USD 进行攻击。
漏洞汇总： 此次事件的根源在于漏洞合约（RouteProcessor2）burnFrom 的管理权限问题或 _allowance 参数传递不正确的问题。实际上，需要根据项目的具体需求进行调整，可以通过设定合适的管理权限或修改 _allowance[_msgSender][account] 为 _allowance[account][_msgSender] 等方式进行处理。
二、安全建议 针对此次攻击事件，大家在实施过程中应注意以下常见问题： 1. 在开发与财务相关的逻辑运算时，应仔细考虑领域模型的准确性。 2. 此次漏洞的 burnFrom 函数是在 4 月 16 日进行合约更新时引入的。因此，在项目发布或更新合约之前，必须经过第三方技术专业财务审计团队对合约进行审计。
关于我们 SharkTeam 的愿景是全方位保障全球 Web3 的安全性。我们的精英团队由来自全国各地的资深安全专业人员和高级科学研究人员组成，熟练掌握区块链智能合约的底层基础理论，并提供专业的智能合约财务审计、链上剖析、紧急处置等服务。我们已与 Polkadot、Moonbeam、Polygon、OKC、HuobiGlobal、imToken、ChainIDE 等区块链生态体系的重要参与者建立了长期合作伙伴关系。
官方网站：https://www.sharkteam.org Twitter：https://twitter.com/sharkteamorg Discord：https://discord.gg/jGH9xXCjDZ Telegram：https://t.me/sharkteamorg
转载：驼鸟区块链
