Radiant Capital 事件后总结

2024年10月16日，Radiant Capital遭遇安全漏洞，损失约5000万美元。攻击者通过精密的恶意软件注入，成功篡改了至少三名长期贡献者的硬件钱包。这些开发者使用硬件钱包，且地理位置分散，这降低了被物理攻击的可能性。攻击者在正常的多重签名交易过程中，以合法的交易数据诱骗签名，导致数百万美元被盗。事件引发了广泛的安全讨论，强调了在DeFi环境中，盲签名及常见错误消息可能掩盖更深层次问题的风险。为避免类似事件，建议实施多层签名验证、独立设备校验、增强硬件钱包安全性等监控和审计机制。

事件摘要

2024年10月16日，Radiant Capital 遭遇了安全漏洞，导致约5,000万美元的损失。此次攻击涉及三位 Radiant 开发者，他们都是 DAO 中长久以来带头和受信任的贡献者。这些开发者使用硬件钱包，并分布在不同地区，减少了协调物理攻击的可能性。

攻击者通过复杂的恶意软件注入管理了至少这三位核心贡献者的设备。这些被攻陷的设备随后被用来签署恶意交易。

虽然已经确认有三台设备被攻陷，但很可能还有更多设备受到攻击——它们被攻陷的方式仍然未知，目前在调查中。这些设备的被攻陷方式是， Safe{Wallet} （前称 Gnosis Safe）前端显示合法的交易数据，而恶意交易则在后台被签署和执行。这一漏洞发生在常规的多签名发行调整过程中，该过程会定期进行以适应市场条件和利用率。

DAO 贡献者在整个过程中严格遵循行业标准操作程序（SOP）。每一笔交易都在 Tenderly 上进行了准确性模拟，并在每个签名阶段由多个开发者单独审核。在这次审核中， Tenderly 和 Safe 的前端检查都没有显示出任何异常。

为了强调这一点，漏洞在 Gnosis Safe 用户界面和 Tenderly 模拟阶段的人工审核中是 完全不可察觉 的。这一点得到了包括 SEAL911 和 Hypernative 在内的外部安全团队的确认。

所有三笔多签名交易的前端验证没有显示出任何受损的迹象，除了由于失败所导致的 Safe 应用交易重新提交。需要强调的是，因失败重新提交 Safe 交易是常见且预期的情况。由于气体价格波动、nonce 不匹配、网络拥堵、气体限制不足、智能合约执行错误、代币不足、待处理交易、前端同步问题、超时或在多签名设置中权限/签名错误，提交到 Safe 前端的交易可能会失败。因此，这一行为并没有引起立刻的怀疑。恶意行为者利用了这种常态，通过这一过程多次获取了多个被攻陷的签名，所有这一切都在模仿常规交易失败的表象下进行。

攻击者随后从 Arbitrum 和 BSC 的核心市场中抽走了大约5,000万美元。此外，他们利用开放的批准从用户账户中提取资金。所有 Radiant 平台的用户被强烈建议撤销 所有 链上的批准 — Arbitrum，BSC，Ethereum 和 Base。

DAO 一直在与美国执法机关和 ZeroShadow 密切合作，并与这两个团体保持良好的关系。他们对漏洞情况完全知情，并正在积极努力冻结所有被盗资产。DAO 对此次攻击感到非常震惊，并将继续提供24/7的支持，协助各主管机关识别攻击者并尽快追回失窃资金。

攻击向量和方法论

攻击者的目标是从硬件钱包中获得三项多签名批准，以授权 transferOwnership 操作。他们成功攻陷了多位开发者的设备——至少有三台，不过确切数量仍未确定。目前还尚不清楚设备是如何被攻陷的。攻击利用了一种复杂的方法，通过使用 Safe{Wallet} 验证交易的开发者在前端呈现出合法的交易。

当他们批准交易时，被攻陷的设备拦截了该批准，转而向硬件钱包发送一笔恶意交易进行签名。之后，Safe 钱包界面显示错误消息，促使用户再次尝试签名。该过程为攻击者提供了三个有效但恶意的签名。

