威胁建模如何阻止Bybit 15亿美元的黑客攻击

本文分析了Bybit交易所15亿美元黑客攻击事件,探讨威胁建模如何识别操作安全漏洞。文章详细介绍了威胁建模在区块链安全中的应用方法,包括组件识别、信任区域映射和威胁场景开发,并提供了具体的安全控制建议。

威胁建模如何阻止Bybit 15亿美元的黑客攻击

理解区块链安全中的威胁建模

2025年2月21日,加密货币交易所Bybit遭受了毁灭性的15亿美元黑客攻击,这是加密货币历史上最大的黑客事件。这不是由于智能合约缺陷或编码错误,而是一个复杂的操作安全故障,允许攻击者入侵签名者设备并操纵交易数据。

这次攻击遵循了我们过去一年观察到的令人不安的模式,类似的事件发生在WazirX(2.3亿美元)和Radiant Capital(5000万美元)。在每种情况下,攻击者都针对人力和操作元素,而不是利用代码漏洞。

随着攻击者从技术利用转向操作安全漏洞,威胁建模变得至关重要。传统的代码审计发现代码中的实现问题,但只有全面的威胁建模才能揭示导致这些最新漏洞的系统性操作和设计弱点。

在Trail of Bits,我们多年来为区块链组织进行了大量威胁模型,尽管大多数评估仍然是保密的,因为客户通常拒绝发布它们。这在行业中造成了关于威胁模型在预防像Bybit所经历的那种毁灭性攻击方面的有效性的信息差距。

基于我们之前对Bybit黑客攻击的分析,我们讨论了操作安全故障时代已经到来,现在我们将探讨具体的威胁建模技术,这些技术可以在漏洞被利用之前识别它们。

通过威胁建模视角看Bybit黑客攻击

威胁建模是一种结构化方法,用于识别系统架构、数据流、操作流程和人为因素中的安全风险。与发现实现错误的代码审查审计不同,威胁模型揭示了系统性和操作性的弱点——正是这种弱点导致了Bybit的黑客攻击。

我们的方法分解如下:

  • 建立安全控制集:我们基于NIST SP 800-53建立一组安全控制,并使用这些控制来指导参与。
  • 组件识别:我们识别所有范围内的系统组件,从钱包基础设施到API服务、用户界面、内部管理工具和第三方集成。
  • 参与者分析:我们识别所有与系统交互的参与者,包括合法用户、管理员和潜在攻击者。这帮助我们理解谁可以访问什么以及他们拥有什么权限。
  • 信任区域映射:我们根据共享目的、所有权或潜在损害级别将组件分组到“信任区域”。信任区域由信任边界界定,这些边界通常发生在需要身份验证和授权以获得系统内更高权限级别的地方。
  • 数据流分析:我们映射数据如何在组件之间和跨信任边界移动,识别敏感信息可能被暴露或操纵的地方,以及哪些威胁参与者可能这样做。
  • 威胁场景开发:对于每个信任边界跨越,我们分析潜在的攻击向量,并开发现实的威胁场景,展示设计漏洞如何被利用。

Bybit黑客攻击:威胁建模视角

Bybit黑客攻击展示了一个复杂的操作安全漏洞,我们相信通过将全面威胁建模紧密集成到交易所的软件开发生命周期中,可以识别和缓解这种漏洞。让我们通过这个视角来审视发生了什么。

攻击机制和失败的控制

攻击者入侵了所有Bybit多签签名者使用的Safe签名前端。当这些人认为他们在授权常规交易时,他们实际上是在签署更改其Safe多签钱包实现地址的交易,并将其替换为恶意实现,从而完全绕过多签的安全意图,授予攻击者控制权。

攻击者利用了合约的EVM delegatecall功能,并部署恶意软件来操纵签名界面。签名者无法看到他们签署的内容,原因有两个关键问题:修改钱包界面的恶意软件和硬件钱包上的盲签名限制,这些钱包不显示用户正在签署的完整语义信息。

在软件开发生命周期(SDLC)的设计阶段执行威胁模型可能已经告知Bybit,他们的系统包含以下需要缓解的控制故障:

  1. 端点安全控制

    • 描述:冷钱包的签名者可能使用通用工作站进行敏感交易签名操作,为设备入侵创造了广泛的攻击面。
    • 识别风险:签名者设备的入侵可能导致交易操纵。
    • 建议:实施具有有限连接性的专用签名工作站,如果设备必须在线,则添加增强监控。此外,可以向系统添加智能合约,以时间锁定资金移动,为事件响应留出时间,或完全限制资金发送的位置。
  2. 交易验证过程

    • 描述:冷钱包签名者可能依赖单一验证界面,没有二次确认机制,使签名者无法检测被操纵的交易细节。
    • 识别风险:盲签名可以隐藏交易细节。
    • 建议:使用交易验证脚本(如@pcaversaccio维护的脚本)实施二次验证。这应在单独的安全工作站上执行,以减少受入侵签名者工作站的影响,签名者应彻底比较验证脚本和硬件钱包显示的交易哈希值(逐字节)。
  3. Safe钱包配置

    • 描述:多签钱包配置为允许delegatecall操作,这使得攻击者能够更改钱包的具体实现。
    • 识别风险:delegatecall操作可以更改由离线或部分离线签名者工作站签署的交易语义。虽然delegatecall操作本身不是漏洞,但在这个系统中的使用造成了设计弱点。
    • 建议:完全禁用delegatecall功能,或者设计链上组件,使签名仅对通过delegatecall调用的特定实现有效。
  4. 操作隔离

    • 描述:Bybit可能缺乏企业基础设施和关键签名基础设施之间的适当分离,可能允许企业网络入侵影响签名操作。
    • 识别风险:企业基础设施入侵影响签名基础设施。
    • 建议:实施物理和逻辑上分离的基础设施的空气隔离签名程序。

