XCarnival 是一个 NFT 借贷协议,用户可以将 NFT 抵押给协议,从而借出 token。同时也可以将 token 抵押给协议,获得利息收益。
这次攻击事件的原理是,用户在将 NFT 从协议中取出后,仍然可以借出 token。黑客利用这个 bug,不断新建合约,将其作为抵押人,抵押 NFT 并取出,然后再去借出 token,从而实现无本套利。
代码分析
XCarnival 的核心在于三个合约:
XNFT
,用户抵押 NFT 入口XToken
,用户借款入口P2Controller
,校验用户的权限,例如订单是否可借出,用户是否可赎回等
这次的 bug 在于,用户可以将 NFT 抵押到协议之后,再取出 NFT,而由于合约借贷逻辑中,没有订单的状态进行判断,因此仍然可以调用借出方法进行借贷,造成资产流失。
我们先来看看抵押的代码:
注意到抵押方法的 xToken 地址是作为参数传进去的,指定要借哪个 token。
再来看看取出 NFT 的方法(由于这段代码太长,我们只截取最重要的部分):
我们看到,在取出 NFT 的最后,将订单的 isWithdraw
置为了 true,指明订单已经被取出。
接下来我们看看借出 xToken 的部分:
xToken 中会调用 controller
的各种 allow
,verify
方法等来判断该 token 是否可借出。那么我们再看看 controller
中是如何实现的:
注意到没有,这里并没有对订单中的 NFT 是否取出,也就是上面的 isWithdraw
进行检查。如果我们先去抵押 NFT,这时已经生成了订单,然后再取出。此时再去调用 xToken 的 borrow
方法,那么就可以借款,而此时是没有任何抵押的。此次黑客事件就是利用了这个 bug。
攻击步骤
我们来看看黑客的几笔交易都在干什么:
- 从 OpenSea 中购买 BAYC (tokenId:5110)作为抵押物
- 创建攻击合约
- 将 BAYC 转到攻击合约中
- 新建内部合约并将其作为抵押人,抵押 NFT 后取出
- 内部合约行使借贷权利,从协议中借出 token
其中第四步的详细逻辑为:
这样在一笔交易中就可以构建多个抵押人(即新建的合约)。在实际的攻击中每一笔交易新建了四个内部合约,然后多次调用该方法,就可以构建出许多的抵押人。并且这些抵押人在协议中已经没有了抵押,但是仍然有借出 token 的权利。
接下来第五步,利用内部合约抵押人的身份,在没有任何抵押的情况下,直接从协议中借出 token,完成套利。
注意黑客在调用抵押方法 pledgeAndBorrow
的时候,传入了自定义的 xToken 地址。由于在这一步只需要实现抵押,不需要借贷,因此传入自定义的 xToken,可以避免 xToken 自带的一堆校验。
整体的逻辑还是比较简单的,我们也来尝试写写攻击合约。
攻击重现
要重现攻击,就需要模拟主网的各种状态,这时我们可以利用 hardhat 的 fork 功能,不熟悉的朋友可以看看我之前写的一篇文章,对其用法有详细的解释。
黑客的第一笔交易发生在区块 15028718 中,是购买 BAYC 的交易,那么我们就 fork 区块 15028720,并且使用 hardhat_impersonateAccount
模拟黑客的地址,那么此时在本地我们就拥有了 BAYC(5110),只需要关注攻击逻辑本身即可。
根绝我们前面的分析,在第四步中,需要新建内部的辅助合约,并具有抵押、取出、转移 NFT 的功能,最重要的,需要有借出 xToken 的功能。同时,在外部的攻击合约中,需要维护一个内部合约的地址列表,方便后续集中调用借款方法。
综上,我们最终实现的内部辅助合约为:
外部攻击合约为:
感兴趣的朋友可以多看几遍,结合注释好好理解一下,我们不再详细解释。
接着我们在本地自测,调用两次 prepare
之后调用 attack
,测试结果为:
balance before hack is 27.69746933937151467 balance after hack is 315.51434111624879089
差值恰好是 36 * 4 * 2 = 288
,说明我们模拟成功。
总结
这次的 bug 原因在于在一个很小的细节,也就是 NFT 取出后没有修改状态。这种小问题,审计人员也没有查出来,说明细节真的很重要。我们在编写合约的时候,对各个状态的变更都要仔细考虑几遍。
关于我
欢迎和我交流