尽管进行了多层验证，包括通过 Tenderly 和其他审计工具审核交易，签名的交易在界面上看起来正常。Ledger 硬件钱包上显示的盲签名也看起来有效，为攻击者的方法增加了另一层混淆。这些策略使得攻击者能够在不被注意的情况下进行转移。

安全影响

此次攻击最令人担忧的方面是涉及的高水平的复杂性。被攻陷的设备未显示出任何明显的警告信号，超出签署过程中出现的小故障和错误消息——与硬件钱包和 Safe 交互时常遇到的问题。这些看似常规的错误消息是更深层次问题的唯一指标，而在正常情况下，这不会引起立刻的担忧。

预防性建议：

正在评估漏洞的各个小组认为，这是 DeFi 领域中记录到的最复杂的黑客攻击之一，许多协议面临风险。为减轻未来类似攻击的发生，以下策略应予以考虑：

  1. 多层签名验证： 实施治理层，如果一个或多个签名者遇到问题或异常，流程将在继续之前暂停以进行进一步验证。当即使一个签名者遇到错误时也应触发审核。一个错误可以简单得多，比如应该被接受的交易未通过，从而提示请求新签名。

  2. 独立设备验证： 在签名前使用一个未被攻陷的独立设备来验证交易数据。该设备应生成可读的签名验证代码，与呈递给硬件钱包的数据匹配。

  3. 增强 Ledger/Trezor 安全： 避免在关键交易中使用盲签。如果不可避免，确保任何涉及硬件钱包的合约交互需要一个可见验证的额外层，例如在硬件钱包上显示以可读格式的交易数据。

  4. 错误触发的审计： 集成一个机制，使得反复交易错误或故障自动触发对交易的全面审计，方可进行额外的签名尝试。

  5. 手动审核交易负载： 在请求签名时从钱包提供商（如 Metamask, Rabby）取出 原始交易数据 并将其输入到 https://etherscan.io/inputdatadecoder。确认您调用的 "function" 及 "ToAddress" 是否与预期行为匹配。如果设备被攻陷，在上述案例中，它要么根本无法解码，要么调用与您认为要调用的不同的函数，或将结果指向不同的拥有者地址。还强烈建议验证每条消息哈希与 Gnosis 上的硬件钱包匹配： https://help.safe.global/en/articles/40831-how-to-verify-safe-transactions-on-a-hardware-wallet

事件后的结论

此次攻击对三位 Radiant 开发者造成了影响，他们都是 DAO 中长久以来受信任的贡献者。攻击者使用恶意软件在设备级别操控了交易数据，绕过了 Tenderly 中的手动检查和模拟，这些检查返回了正常的结果。被攻击的设备使得攻击者能够通过看似合法的虚假交易收集多个被污染的签名。

虽然硬件钱包一般情况下是安全的，但在 DeFi 环境中使用盲签署有其显著的风险。攻击者通过在 Gnosis Safe 中呈现正常的交易（没有明显的异常，除了常规交易失败）来利用这一点—这是一种常见现象，使得检测变得困难。

作为紧急的预防措施，安全小组的每个成员均使用新的、未被攻陷的设备创建新的冷钱包地址，以确保没有遗留的脆弱性。DAO 已显著加强了 Admin 和 DAO 多签名（其他 Safe 将随后进行）的安全性，限制了签名者数量至7位，新签名阈值为4/7，这确保了将近60%的签名者必须批准交易后才能执行。

此外，贡献者将会为每一笔交易使用 Etherscan 上的输入数据解码器进行二次确认，提供额外的准确性层，在进行签名之前。

预计 DAO 会在数天内重新启动 Base 和 Eth 市场。

DAO 还将为 RIZ 市场创建新的 Safe，并将 RizRegistry 合同的所有权转移到这些安全 Safe 以确保与核心市场的隔离。

所有合约的升级与所有权转移还将受到最低72小时的延迟，采用新实施的延时合约。此延迟将为社区和开发者提供充分的时间在更改生效之前进行审查和验证。但是这也可能拖延对关键漏洞的响应，尚不清楚延迟是否能阻止此次攻击，因为三位签名者的设备均已被攻陷。

