ETH:白帽黑客samczsun:针对NFT资产的攻击会越来越频繁

注:原文作者是拥有“审计上帝”之称的白帽黑客samczsun,同时他也是Paradigm的研究合伙人,其最近出手拯救了BitDAOMISO荷兰拍卖资金池中的3.5亿美元资产,而在这篇文章中,他提醒了关于NFT代币标准的潜在安全风险,他还预测称,随着ERC-721和ERC-1155代币标准变得越来越流行,针对NFT的攻击很可能会越来越频繁。

如果你从事软件工程方面的工作,很可能你听说过至少一条软件工程原则。虽然我不主张严格遵守每一条原则,但有一些确实是值得关注的。

我今天要讲的就是最小惊讶原则,它有一个奇特的名字,但却是一个非常简单的想法。它所说的是,当呈现声称要做某件事的代码时,大多数用户都会假设它是如何完成这件事的。因此,作为开发人员,你的工作是编写符合这些假设的代码,这样你的用户就不会感到意外。

这是一个很好的原则,因为开发人员喜欢对事物进行假设。如果你导出一个名为calculateScore(GameState)的函数,很多人就会假设该函数只会从游戏状态中读取。如果你还改变了游戏状态,你会使得很多人面临困惑的状态,他们试图弄清楚为什么他们的游戏状态会随机被破坏。即使你把它放在文档中,仍然不能保证人们会看到它,所以最好首先确保你的代码不会令人惊讶。

JPEG'd已收到白帽黑客返还的5494.4枚WETH:8月5日消息,DeFi公共产品JPEG'd发推称,DAO多签地址确认收到5494.4枚WETH,从pETH漏洞中追回资金的地址所有者获得了10%(610.6枚WETH)的白帽赏金。[2023/8/5 16:20:11]

“6小时的调试工作,可以为你们节省5分钟的文档阅读时间。”

越安全越好,对吗?

早在2018年初,当ERC-721标准被起草出来时,有人就提出了实施转账安全性?的建议,以确保代币不会被卡在不用于处理代币的接受者合约中。为此,提案作者修改了transfer函数的行为,以检查接收方是否能够支持代币转账。他们还引入了unsafeTransfer函数,如果发送者愿意,该函数将绕过这个检查。

然而,由于担心向后兼容性,这个函数在随后的提交中被重命名了。这使得ERC-20和ERC-721代币的transfer函数表现相同。但是,现在需要将接收方检查转移到其他地方。因此,标准作者就引入了safe类函数:safeTransfer以及safeTransferFrom。

Arbitrum因代码漏洞向白帽黑客支付400ETH:9月21日消息,一名匿名白帽黑客0xriptide因发现Arbitrum支付代码漏洞获得了400ETH(约52万美元)的奖励,该漏洞涉及2.5亿美元资产。

据0xriptide透露,其在Arbitrum Nitro升级前几周开始寻找漏洞,最终发现该漏洞能让桥接合约在启动之前完成初始化并接受存款,这意味着黑客可以将自己的地址设置桥接地址并模仿实际合约,并接受ETH存款。[2022/9/21 7:10:13]

这是一个关于正当性问题的解决方案,因为有许多ERC-20代币被意外转移到从未期望收到代币的合约的例子。而在起草ERC-1155标准时,提案作者从ERC-721标准汲取了灵感,不仅在转账时,而且在铸造也纳入了接收方检查,这一点也不足为奇。

在接下来的几年里,这些标准大多处于休眠状态,而ERC-20代币标准保持了它的流行状态,而最近gas成本的飙升,以及社区对NFT兴趣的增强,自然而然导致开发者越来越多地使用ERC-721和ERC-1155代币标准。有了这些新的兴趣,我们应该庆幸这些标准的设计考虑了安全性,对吗?

越安全越好,真的吗?

Ok,但对于转帐和铸造来说,安全意味着什么呢?不同的当事人对安全有不同的解释。对于开发人员来说,一个安全函数可能意味着它不包含任何bug或引入额外的安全问题。而对于用户来说,这可能意味着它包含额外的护栏,以保护他们不被意外射中自己的脚。

Nomad:已追回1660万美元资金,其中白帽黑客主动归还1120万美元:8月4日消息,Nomad在推特上公布Nomad Bridge资金返还情况,总计1120万美元返还至官方地址,具体如下:

- ???.eth (400万美元);

- 0xE3F40743cc18fd45D475fAe149ce3ECC40aF68c3(340万美元);

- darkfi.eth (190万美元);

- returner-of-beans.eth(100万美元);

- anime.eth(90万美元)。

Nomad表示,截至目前总共追回1660万美元资金。希望退还资金的白帽黑客请将ETH/ ERC-20代币发送到官方以太坊钱包地址0x94A84433101A10aEda762968f6995c574D1bF154。[2022/8/4 5:15:06]

事实证明,在这种情况下,这些函数更多的是后者,而较少会是前者。这是特别令人遗憾的,因为在transfer和safeTransfer函数之间进行选择时,你为什么不选择安全的那个函数呢?名字都体现出来了!

