2023?年?3?月?13?日，EulerFinance?资金池遭遇闪电贷攻击，预计损失总计约?1.95?亿美元。这一数字也是?2023?年迄今为止Web3领域所有其他安全事件资产损失总额的两倍以上。
根据?EulerFinance?对自己描述，该平台是“以太坊上的一个允许用户借出和借入几乎任何加密货币资产的非托管协议”。
造成该攻击的原因主要是?EulerPool?合约中的`donateToReserve`存在漏洞。由于该功能缺乏对调用者仓位健康度的检查，用户可以通过自主放弃一部分杠杆存款，使自身仓位失衡，从而使用?Euler?特色的清算规则清算自己的仓位而获利。
攻击者利用闪电贷借来的资产，首先通过?Euler?借贷协议中独特的`mint'功能以及?Euler?资金池合约中易受攻击的'donateToReserves'功能创建了一个高杠杆且资不抵债的状况。随后攻击者在同一笔交易以清算者的身份清算自己创建的资不抵债的仓位“免费”获得大量衍生?eToken。最后通过提款耗尽资金池，并在多个?EulerPools?反复实施攻击，以耗尽所有资金池。
下面是对某一资金池的攻击流程，还有其他四个具有相同漏洞的资金池也被攻击了。
攻击流程
①攻击者从?AAVE?闪电贷到?3000?万DAI。
②攻击者通过?eDAI?合约向?Euler?存入?2000?万DAI，并收到?2000?万eDAI。在攻击者存入?2000?万?DAI?之前，Euler?池中的?DAI?余额为?890?万。
③调用`eDAI.mint()`。该特定的`mint`功能是?EuleFinancer?独有的，可允许用户反复借款和还款。这是一种创建借贷循环的方法，其结果是带杠杆的借贷仓位。
④调用`mint`后，收到?2?亿dDAI?和?1.95.6?亿eDAI。(注：dTokens?代表债务代币，eTokens?代表抵押股权）。
⑤调用"repay"，将?eDAI?池中的?1000?万?DAI?偿还给?Euler，这就将?1000?万?dDAI?销毁了。随后再次调用"mint"，为攻击合约创造另一个?2?亿?dDAI?和?1.956?亿?eDAI?形式的借贷仓位。此时攻击者的仓位为:3.9亿dDAI和4?亿eDAI。
⑥调用`donateToReserves`，将?1?亿?eDAI?转给?Euler。由于没有对这一行为的抵押状况进行适当的检查，"donate"后的攻击者成为了"违规者",其风险调整后负债远超过了的抵押品价值，因此可以对其进行清算。此时攻击者的仓位为:3.9亿dDAI和3?亿eDAI。
⑦攻击者部署的清算人合约开始清算“违规者”。EulerFinance?清算逻辑中一个特色功能是当被清算人的借贷仓位极其不健康时，清算人员可以在此过程中获得最高?20%?的“折扣”。
⑧通过清算，清算人获得了?2.59?亿?dDAI?的“债务”，获得?3.1eDAI?的“资产”。清算过程中转让的债务总额比资产低得多。清算人获得了价值近?4500?万的?eDAI?资产。
⑨清算人通过获得的?eDAI?从协议中取走了所有的?3890?万?DAI?的抵押品，然后偿还了闪电贷款，获利?800?万美元。
攻击者目前在地址一持有价值?1350?万美元的?ETH，在地址二持有?1.48?亿美元的?ETH?以及?4300?万?DAI。
地址一：
https://etherscan.io/address/0x?B?2698?C?2D?99?aD?2c?302?a?95?A?8?DB?26?B?08?D?17?a?77?cedd?4?
地址二：
https://etherscan.io/address/0x?b?66?cd?966670?d?96?2C?227?B?3?EABA?30?a?87?2D?bFb?995?db
神奇的是，第一次攻击交易竟被?MEV?机器人无意拦截了。该机器人获得了?879?万美元的?DAI。可惜攻击者合约里把提款地址写死了,MEV?机器人在试图归还资金的过程中只能把截拦到的资金发到攻击者的地址。
第二到第五笔攻击使黑客获得了价值?1.77?亿美元的资产。
MEV?机器人的所有者在链上留言并解释他们无法归还这些钱，并对受影响的用户感到抱歉和遗憾。
写在最后
目前，该事件是?2023?年Web3领域最大的一次黑客攻击。EulerFinance?在推文中承认了这一事件的真实性，并表示他们目前正在与安全专家和执法部门进行合作。
EulerFinance?团队的整体安全水平和意识在行业内处于相对较高的水准，目前也已与很多安全公司进行了合作。项目进行过审计，也有?bugbounty?漏洞赏金计划加持，不过项目还是未能逃过黑客的磨爪。
因此?CertiK?安全专家再次提醒，新添加的功能，务必也要进行审计。由于上述合约漏洞是?https://forum.euler.finance/t/eip-14-contract-upgrades/305引进的，才造成了如此严重的后果。
所以审计并不是一劳永逸的，合约在添加新功能时，务必要重新对新添加功能进行审计，否则即便已审计过“千里之堤”，也可能溃于未审计的“蚁穴”。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。