在我们的关键合约中，权限角色被分开，以确保没有单一角色掌握“超级”权限。通过将责任分配到多个角色，DAO 显著降低了任何一个个体或群体获得过度控制的风险。

最后，为了重新启动 Arbitrum 和 BSC 上的核心市场，DAO 将重新部署整个 Aave V2 借贷套件，包括以下合约：

  • LendingPoolAddressesProvider
  • LendingPoolAddressesProviderRegistry
  • LendingPool
  • LendingPoolConfigurator
  • LendingPoolCollateralManager
  • LendingRateOracle
  • AaveOracle
  • AaveProtocolDataProvider

在此过程中，DAO 与美国执法机构和 ZeroShadow 紧密合作，并与这两个团体保持良好关系。他们对漏洞情况完全知情，并在积极努力尽可能冻结所有资产。DAO 对此次攻击深感震惊，并将继续提供24/7的服务，协助各机构识别攻击者并尽快恢复被盗资金。

详细事件时间线

2024–10–02

  • 01:12:37 UTC

Arbitrum： 通过交易 https://arbiscan.io/tx/0x149bd3b684cf63decffbdd1865a20fddf131fb59469d093b2b6d9aa57a0ce4c2 部署了一份恶意合约。该合约计划在几天后被用于恶意目的。

合约: https://arbiscan.io/address/0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5。

  • 08:22:46 UTC

BSC： 在 Binance Smart Chain 上通过交易 https://bscscan.com/tx/0x65419cd822bb616f2d9dacbcfacf81714761f9815cc26b9451cd70f0348232fa 部署了一份类似的恶意合约。

合约: https://bscscan.com/address/0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5

相同或类似的恶意合约也在 Base 和 Ethereum 主网部署，但最终未能成功执行：

2024–10–16

  • 15:46 UTC：开发者 “C1” 提出了交易 ARB Nonce 230 以更新供给和借贷上限。在此过程中，交易签名至少失败了三次，初步归咎于 RPC 问题。

为了解决问题，C1 更换了 Arbitrum RPC，使用了 chainlist.org 上第一个可用的选项，最终成功签署了交易。然后，按照 SOP，此交易在 Telegram 的 “RADIANT — Multisig” 群组中的 #admin 频道中宣布。接着发布了以下消息：

这是 C1 构造的原始 Nonce 230 交易：

但是，ARB Nonce 230 随后在17:09 UTC被覆盖（见下文），并被 恶意交易 替换，该交易调用了 transferOwnership 功能：

有一点需要注意——截至目前，从 URL 查看已取消的 ARB Nonce 230 时，用户界面中的时间戳似乎是观看者当前的时间。因此，用户界面时间戳显示“少于一分钟前”，尽管这在时间上是不准确的。

  • 17:04 UTC：开发者 C2 提出了更新 Ethereum 主网的交易，基于 ETH Nonce 127，Arbitrum 和 BSC 链更新 RDNT 代币分配率。然而，Nonce 127 被替换以转移所有权并执行恶意代码。C2 指出，在此期间他的 Rabby 钱包遇到问题。

  • 17:09:18 UTC：上述恶意交易替换了 ARB Nonce 230，将 LendingPoolAddressesProvider 的所有权转移给新的所有者。交易： https://arbiscan.io/tx/0x7856552db409fe51e17339ab1e0e1ce9c85d68bf0f4de4c110fc4e372ea02fb1。

  • 17:09:35 UTC：在主网上触发了自动暂停。

交易： https://etherscan.io/tx/0xa5dc1b97d72d11940d186596cb7478dedc27c8812c9d3bdf78eba5e8cf4f1006。

  • 17:09:40 UTC：在 BSC 链上引发了自动暂停。

交易： https://bscscan.com/tx/0x873c2382689cad921427e30f16a814ffb2c1e2550e316e767e66759f7abf4a34。

  • 17:11:00 UTC：BSC 链的 LendingPoolAddressesProvider 所有权被转移至 0x57ba8957ed2ff2e7AE38F4935451E81Ce1eEFbf5，绕过暂停并完成实现的升级。