好吧,其中的一个原因可能是我们的老朋友reentrancy,或者我一直在努力将其重命名为:不安全的外部调用。回想一下,如果接收方是攻击者控制的,则任何外部调用都可能不安全,因为攻击者可能会导致你的合约转换为未定义状态。根据设计,这些“安全”函数执行对代币接收者的外部调用,通常在铸造或转移期间由发送者控制。换句话说,这实际上是不安全外部调用的教科书示例。

Gearbox Protocol 已修复白帽黑客在 Immunefi 上提出的漏洞:金色财经消息,DeFi 可组合性杠杆协议 Gearbox Protocol 在推特上宣布,目前已修复白帽黑客在 Immunefi 上提出的漏洞,协议已恢复正常使用。Gearbox 表示,此前发现的漏洞与 Uniswap V3 的适配器相关,目前已部署新的适配器,协议已恢复正常使用,此期间没有资金收到损失。此外,Gearbox 已经向白帽黑客支付了超过 15 万美元的漏洞赏金。[2022/3/27 14:21:08]

但是,你可能会问自己,如果允许接收方合约拒绝他们无法处理的转账,那最坏的后果是什么?好吧,让我通过两个案例研究来回答这个问题。

例子1:Hashmasks

Hashmasks是一个供应有限的NFT头像项目,用户每次交易最多可以购买20个maskNFT。下面是购买mask的函数:

O3 Swap:白帽黑客已归还所有剩余资金,O3跨链池将尽快恢复:8月23日消息,O3 Swap在推特发文表示,白帽黑客已通过链上交易信息公布了多签地址的私钥,归还了剩余资金。作为对白帽先生的感谢,O3Labs 团队将根据官方发布的”O3 Bug Bounty“的最高额奖金,向白帽先生的地址转账价值 20 万美金的 O3。团队将尽最快速度恢复O3跨链池,重建 O3 Swap。[2021/8/23 22:32:01]

你可能觉得这个函数看起来非常合理。然而,正如你可能已经预料到的,在_safeMint调用中隐藏着一些险恶的东西。让我们来看看。

为了安全性,这个函数对token的接受者执行了一次callback回调,以检查他们是否愿意接受转账。然而,我们是token的接收者,这意味着我们刚刚得到了一次callback回调,在这个点上我们可以做任何我们想做的事情,包括再次调用mintNFT函数。如果我们这样做,我们将在仅铸造了一个mask后重调用该函数,这意味着我们可以请求再铸造另外19个mask。这导致最终铸造出了39个maskNFT,尽管规则允许铸造的最大数量只有20个。

例子2:ENS域名封装器

最近,来自ENS的NickJohnson联系了我,他想让我看看他们正在进行的ENS域名封装器工作。这个域名封装器允许用户用新的ERC-1155token代币化他们的ENS域名,这提供了对细粒度权限以及更一致的API的支持。

概括地说,为了封装任何ENS域名,你必须首先批准域名封装器以访问你的ENS域名。然后,你调用wrap(bytes,address,uint96,address),它既为你铸造一个ERC-1155token,也负责管理底层的ENS域名。

下面就是这个wrap函数,它相当简单。首先,我们调用_wrap,它执行一些逻辑并返回哈希域名。然后,我们确保交易发送方确实是ENS域名的所有者,然后再接管该域名。请注意,如果发送方不拥有底层的ENS域名,则整个交易应还原,撤销在_wrap中所做的任何更改。

下面是_wrap函数本身,这里没有什么特别的。

不幸的是,正是这个_mint函数,它可能会给毫无戒心的开发者带来可怕的惊喜。ERC-1155规范规定,在铸造token时,应咨询接收者是否愿意接受该token。在深入研究库代码后,我们发现情况确实如此。

但这到底对我们有什么好处呢?好的,我们再一次看到了一个不安全的外部调用,我们可以用它来执行重入攻击。具体地说,请注意,在callback回调期间,我们拥有了代币ENS域名的ERC-1155token,但域名封装器尚未验证我们拥有基础ENS域名本身。这使我们能够在不实际拥有ENS域名的情况下对其进行操作。例如,我们可以要求域名封装器解开我们的域名,燃烧掉我们刚刚铸造的token并获取底层的ENS域名。

现在我们拥有了底层的ENS域名,我们可以用它做任何我们想做的事情,比如注册新的子域名或者设置解析器。完成后,我们只需退出callback回调。域名封装器将和底层ENS域名的当前所有者交互,并完成交易。就像那样,我们已经取得了域名封装器被批准用于的任何ENS域名的临时所有权,并对其进行了任意更改。

结论

令人惊讶的代码可能会以灾难性的方式破坏事物。在本文的两个案例下,开发人员合理地假设safe函数类可以安全地使用,却无意中增加了他们的攻击面。随着ERC-721和ERC-1155代币标准变得越来越流行及广泛,这类攻击情况很可能会越来越频繁。开发人员需要考虑使用safe类函数的风险,并确定外部调用如何与他们编写的代码进行交互。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金星链

[0:15ms0-1:305ms