EarningFarm攻击事件分析

根据Numen链上监控显示，3天前EarningFarm发生攻击。见如下链接：

https://etherscan.io/tx/0x160c5950a01b88953648ba90ec0a29b0c5383e055d35a7835d905c53a3dda01e

看到在_deposit完成各种token的兑换最后存入aave，并且偿还balancer的借款，然后完成回调。

下面是withdraw。

然后看一下balancer的flashloan和回调 receiveflashloan，如下图所示：

由于项目方缺少经验，项目本身确实用到了balancer的flashloan，再项目方看来这是一种正常场景。但是项目方没考虑到直接调用balancer的flashloan这种场景，而不是从正常的deposit或者withdraw流程进入，所以产生了问题。由于攻击者可直接调用balancer的flashloan，并且把recipent设置成elfevervault合约。不直接调用withdraw，因为不管从哪个口进入，底层都是_deposit或者_withdraw。其实针对msg.sender==balancer的判断是恒成立的。 因为地址a调用balancer的flahsloan，flashloan里面回调了地址a的receiveflashloan，相当与回调的msg.sender永远是balancer，等于没有判断。其实这个地方应该校验的是谁调用了flashloan而不是谁调用了闪电贷回调 receiveFlashloan。当然如果指定要用balancer的flashloan，那么这个判断也不能省略，然后需要在加上前面说的判断。

总体过程见下图：

因为底层都是通过_deposit/_withdraw实现，所以跳过deposit/withdraw入口，直接从balancer.flashloan进入。因为对闪电贷回调函数的msg.sender没有进行正确校验，导致只要是balancer的flashloan进入，校验恒成立，并且recipent地址由外部控制。校验没有真正起到拦截作用，应该对flashloan的msg.sender在进行一个校验，应该require(msg.sender==recipent)。