mt logoMyToken
Market cap:
0%
FGI:
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

SharkTeam独家分析 | NFT流动性协议的安全困局—NFT借贷协议XCarnival被黑事件分析

Collect
Share

6月24日, NFT 抵押借贷协议XCarnival遭受到黑客攻击,黑客获利3087 ETH,大约380万美元。

image.png

这也是NFT流动性协议为数不多的严重攻击事件,SharkTeam第一时间对此事件进行了技术分析,并总结了安全防范手段,希望后续项目可以引以为戒,共筑区块链行业的安全防线。

image.png

一、 事件分析

攻击者地址:0xb7CBB4d43F1e08327A90B32A8417688C9D0B800a

攻击者通过Tornado提取了120 ETH用作攻击的启动资金:

image.png

攻击者地址获取到资金后的一系列交易如下:

image.png

image.png

首先,攻击者通过OpenSea创建了一个NFT,TokenID=5110

image.png

然后,攻击者创建了攻击合约,地址为0xf70f691d30ce23786cfb3a1522cfd76d159aca8d,简记为0xf70f

image.png

攻击者将创建的NFT转移至攻击合约

image.png

完成以上步骤后,攻击者发起了多次攻击,以其中的第一笔攻击交易为例,

txHash: 0x422e7b0a449deba30bfe922b5c34282efbdbf860205ff04b14fd8129c5b91433

NFT转移记录如下:

image.png

交易中NFT进行了4次转移,每次转移都使用了不同的合约地址,而且这些合约地址都是在当前交易中创建的,以第一次的转移为例,执行过程如下:

(1)创建合约0x2d6e070af9574d07ef17ccd5748590a86690d175,简记为0x2d6e

image.png

然后将NFT转移到新创建的合约0x2d6e

image.png

(2)通过代理合约调用XNFT合约中的质押与借贷函数pledgeAndBorrow,将NFT质押到XNFT合约中,借款为0。

image.png

XNFT代理合约地址为0xb14B3b9682990ccC16F52eB04146C3ceAB01169A,简记为0xb14b

NFT实现合约地址为0x39360AC1239a0b98Cb8076d4135d0F72B7fd9909,简记为0x3936

pledgeAndBorrow函数如下:

image.png

image.png

这里,在接收到NFT后就直接生成了订单,orderId=11,tokenId=5110,pledger就是from,即0x2d6e

image.png

(3)调用提取函数withdrawNFT,提取订单order=11中的NFT(tokenId=5110)

image.png

withdrawNFT函数如下:

image.png

该函数将5110 NFT提取到了地址0x2d6e

(4)将5110 NFT由合约0x2d6e转移到攻击合约0xf70f

image.png

经过以上步骤,该交易的目的就是创建4个订单,订单的orderId分别为11,12,13和14,并且订单的借款为0,其中NFT已被提取(order.isWithdraw = true)。

攻击者重复以上交易,创建了很多订单,然后调用了攻击的start函数,发起攻击。以第一笔 攻击 交易为例,

txHash: 0xabfcfaf3620bbb2d41a3ffea6e31e93b9b5f61c061b9cfc5a53c74ebe890294d

image.png

XToken代理合约:0xB38707E31C813f832ef71c70731ed80B45b85b2d,简记为0xb387

XToken实现合约:0x5417da20aC8157Dd5c07230Cfc2b226fDCFc5663,简记为0x5417

交易中存在多笔ETH转账记录,都是从0xb387,通过攻击合约创建的合约转入到攻击合约中,每次转账都调用了XToken合约中的borrow函数,以第一笔转账为例,函数调用如下:

image.png

borrow函数如下:

image.png

这里会调用controller合约中的borrowAllowed函数做校验,函数调用以及参数如下:

image.png

controller合约borrowAllowed函数如下:

image.png

这里对order进行了校验,但仅仅是校验了订单存在、地址正确并且没有被清算,并没有校验订单中的NFT是否被提取,尽管orderId=11的订单中的NFT已经被提取了,order的校验仍然可以通过,因此,攻击者在没有实际抵押NFT的情况下借走了36 ETH。

攻击者利用该漏洞,重复攻击,陆续从合约中盗取了共计3087 ETH,总价值约380万美元。

二、安全建议

本次安全事件发生的根本原因在于项目方合约存在逻辑漏洞,在借款时逻辑不严谨,缺少关键逻辑的校验,即没有检测抵押物是否已经被提取。

众所周知,NFT生态想要有长期可持续发展,必须要有优秀的NFT流动性项目来提供流动性市场。在各类NFT藏品不断发布的同时,交易、借贷等NFT流动性协议也是行业关注的重点。但因为NFT的价格预言机、价值背书等问题还没有彻底解决,因此大多数NFT流动性项目的体量还比较小。在这种情况下,一旦发生黑客攻击事件,往往会给项目团队造成致命打击,也会极大的影响用户信心。

因此我们建议项目方在项目设计、开发以及测试的过程中要严谨,尽可能避免一些核心校验逻辑的缺失,给黑客可乘之机。另外,建议进行多方多轮审计,尽可能地减少合约中的高危漏洞。

三、关于我们

SharkTeam 的愿景是全面保护Web3世界的安全。团队成员分布在北京、南京、硅谷,由来自世界各地的经验丰富的安全专业人士和高级研究人员组成,精通区块链和智能合约的底层理论,提供包括智能合约审计、链上分析、应急响应等服务。已与区块链生态系统各个领域的关键参与者,如Huobi Global、OKX、polygon、Polkadot、imToken、ChainIDE等建立长期合作关系。

Web:https://www.sharkteam.org

Telegram:https://t.me/sharkteamorg

Twitter:https://twitter.com/sharkteamorg

Reddit:https://www.reddit.com/r/sharkteamorg

更多区块链安全咨询与分析,点击下方链接查看

D查查|链上风险核查 https://m.chainaegis.com

Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content