将威胁建模引入组织

随着区块链行业操作安全故障的增加,实施强大的威胁建模程序不再是可选的——而是必需的。较小的组织应从Rekt Test开始,这是我们评估基本安全控制的简单框架。Rekt Test是更大威胁建模旅程的理想起点。

较大的组织需要更多考虑。在进行具体的威胁建模工作之前,他们应专注于以下基础步骤:

步骤1:设定正确的范围和节奏

有效的威胁建模始于清晰识别如果被攻击者入侵,哪些资产和操作将对系统产生最大影响。优先考虑最关键的项目,如钱包基础设施、交易签名和其他特权访问系统。

将威胁建模视为一个持续过程而非一次性练习也很重要。基础设施随时间变化,威胁模型必须随之变化。定期(每季度或每半年)更新模型,以及在重大架构更改、新功能启动或操作变化后进行更新。

步骤2:与现有流程集成

威胁建模只有在与现有开发生命周期和操作工作流结合时才能提供价值。这些工作流的所有者是关键利益相关者,您需要他们的支持才能成功将威胁建模集成到组织中。

以下是威胁建模可以有效的几个推荐接触点:

  • 嵌入软件开发生命周期(SDLC):在设计过程早期纳入威胁建模,而不是等到设计最终确定后才启动威胁模型。这降低了修复不安全设计的成本,并让团队更好地了解在设计系统时需要防御的威胁类型。提议的设计更改应附带说明其采用将如何影响系统的威胁模型和攻击面。
  • 连接到风险管理:确保威胁模型结果输入组织的安全路线图和风险登记册。如果威胁模型不用于告知未来的风险管理决策,那么它将不提供价值。
  • 与事件响应对齐:基于威胁模型中的场景进行桌面练习和事件响应计划。将这些过程与威胁建模的期望对齐,减少事件响应团队遇到的意外数量。
  • 补充现有安全测试和审计:使用威胁模型指导内部和外部渗透测试、代码审查、审计和其他安全评估的范围和重点。当威胁参与者及其能力被充分理解时,这些安全控制更加有效。

步骤3:优先考虑安全投资

每个组织都有有限的资源。使用威胁模型指导安全投资决策,将资源导向最弱的防御和最重要的安全关注点:

  • 基于风险的方法:根据潜在影响和利用可能性优先处理威胁。
  • 深度防御策略:投资于预防、检测和响应能力,而不是仅仅专注于预防控制。
  • 衡量控制有效性:定期评估实施的控制是否带来预期的风险降低。

Trail of Bits如何帮助

Trail of Bits提供为区块链组织量身定制的全面威胁建模服务。我们的方法可以与您现有的安全计划无缝集成:

  • 基于组件的方法:我们识别所有相关系统组件、信任边界、数据流和范围内的威胁参与者,构建威胁环境的整体视图。
  • 场景开发:基于我们在加密货币漏洞方面的丰富经验,开发现实的攻击场景。
  • 成熟度评估:我们根据行业最佳实践评估您的安全控制,并提供清晰的改进路线图。
  • 知识转移:我们在整个过程中与您的团队协作,确保您获得维护和更新威胁模型所需的技能。

我们的威胁建模专家已帮助众多加密货币交易所、协议和区块链平台在关键安全漏洞被利用之前识别和解决它们。通过与Trail of Bits合作,您不仅获得威胁模型——还在与日益复杂的攻击者的持续军备竞赛中获得战略优势。

威胁建模作为战略防御

Bybit黑客攻击表明,区块链空间的安全需要的不仅仅是安全代码——它需要系统性的方法,考虑人为因素、操作流程和技术控制。

虽然威胁建模是一种强大的技术,但重要的是要认识到它只是全面安全计划的一个组成部分。为了使威胁建模真正有效,它必须与其他安全学科无缝集成,包括风险管理、安全开发实践、事件响应计划和日常操作流程。这种整体方法创建了多层防御,可以承受我们最近看到的复杂攻击。

问题不再是您的组织是否有能力投资于威胁建模——而是您是否承担得起不投资的风险。

注意:这些示例基于我们对事件的外部知识和可用事实的推断。一些示例发现可能不准确反映Bybit的安全实践或事件中实际发生的情况。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计