两天内遭遇两次攻击 DeFi 协议 FEG 真的伤不起

前言

北京时间 2022 年 5 月 16 日，知道创宇区块链安全实验室 监测到多链 DeFi 协议 FEG 遭到闪电贷攻击，攻击者窃取 144 ETH 和 3280 BNB，损失约 130 万美元。

5 月 17 日，多链 DeFi 协议 FEG 再次受到攻击，攻击者窃取 291 ETH 和 4343 BNB，损失约 190 万美元，其中 BSC 130 万美元， 以太坊 链 60 万美元。

分析

该协议在 BSC 和 Ether 上都被攻击了，下面的图分别是两链上的攻击事件交易哈希。本次攻击事件主要原因是 swapToSwap() 函数中 path 地址可被攻击者控制。

基础信息

攻击合约：0x9a843bb125a3c03f496cb44653741f2cef82f445

攻击者地址：0x73b359d5da488eb2e97990619976f2f004e9ff7c

漏洞合约地址：

BSC: 0x818e2013dd7d9bf4547aaabf6b617c1262578bc7

Ether: 0xf2bda964ec2d2fcb1610c886ed4831bf58f64948

攻击 tx：

BSC:0x77cf448ceaf8f66e06d1537ef83218725670d3a509583ea0d161533fda56c063

Ether:0x1e769a59a5a9dabec0cb7f21a3e346f55ae1972bb18ae5eeacdaa0bc3424abd2

攻击流程

1.攻击者 0x73b3 调用事先创建好的攻击合约 0x9a84 从 DVM 中闪电贷借出 915.842 WBNB，接着将其中的 116.81 WBNB 兑换成 115.65 fBNB。

2.攻击者 0x73b3 通过攻击合约 0x9a84 创建了 10 个合约以便后面利用漏洞。

3.攻击者 0x73b3 将第一步中兑换得到的 fBNB 通过函数 depositInternal() 抵押到 FEGexPRO 合约 0x818e 中。

4.攻击者 0x73b3 调用 depositInternal() 和 swapToSwap() 函数使得 FEGexPRO 合约 0x818e 授权 fBNB 给第二步创建好的合约，重复多次调用授权 fBNB 给创建的 10 个合约。

5、由于上一步中已经将攻击者 0x73b3 创建的 10 个合约都已授权，攻击者用这些已被授权的合约调用 transferFrom() 函数将 FEGexPRO 合约 0x818e 每次转走 113.452 fBNB。

6、攻击者 0x73b3 又从 PancakePair 的 LP 交易对 0x2aa7 中借出 31217683882286.007 的 FEG 和 423 WBNB 并重复上面的 第三步、第四步和第五步，最终获得 。

7、最后归还闪电贷，将上面攻击获得的所有 WBNB 转入攻击合约 0x9a84 中。

细节

查看 FEGexPRO 合约，我们能看到 depositInternal() 函数和 swapToSwap() 函数的具体逻辑。其中 depositInternal() 函数进行质押，用户的余额受到合约当前代币余额的影响，第一次攻击者正常质押后 balance 也正常增加，而由于当前合约代币余额没变，后面的质押只需要传入最小值调用即可。

通过调用 swapToSwap() 函数传入恶意的 path 地址参数，当前合约代币余额并不会受到影响，IERC20(address(Main)).approve(address(path), amt); 这样就能给 path 地址进行当前合约 fBNB 的授权。

攻击者通过反复调用 depositInternal() 和 swapToSwap()就可以让 FEGexPRO 合约将 fBNB 反复授权给攻击者传入的恶意合约 path 地址。其他地址转走的代币数量就是攻击者第一次质押的代币数量减去手续费的数量。通过查看 Debugger 中的信息，我们可以发现传入的 path 地址参数都是攻击流程中创建的合约地址。

后续

在 16 日的攻击之后，次日攻击者又进行了一次攻击，但更换了攻击地址。

攻击合约：0xf02b075f514c34df0c3d5cb7ebadf50d74a6fb17

攻击者地址：0xf99e5f80486426e7d3e3921269ffee9c2da258e2

漏洞合约：0xa3d522c151ad654b36bdfe7a69d0c405193a22f9

攻击 tx：

BSC:0xe956da324e16cb84acec1a43445fc2adbcdeb0e5635af6e40234179857858f82

Ether:0c0031514e222bf2f9f1a57a4af652494f08ec6e401b6ae5b4761d3b41e266a59

由于 R0X 漏洞合约 0xa3d5 未开源，我们试着从 Debugger 中进行分析，发现和第一次的攻击流程类似，但还用了 BUY() 辅助存入和 SELL() 函数进行辅助提取。

总结

该次攻击的主要原因是未验证 swapToSwap() 函数中 path 地址参数，导致可以被攻击者任意传入使得 FEGexPRO 合约将自身代币授权给攻击者传入的所有恶意 path 地址。建议合约在开发时要对所有传入的参数进行校验，不要相信攻击者传入的任何参数。