点击阅读:Web3安全连载(1)当硬核黑客开始研究“钓鱼”,你的NFT还安全吗?
欢迎来到Web3安全连载系列,上周,我们刚推送《Web3安全连载(1)当硬核黑客开始研究“钓鱼”,你的NFT还安全吗?》后,就有一位NFT收藏者被盗。
在上篇文章里,我们就说过Web3世界黑客依然猖狂,因此个人的安全防范非常重要,大家可以再次阅读下面这篇文章:
干货 | 钓鱼网站“入侵”Web3,这些防技巧必须学会!
此外,NFT智能合约层面上的漏洞同样值得我们警惕!随着今年一系列NFT智能合约相关安全事件的发生,如:APE Coin空投事件、TreasureDAO安全事件等,让我们必须再次关注NFT领域的智能合约安全。
典型的NFT合约漏洞主要包含两大类,一类是NFT自身的漏洞;一类是NFT平台业务相关漏洞问题。闲话少说,本文我们将对NFT中的这两类合约安全问题进行详细介绍,欢迎来围观。
??PART 01
「NFT自身漏洞问题」
NFT的生命周期通常分为发行、流转、销毁等阶段,其中在发行阶段存在的安全问题最多。NFT的购买通常分为预售、正式发售两种情况。而预售阶段项目方一般会设置能够参与的用户白名单。但是即使进行了设置,但仍然存在各类白名单绕过漏洞的问题。
案例一:APE Coin空投事件?
2022年3月17日,推特用户Will Sheehan发布推文称套利机器人通过闪电贷薅羊毛拿到了超过6万的APE Coin空投。
关于本次攻击事件中,相关信息如下:
攻击交易:
0xeb8c3bebed11e2e4fcd30cbfc2fb3c55c4ca166003c7f7d319e78eaab9747098
DeFi协议Num Finance完成150万美元融资,Ripio Venture等参投:5月24日消息,Num Finance 完成 150 万美元融资,稳定币开发商 Reserve、H2O Scouter Fund、Ripio Venture、VC3 DAO 和 Auth0 首席技术官 Matias Woloski 等参投。
Num Finance 表示,将在下个月内扩大其稳定币产品,包括巴西雷亚尔、哥伦比亚比索、墨西哥比索和巴林第纳尔,还将发展其现实世界资产(RWA)产品。[2023/5/24 15:21:32]
获利者地址:
0x6703741e913a30D6604481472b6d81F3da45e6E8
漏洞合约地址:
0x025C6da5BD0e6A5dd1350fda9e3B6a614B205a1F
攻击者获得相关APE空投的交易具体如下图所示:
攻击者套利的主要步骤为:
1.首先从Opensea购买了ID为1060的BAYC NFT;
2.通过NFTX以闪电贷借出5个BAYC NFT;
3.利用空投合约(AirdropGrapesToken)漏洞,领取6个BAYC对应数量的APE Coin;
4.归还闪电贷,并转移获利的APE Coin;
其中涉及到的漏洞合约AirdropGrapesToken代码如下图所示:
如上图所示,该函数使用 alpha.balanceOf()和beta.balanceOf()判定调用者对BAYC/MAYC NFT的所有权。但是这种方式仅能获取到用户对该NFT所有权的瞬时状态,该瞬时状态可以通过闪电贷借入进行操控,更安全的方式是采用基于默克尔树的(Merkle tree)链下快照方式。该方式将白名单存储在链下项目方的中心服务器上,当用户在前端官网点击mint之后,服务器会根据钱包地址生成Merkle proof,用户再向智能合约发送一笔携带Merkle proof的交易,并在链上的智能合约中进行验证。
加拿大DeFi公司WonderFi宣布完成对Bitbuy的收购:金色财经消息,加拿大DeFi公司WonderFi Technologies完成了对Bitbuy Technologies母公司First Ledger Corp的收购。
在加拿大Neo Exchange交易的WonderFi已同意以现金加股票的形式支付1.618亿美元。据悉,该协议于2022年1月首次宣布,4个月后完成。(Blockworks)[2022/3/25 14:18:20]
该方式一般包含以下三部分:
- 后台根据白名单地址生成Merkle tree;
- 将Merkle Root上传到区块链;
- 验证时前端根据当前用户生成Merkle Proof,并将其传入NFT合约校验;
具体可以参考NFT项目Invisible Friends (INVSBLE),合约地址:0x59468516a8259058baD1cA5F8f4BFF190d30E066。以下是INVSBLE项目中采取的白名单铸币方法mintListed():
- amount:铸造NFT的数量;
- maxAmount:该地址能铸造的NFT最大数量;
- merkleProof:判断某特定白名单地址节点是否属于Merkle tree上所需的数据,包含叶子节点、路径、根;
该函数首先校验预售是否开启、调用者是否还有额度铸造,接着进行白名单校验,并验证调用者出价是否正确,最后铸造NFT。以下为进行白名单验证的代码实现:
keccak256(abi.encodePacked(sender,maxAmount.toString()))用于计算默克尔树的叶子节点,此处用白名单用户地址和每个用户能够铸造的最大NFT数量作为叶子节点属性。同时还隐藏了一个校验,即msg.sender必须是白名单地址本身。
DeFi借贷平台Vee.Finance完成数百万美元种子轮融资:DeFi借贷平台Vee.Finance完成数百万美元种子轮融资,火币创投区块链基金和AVATAR领投,本轮融资主要用于扩大团队和增加平台的能力,以扩大业务规模。(newsbtc)[2021/7/14 0:52:21]
Merkle Proof验证计算使用library MerkleProof,计算过程可以参考SPV验证,具体源码如下:
使用该方式,NFT发行合约中不需要存储整个白名单列表,只需要存储Merkle root。当交易发送方是非白名单用户时,因为其无法提供合法的Merkle Proof,则无法通过校验。
链下数据快照验证白名单还有另一种使用签名的方式,此时如果合约开发者未设置足够的安全检查,也容易造成安全问题,如:NBA薅羊毛事件。
案例二:NBA薅羊毛事件?
2022年4月21日,NBAxNFT项目方遭遇黑客攻击。根据官方回复,由于其白名单校验出现问题导致预售提前售罄。
本次攻击事件中,漏洞合约地址:
0xdd5a649fc076886dfd4b9ad6acfc9b5eb882e83c
上述代码存在两个安全问题:签名冒用和签名复用。签名复用指的是,同一个签名只能使用一次,一般项目方会在合约中设置一个mapping结构存储该签名是否已经被使用,具体源码如下:
?mapping(bytes => bool) private usedClaimSignatures
其中bytes代表Hash签名数据,bool值代表该签名是否曾经被使用,但是mint_approved()函数中并未存储该值,所以存在签名复用问题。
数据:过去三个月至少36个DeFi项目总计获1亿美元资助:12月4日消息,过去三个月里,已确认至少36个DeFi项目得到了资助。总共约有1亿美元被分配给了这些项目,平均交易规模约为300万美元。而在这些投资中,最主要的趋势之一(占到所有投资交易的25%)是为那些不是建立在以太坊协议之上的DeFi应用程序提供资金,或者是为其他协议提供可互操作性的跨链项目。(The Block)[2020/12/4 14:02:21]
本文主要研究白名单校验中的签名冒用问题,即由于vData memory参数info在传参时未进行msg.sender校验导致签名可冒用。具体白名单校验函数verify()如下:
上述代码采用签名校验的方式验证白名单,白名单存储在中心化服务器上,用户从前端NFT官网点击mint时,服务器会首先校验是否是白名单用户。如果是,则由服务器使用项目方私钥进行签名,再将签名数据返回。最后用户携带该签名的交易发送到链上进行验证。因此此处ecrecover()验证的仅仅是项目方的地址,仅能证明该签名数据是由项目方进行签发的,但是由于未对签名数据中的调用者,即info.from进行验证,所以导致签名可冒用。
PART 02
「NFT平台漏洞问题」
NFT平台主要有两类,一类是NFT交易平台,如:Opensea、TreasureDAO等;另一类是结合了DeFi业务的平台,如:Revest Finance等。根据平台类型不同,对应的业务类型也不同,造成的安全漏洞也不同。
NFT+DeFi?类型
目前NFT + DeFi主要分为三种类型:一种是将NFT当作流动性代币,如:Uniswap-V3等;一种是将NFT碎片化,即FNFT(Fractional Non-Fungible Token),如:Revest Finance等;另一种是将NFT作为借贷的抵押品,如:Position Exchange等。其中Revest Finance项目包含以上三种业务类型,因此本文从业务逻辑的角度研究了Revest Finance安全事件。
Gate.io明日中午12点上线14天AXIS锁仓DeFi流动性挖矿理财项目:据官方公告,Gate.io将于9月19日(明日)中午12点上线14天AXIS锁仓获得AXIS收益DeFi流动性挖矿理财项目,总仓位5万AXIS。
Gate.io提醒:由于DeFi项目价格波动较大,DeFi流动性挖矿的收益波动风险同样较高,请务必注意投资风险,理财收益最终将根据实际收益情况调整分发。详情见原文链接。[2020/9/18]
Revest Finance是针对DeFi领域的staking解决方案,用户通过该项目参与任何Defi的staking,都可以直接生成一个F-NFT,其代表了staking仓位当前和未来的价值,具体的业务模型如下:
该项目中用户可以通过mintAddressLock()铸造对应抵押资产的FNFT,具体代码如下所示:
其中涉及到的重要参数为:
- trigger:只有该address可以解锁质押的资产;
- recipients:铸造的FNFT对应的接收者;
- quantities:各个接收者接收的FNFT数量;
- IRevest.FNFTConfig:描述FNFT对应的质押资产,包括:asset(抵押的资产类型,如WETH等)、depositAmount(每个FNFT代表的抵押资产数量,包含精度)等。
用户也可以通过depositAdditionalToFNFT()追加FNFT的抵押资产,具体代码如下:
其中涉及到的重要的参数为:
- fnftId:需要追加资产的FNFT;
- amount:每个FNFT需要追加的抵押资产数量,包含精度;
- quantity:为多少个FNFT追加抵押;
用户追加质押资产时,根据quantity的不同存在三种情况,第一种情况是为所有FNFT追加抵押,第二种情况是为其中一部分FNFT追加抵押,第三种情况是追加抵押的FNFT数量大于FNFT总量,此时报错返回。该漏洞为第二种情况下造成的重入,具体逻辑如下:
由上述代码可知,追加抵押时需要先把之前的FNFT销毁,之后再铸造新的FNFT。但是在铸造时,由于min()函数中未判断需铸造的FNFT是否已经存在,并且状态变量fnftId自增在_mint()函数后。而_min()中存在ERC-1155中的隐藏外部调用_doSafeTransferAcceptanceCheck(),造成了重入漏洞。具体代码如下:
此处的mint()函数中_mint()包含一个隐藏的外部调用,具体如下:
攻击主要包括以下三个步骤:
1.调用mintAddressLock()铸造了2个fnftId为1027的FNFT,但是它们对应的资产为0;
2.调用mintAddressLock()铸造了360000个fnftId为1028的FNFT,它们对应的抵押资产仍然为0;
3.在步骤2中,利用ERC-1155中_mint()函数中的_doSafeTransferAcceptanceCheck()重入了depositAdditionalToFNFT(),将1个fnftId为1027的FNFT对应的抵押更新为1 WETH。
由于此时fnftId还未自增,仍然为1027,所以该函数会生成一个fnftid为1028且价值为1 WETH的FNFT,导致将id为1028的FNFT价值从0更新为了1 WETH。
综上,由于FNFT是一种证券化后的NFT,其价值会根据业务逻辑的不同产生波动,如该例中的staking仓位价值。所以FNFT存在价值变更的情况,一般会通过重写burn()和mint()等函数实现价值变更,如:本例中的FNFTHandler合约。如果实现时没有考虑检查-交互-生效机制,就可能存在严重安全问题。
NFT交易平台?
该类平台一般会实现简单的市场功能,包括:挂单、取消挂单、购买、出价、取消出价、接受出价、提现等。其中涉及到的NFT资产包括ERC721、ERC1155两种,开发过程中如果没有考虑到二者的区别,就可能造成安全问题,如TreasureDAO事件。
2022年3月3日,TreasureDAO生态的TreasureMarketplace交易平台遭到黑客攻击,造成NFT token被盗。传送门——《怪事?盗了又归还?TreasureDAO安全事件分析》
在本次事件攻击事件中,攻击者信息如下:
交易发起地址:
Arbitrum:0x9b1acd4336ebf7656f49224d14a892566fd48e68
漏洞合约:
Arbitrum:0x812cda2181ed7c45a35a691e0c85e231d218e273
Arbitrum:0x57dc8e6a28efa28ac4a3ef50105b73f45d56615d4a6c142463b6372741db2a2b
TreasureMarketplaceBuyer合约的buyItem函数在传入_quantity参数后,并没有做代币类型判断,直接将_quantity与_pricePerItem相乘计算出了totalPrice,因此safeTransferFrom函数可以在ERC-20代币支付数额只有0的情况下,调用TreasureMarketplace合约的buyItem函数来进行代币购买。
但是在调用TreasureMarketplace合约的buyItem函数时,函数只对购买代币类型进行了判断,并没有对代币数量进行非0判断,导致ERC-721类型的代币可以在无视_quantity数值的情况下直接购买,从而实现了漏洞攻击。
本次安全事件主要原因是ERC-1155代币和ERC-721代币混用导致的逻辑混乱,ERC-721代币并没有数量的概念,但是合约却使用了数量来计算代币购买价格,且最后在代币转账的实现中也未进行逻辑分离。
此外,在与NFT交易平台相关的漏洞中,除了上述由于NFT本身造成的漏洞外,还有由于平台本身存在安全问题而危害NFT交易的情况。如:近期发现的Opensea Wyvern 2.2合约漏洞,攻击者可以利用该漏洞窃取Opensea市场中具有活跃报价的用户WETH。所幸Opensea团队预先发现了该问题,并进行了及时的修复,尚无相关攻击产生。
郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。