智能合约中的安全实现与脆弱集成：ERC-2771危机管理

作者：Vlad Estoup 和 Pedro Aisenson 应对措施

1. 红色代码

2. 最初的恐慌

3. 监控和分类

4. 最初的事件和公开

经验教训

1. 库和安全标准并非即插即用

2. 及时、负责任的沟通

3. 应对漏洞和事件的能力

4. 全生态系统范围的努力

应对措施

I. 红色代码

美国东部时间 12 月 4 日星期一下午 4 点，OpenZeppelin 团队收到 Thirdweb 的通知，得知一个漏洞源于元交易 (ERC-2771) 与使用用户控制数据的自委托调用的结合，这在 Multicall 标准中经常看到。有关完整的技术解释，请查看我们的深入技术披露。

在最初的私下披露时，我们意识到该漏洞已经在外面存在一段时间了，并且有几个项目存在风险。

II. 最初的恐慌

Thirdweb 的 最初公开披露 错误地推断出该漏洞源于“web3 行业中常用的开源库”，这错误地牵涉到 OpenZeppelin Contracts 库。这在社区中引起了广泛的、没有根据的恐慌。

我们必须小心如何解释该漏洞，并向社区保证 OpenZeppelin Contracts 库的安全性——我们团队最不希望做的事情是向黑客提供他们可以用来攻击项目的信息。周二，我们的团队一直工作到凌晨，撰写了一条令人安心的消息。它必须提供信息和以解决方案为导向，同时对问题的具体性质保持模糊。

OpenZeppelin 团队昨天（12 月 4 日）美国东部时间下午 4 点收到来自 @thirdweb 的通知，得知一个安全漏洞涉及但不限于 Thirdweb 版本的 DropERC20、ERC721、ERC1155（所有版本）和 AirdropERC20 预构建合约。

据我们所知，这个...

— OpenZeppelin (@OpenZeppelin) 2023 年 12 月 5 日

虽然 OpenZeppelin 库经过实战测试，并且仍然是最安全的，用于智能合约开发，但所有软件都可能容易出现错误，并且当用户进行集成时，无法保证安全的互操作性。因此，关于广泛使用的库中存在错误的最初说法是基于对库的安全范围的误解。ERC-2771 和 Multicall 都不需要或确保相互兼容性。在这些标准的许多不同实现中观察到的漏洞突出了不正确集成单独安全组件的风险，强调了仔细的架构设计和彻底的安全审计的必要性。

也就是说，我们保护区块链社区和生态系统的承诺促使我们领导这项工作：评估社区中谁受到了影响，为他们提供缓解策略，并在适当的时候进行负责任的披露。

III. 监控和分类

行动方案是确定谁可能面临风险，通知他们的团队，并帮助他们实施缓解策略。

检测哪些合约受到影响是一个挑战：ERC-2771 和 Multicall 都没有指定任何事件，这需要一种新颖的方法来处理我们现有的事件响应监控工具，这些工具侧重于事件识别。为了克服这个障碍，我们成功地采用了一种替代方法，依靠查询已验证合约中的代码模式。

为了获得额外的支持和社区参与，我们与该领域一些最著名的白帽创建了一个作战室，包括 Samczsun、David Benchimol 来自 Ironblocks 和 Yannis Smaragdakis 来自 Debaub。白帽团队迅速开始联系我们认为可能存在风险的主要协议。来自 Debaub 的 Yannis 和 Ironblocks 团队率先运行查询，以识别受 ERC-2771 和自委托调用组合影响的实例。与此同时，我们的合约和事件响应团队也进行了查询，使 OpenZeppelin 能够生成紧急分类的地址列表。

首先，我们审查了我们所有审计客户的代码库，筛选出那些实施 ERC-2771 的代码库。我们还监控了所有在 Etherscan 上验证的 OpenZeppelin Contracts 用户——突出了验证合约的重要性。每当我们发现命中时，我们的团队都会进行更深入的调查，以确定特定协议是否受到影响。然后通过私人渠道联系受影响的团队，并给出具体的保护自己的步骤。我们认为现在公开还为时过早，并密切关注生态系统周围的任何可能泄露信息的潜在漏洞。