交易： https://bscscan.com/tx/0xd97b93f633aee356d992b49193e60a571b8c466bf46aaf072368f975dc11841c。Hypernative 警报系统标记了可疑活动。开发者 C2 在 Telegram 上向团队发消息。

  • 17:12–17:43 UTC：团队紧急想要了解情况，并发起了第一次战情会议电话。
  • 17:43:41 PM UTC：执行了一笔交易以暂停 Base 上的 LendingPool。

交易： https://basescan.org/tx/0xdeee13d47eca82c8a774ec792f823360013f001e93b5abc17cb939f25187d00e。

考虑到潜在的“中间人”攻击威胁，安全团队确定必须在适当的风险评估后才能移除被攻陷的钱包。

备注

  • 一些开发人员在 Safe{Wallet} 应用中报告了签署交易的问题。开发者 C3 提到：

“在过去几周，我不得不在 Rabby 中两次签署交易。C2 也表示 RPC 问题。在黑客攻击后，我的 Rabby 钱包停止工作并消失，和 C2 的经历相似。”

  • C1 也报告了必须在初次失败后重新签署交易的问题。
  • Radiant 协议的常规更新需要 Admin 多签名的交易，这些交易在系统中拥有最关键的权限。

被攻陷的钱包

  • 0x20340c2a71055FD2887D9A71054100FF7F425BE5（使用 Rabby 管理的 Ledger 硬件钱包）
  • 0x83434627e72d977af18F8D2F26203895050eF9Ce（使用 Rabby 管理的 Ledger 硬件钱包）
  • 0xbB67c265e7197A7c3Cd458F8F7C1d79a2fb04d57（使用 Frame 管理的 Trezor 硬件钱包）

Admin 多签名钱包和签名阈值（在漏洞发生时）

  • Ethereum： 0x0235a22a38Dd09291800e097bD2ebE6e3b4d5F04（3/9）
  • BSC Chain： 0xE4714D6BD9a6c0F6194C1aa8602850b0a1cE1416（3/11）
  • Base： 0xBBf7eDF92926b775A434f9DF15860f4CD268B0A0（3/9）
  • Arbitrum： 0x111CEEee040739fD91D29C34C33E6B3E112F2177（3/11）

已知攻击者钱包

  • 0x0629b1048298AE9deff0F4100A31967Fb3f98962（主要攻击者）
  • 0x57ba8957ed2ff2e7ae38f4935451e81ce1eefbf5（主要攻击合约）
  • 0x911215CF312a64C128817Af3c24B9fDF66B7Ac95（测试地址）
  • 0x97a05becc2e7891d07f382457cd5d57fd242e4e8（洗钱地址）
  • 0x9c5939AAC4f65A0eA233E657507C7b54acDE2841（洗钱地址）
  • 0x8B75E47976C3C500D0148463931717001F620887（在 Arbitrum 和 Eth 上合并的资金）
  • 0xcF47c058CC4818CE90f9315B478EB2f2d588Cc78（在 BSC 上合并的资金）
  • 0xa0e768a68ba1bfffb9f4366dfc8d9195ee7217d1（GMX 互动 / 交换）
  • 0xc24927Bd40Bab67CcfB2ca0A90d6cbB8Edb21302（在 Arbitrum 上的批准提取）
  • 0x579145D6d1F26a460d9BDD3040C37517dac379ac（在 BSC 上的批准提取）
  • 0xC4173a794122644870C8fd07c226acF992507897（在 BSC 和 ARB 上的批准提取）
  • 0x3D4C56cdB97355807157F5C7d4F54957f0E9af44（在10月17日创建的合约）
  • 0x3c09Ae8571db07a3347c1D577BB9a54F96bFfa24（在10月17日创建的合约）
  • 0xbc20e84d80a684dAEa4468be6F199a233A3d2363（测试合约）
  • 0x5eb63694A18B618C4EbDd9CA3333fa7f9b8B9cB4（与测试合约相关）
  • 0xD899F3d8ff2A723642d5C55eD1998713C530b7b3（与测试合约相关）

  • 原文链接： medium.com/@RadiantCapit...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，在这里修改，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
RadiantCapital
RadiantCapital
江湖只有他的大名，没有他的介绍。

RadiantCapital

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！