2023 年 3 月 13 日，Euler Finance 资金池遭遇闪电贷攻击，预计损失总计约 1.95 亿美元。这一数字也是 2023 年迄今为止Web3领域所有其他安全事件资产损失总额的两倍以上。
根据 Euler Finance 对自己描述，该平台是“以太坊上的一个允许用户借出和借入几乎任何加密货币资产的非托管协议”。
造成该攻击的原因主要是 Euler Pool 合约中的`donateToReserve`存在漏洞。由于该功能缺乏对调用者仓位健康度的检查，用户可以通过自主放弃一部分杠杆存款，使自身仓位失衡，从而使用 Euler 特色的清算规则清算自己的仓位而获利。
攻击者利用闪电贷借来的资产，首先通过 Euler 借贷协议中独特的`mint功能以及 Euler 资金池合约中易受攻击的donateToReserves功能创建了一个高杠杆且资不抵债的状况。随后攻击者在同一笔交易以清算者的身份清算自己创建的资不抵债的仓位“免费”获得大量衍生 eToken。最后通过提款耗尽资金池，并在多个 Euler Pools 反复实施攻击，以耗尽所有资金池。
下面是对某一资金池的攻击流程，还有其他四个具有相同漏洞的资金池也被攻击了。
攻击流程
①攻击者从 AAVE 闪电贷到 3000 万 DAI。
②攻击者通过 eDAI 合约向 Euler 存入 2000 万 DAI，并收到 2000 万 eDAI。在攻击者存入 2000 万 DAI 之前，Euler 池中的 DAI 余额为 890 万。
③调用`eDAI.mint()`。该特定的`mint`功能是 Eule Financer 独有的，可允许用户反复借款和还款。这是一种创建借贷循环的方法，其结果是带杠杆的借贷仓位。
④调用`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`（该存在漏洞的函数于 2022 年 7 月被引入），将 1 亿 eDAI 转给 Euler。由于没有对这一行为的抵押状况进行适当的检查，donate 后的攻击者成为了违规者（非健康负债水平的地址）, 其风险调整后负债远超过了的抵押品价值，因此可以对其进行清算。此时攻击者的仓位为: 3.9 亿 dDAI 和 3 亿 eDAI。
⑦攻击者部署的清算人合约开始清算“违规者”。Euler Finance 清算逻辑中一个特色功能是当被清算人的借贷仓位极其不健康时，清算人员可以在此过程中获得最高 20% 的“折扣”。
⑧通过清算，清算人获得了 2.59 亿 dDAI 的“债务”，获得 3.1 eDAI 的“资产”。清算过程中转让的债务总额比资产低得多。清算人获得了价值近 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领域最大的一次黑客攻击。Euler Finance 在推文中承认了这一事件的真实性，并表示他们目前正在与安全专家和执法部门进行合作。
Euler Finance 团队的整体安全水平和意识在行业内处于相对较高的水准，目前也已与很多安全公司进行了合作。项目进行过审计，也有 bug bounty 漏洞赏金计划加持，不过项目还是未能逃过黑客的磨爪。
因此 CertiK 安全专家再次提醒，新添加的功能，务必也要进行审计。由于上述合约漏洞是 https://forum.euler.finance/t/eip-14-contract-upgrades/305 引进的，才造成了如此严重的后果。
所以审计并不是一劳永逸的，合约在添加新功能时，务必要重新对新添加功能进行审计，否则即便已审计过“千里之堤”，也可能溃于未审计的“蚁穴”。
