原文作者：九九，慢雾安全团队
2022年6月27日，据慢雾区消息，XCarnival项目被曝出严重漏洞遭黑客攻击并盗走3,087个ETH。XCarnival是一个ETH链上的NFT借贷项目，目前项目团队正在修复漏洞并承诺会对受影响的用户提供解决方案。慢雾安全团队第一时间介入分析，并将结果分享如下：
相关信息
核心合约地址
P2Controller：
0x34ca24ddcdaf00105a3bf10ba5aae67953178b85
Tranchess DAO关于“移除最小创建量”的提案#4已结束投票并实现:3月14日消息，Tranchess DAO关于移除最小创建量的提案#4已经结束投票并实现，50.47%的选票支持100% Reduction。[2022/3/14 13:55:21]
XNFT：
0x39360AC1239a0b98Cb8076d4135d0F72B7fd9909
xToken：
0x5417da20aC8157Dd5c07230Cfc2b226fDCFc5663
声音 | 欧洲央行执委：将在10月前向G7集团提出关于Libra的政策建议:欧洲央行执委科尔表示，稳定币的倡议（例如Libra）是有破坏性的，全球许多其他国家表达了对Libra的巨大的担忧，包括美国。Libra无疑是一个警钟，提醒各国央行不断努力，改善现有的支付系统。全球央行自然会联合起来，共同研究央行数字货币的可行性。预计将在10月前向G7集团提出关于Libra的政策建议。(金十)[2019/9/18]
攻击者EOA地址
0xb7cbb4d43f1e08327a90b32a8417688c9d0b800a
动态 | 日本虚拟货币商业协会发布关于“ICO新规制的建议”:日本虚拟货币商业协会(JCBA)表示，站在虚拟货币事业相关团体的立场，为了促进日本区块链业务的健全成长，同时根据日本金融厅公布的“虚拟货币交换业研究报告”中的“对ICO应对”的部分，在此基础上提出关于“ICO新规制的建议”。主要分为以下四点：(1)关于日本国内交易所处理虚拟货币扩张的问题，其中包括稳定币等。 (2)关于金融商品交易法的限制对象中代币与结算相关规定，包括控制代币区分和限制级别的调整。(3)关于安全代币的限制，包括安全代币作为有价证券情况的明确化。(4)关于实用代币的限制，需排除对商业法规的某些限制，对虚拟货币交易所施加过度的义务是不妥当的以及会计准则明确化等。[2019/3/8]
攻击合约地址
慢雾：Avalanche链上Zabu Finance被黑简析:据慢雾区情报，9月12日，Avalanche上Zabu Finance项目遭受闪电贷攻击，慢雾安全团队进行分析后以简讯的形式分享给大家参考：
1.攻击者首先创建两个攻击合约，随后通过攻击合约1在Pangolin将WAVAX兑换成SPORE代币，并将获得的SPORE代币抵押至ZABUFarm合约中，为后续获取ZABU代币奖励做准备。
2.攻击者通过攻击合约2从Pangolin闪电贷借出SPORE代币，随后开始不断的使用SPORE代币在ZABUFarm合约中进行`抵押/提现`操作。由于SPORE代币在转账过程中需要收取一定的手续费(SPORE合约收取)，而ZABUFarm合约实际接收到的SPORE代币数量是小于攻击者传入的抵押数量的。分析中我们注意到ZABUFarm合约在用户抵押时会直接记录用户传入的抵押数量，而不是记录合约实际收到的代币数量，但ZABUFarm合约在用户提现时允许用户全部提取用户抵押时合约记录的抵押数量。这就导致了攻击者在抵押时ZABUFarm合约实际接收到的SPORE代币数量小于攻击者在提现时ZABUFarm合约转出给攻击者的代币数量。
3.攻击者正是利用了ZABUFarm合约与SPORE代币兼容性问题导致的记账缺陷，从而不断通过`抵押/提现`操作将ZABUFarm合约中的SPORE资金消耗至一个极低的数值。而ZABUFarm合约的抵押奖励正是通过累积的区块奖励除合约中抵押的SPORE代币总量参与计算的，因此当ZABUFarm合约中的SPORE代币总量降低到一个极低的数值时无疑会计算出一个极大的奖励数值。
4.攻击者通过先前已在ZABUFarm中有进行抵押的攻击合约1获取了大量的ZABU代币奖励，随后便对ZABU代币进行了抛售。
此次攻击是由于ZabuFinance的抵押模型与SPORE代币不兼容导致的，此类问题导致的攻击已经发生的多起，慢雾安全团队建议：项目抵押模型在对接通缩型代币时应记录用户在转账前后合约实际的代币变化，而不是依赖于用户传入的抵押代币数量。[2021/9/12 23:19:21]
0xf70F691D30ce23786cfb3a1522CFD76D159AcA8d
0x234e4B5FeC50646D1D4868331F29368fa9286238
0x7B5A2F7cd1cc4eEf1a75d473e1210509C55265d8
0xc45876C90530cF0EE936c93FDc8991534F8A6962
在pledgeInternal函数中转入NFT并生成订单：
2.接着调用withdrawNFT函数提取出质押的NFT，其中首先判断该订单是否被清算状态，如果不是则判断该订单的状态是否为NFT还未被提取且借款金额为0，如果通过即可提取抵押的NFT。
3.以上为攻击前生成订单的准备操作，接着攻击者开始利用生成的订单直接调用xToken合约中的borrow函数进行借款。
在borrowInternal函数中，会外部调用controller合约中的borrowAllowed函数来判断是否可以借款。
可以看到在borrowAllowed函数会调用orderAllowed函数进行订单相关信息的判断，但是在这两个函数中均没有进行_order.isWithdraw状态的判断。因此攻击者可以利用之前生成的订单来调用XToken的borrow函数来借款，而因为抵押的NFT在之前已经被提出，故攻击者可以不用还款来实现获利。
攻击交易分析
此处仅展示其中一笔攻击交易的细节，其余攻击交易的手法均一致，不再赘述。
攻击前准备——生成订单的交易：
0x61a6a8936afab47a3f2750e1ea40ac63430a01dd4f53a933e1c25e737dd32b2f
1.首先攻击者将NFT转入攻击合约并进行授权，接着调用xNFT合约中的pledgeAndBorrow函数在进行抵押NFT生成订单并借款的操作，此处需要注意一点是该函数可以控制传入的xToken，攻击者传入了自己构造的xToken合约地址，并且让借款数量为0，目的是为了满足后续能成功提出NFT时的不被清算且负债为0的条件。
2.攻击者紧接着调用withdrawNFT函数来进行提取抵押的NFT：
正式攻击交易：
0x51cbfd46f21afb44da4fa971f220bd28a14530e1d5da5009cfbdfee012e57e35
攻击者调用xToken合约的borrow函数，传入之前生成的订单的orderID，重复了该操作22次，而因为NFT在准备阶段已经提走，估计无需还款以此来获利。
总结
本次漏洞的核心在于借款的时候，没有进行订单中NFT是否被提走的状态的判断，导致攻击者可以在把NFT提走之后再利用之前生成的订单来借款而无需还款，以此来获利。针对此类漏洞，慢雾安全团队建议在进行借款操作时应做好订单状态中是否已经提走抵押品的判断，避免再次出现此类问题。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。