与此同时，OpenZeppelin Contracts 开发团队正在开发该库的新版本，该版本将确保 ERC-2771 和 Multicall 之间的安全互操作性。

为了帮助联系或在 Twitter 上询问他们是否受到影响的项目，我们为他们提供了一个自助分类解决方案，以确定他们是否容易受到攻击。该团队在 Defender 的 Code Inspector 工具中发布了一个检测器，仅在 3 小时内就被 1000+ 协议使用。那些测试呈阳性的人可以直接与我们的团队进行沟通。

Contract Inspector 报告中紧急的未公开漏洞通知

感谢所有这些努力，像 Velodrome Finance 这样的团队迅速采取行动来保护他们的协议，并在不久后发布了公开声明。

IV. 最初的事件和公开

周三——在首次警报发出 40 小时后——公开披露之前的下一步是通知关键社区成员，特别是来自 EVM 链和 Layer 2 网络的安全代表。我们私下进行了外联，确保他们可以监控其社区内的问题。其中一些人随后发表了公开声明。

在已经通知了 EVM 链、我们的大部分审计客户以及已识别的易受攻击联系人列表后，我们得知持有近 90 ETH 的几个池已被黑客入侵。时间不多了。在链上观察到的第一个 黑客攻击 是一个涉及 Time 合约 的流动性池，Time 是一种使用 Thirdweb 代码的代币。幸运的是，该攻击被 MEV 机器人 抢先交易 了。然后，该信息在 Twitter 上泄露，并由于白帽社区的强烈反对而很快被删除。

现在，当我们与黑客赛跑时，我们面临着典型的困境。公开披露安全问题可能会警告未收到警报的协议，但肯定会同时通知黑帽。认识到熟练的黑客可能会从最近的主网攻击中推断出问题，并考虑到我们详尽的私人外联工作以及某些推文的临时公开曝光，我们得出结论，公开警告协议是净收益。在咨询了领先的白帽专家后，我们的评估得到了加强，他们同意我们的评估。

🚨 社区的重要安全警报 🚨

我们正在公开披露一个关键漏洞，该漏洞源于标准 ERC-2771 的问题集成，以及用户输入数据的自委托调用，包括但不限于 multicall。这个问题构成了重大的...

— OpenZeppelin (@OpenZeppelin) 2023 年 12 月 8 日

公开披露后，安全社区的反应迅速且具有协作性。多家安全公司和专家广泛分享调查结果，极大地扩大了信息的范围，确保大量协议收到潜在风险的警告。

这种经验证明了多个参与方采取积极主动和协调一致的行动以保护生态系统的有效性。展望未来，很明显，吸取的经验教训对于塑造 Web3 中未来的安全实践和漏洞管理策略将是宝贵的。

经验教训

I. 库和安全标准并非即插即用

即使是经过良好审计的安全代码，当以不可预见的方式组合时，也可能成为一种负担。导入依赖项时，请务必了解它们内部的工作方式，并考虑如何将它们与其他功能结合起来。

II. 及时、负责任的沟通

管理像这样的危机需要精确、有分寸的沟通，在不引起不必要恐慌的情况下传递信息。为了确保及时和私人的安全通知，请务必验证你的合约，并在每个合约的开头添加安全联系人作为注释。对于某些联系方式，由于 Twitter DM 是最佳联系方式，我们损失了 24 小时。

III. 应对漏洞和事件的能力

为了有效的事件响应，请确保你的合约是可升级的，并且你已断路器机制就位。

IV- 全生态系统范围的努力

多个参与方采取有效、积极主动和协调一致的行动是识别、React 和缓解全生态系统漏洞的关键。

• 原文链接： openzeppelin.com/news/se...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～