事件回顾

2025 年 2 月 21 日 UTC 时间下午 02:16:11，Bybit 的以太坊冷钱包（0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4）遭到攻击，约 401,346 ETH、15,000 cmETH、8,000 mETH、90,375 stETH 和 90 USDT 被转移至未知地址，总价值约 14.6 亿美元。

攻击者通过钓鱼攻击诱骗 Bybit 的多重签名钱包签名者签署恶意交易。具体步骤如下：

• 攻击者提前部署了恶意合约，包含资金转移的后门功能。
• 篡改 Safe 前端界面，使签名者在 Safe 上看到的交易信息与实际发送至 Ledger 硬件钱包的数据不一致。
• 通过伪造的界面，攻击者成功获取三个有效签名，将 Safe 多签钱包的实现合约替换为恶意合约，从而控制冷钱包并转移资金。

Sygnia 受 Bybit 委托进行取证调查，确定攻击的根本原因，目标是识别攻击范围和来源，并减轻当前和未来的风险。最新报告见：Bybit Interim Investigation Report。

目前为止，取证调查突出显示以下发现：

• 对所有用于发起和签署交易的主机的取证调查发现，在 Safe 的 AWS S3 存储桶中的资源被注入了恶意 JavaScript 代码。
• 资源修改时间和公开可用的网络历史档案表明，恶意代码的注入是直接在 Safe 的 AWS S3 存储桶中进行的。
• 对注入的 JavaScript 代码的初步分析表明，其主要目的是操纵交易，在签名过程中有效地更改交易内容。
• 此外，对注入 JavaScript 代码的分析发现了一个激活条件，该条件仅在交易来源匹配两个合约地址之一时才会执行：Bybit 的合约地址和一个目前未识别的合约地址（可能与威胁者控制的测试合约相关）。
• 在恶意交易执行并发布后两分钟，新版本的 JavaScript 资源被上传到 Safe 的 AWS S3 存储桶。这些更新版本已删除了恶意代码。
• 初步发现表明攻击源自 Safe 的 AWS 基础设施。
• 到目前为止，取证调查未发现 Bybit 基础设施有任何被入侵的迹象。

对三个签名者主机的取证调查表明，攻击的根本原因是来自 Safe 基础设施的恶意代码。

在 Bybit 的基础设施中未发现被入侵的迹象。

调查仍在继续，以进一步确认这些发现。

从目前的信息来看前端并不是这次的主要问题所在，主要对这次攻击要负责的是 AWS 上面的存储服务被黑了，JavaScript 被篡改，导致在 Safe 前端发起的交易内容被修改。但是前端方面，如果 Safe 前端做了基本的 SRI 验证，即使这个 JavaScript 被改了，也不会出事，这样来看前端是要有一定责任的。当然 Bybit 肯定也是要负责的，首先他们自己用的硬件钱包没有显示具体交易信息他们就确认了，本身他们对 Safe 前端的信任就是不可靠的。

硬件钱包在处理复杂交易时存在局限性，无法完整解析和显示多重签名钱包的详细交易数据，导致签名者在未完全验证交易内容的情况下进行“盲签”。

黑客很擅长利用交互过程的设计缺陷骗取用户资产，如：利用 UI 劫持、欺骗用户签名；利用盲签名欺骗用户签名；利用 Permit 签名盗取用户的资产；利用 TransferFrom 零转欺骗用户进行钓鱼；采用尾号相同空头实施骗局；对 NFT 进行钓鱼等其它通用的钓鱼手法。

随着 Web3 技术的快速发展，前端安全与区块链安全的边界逐渐模糊。传统前端漏洞（如 XSS、CSRF）在 Web3 场景下被赋予了新的攻击维度，而智能合约漏洞、私钥管理缺陷等问题则进一步放大了风险。

接下来我们从两个场景来分析一下前端开发和安全问题的关联。

场景一：交易参数篡改 —— 界面显示转账，实际执行授权

示例：前端展示与链上执行分离

// 前端显示转账 1 ETH
const showData = contract.interface.encodeFunctionData('transfer', [
  '0xUserAddress',
  ethers.parseEther('1')
]);

// 实际发起无限授权
const realData = contract.interface.encodeFunctionData('approve', [
  '0xAttackerAddress',
  ethers.MaxUint256
]);

// 发送欺骗交易
const tx = await signer.sendTransaction({
  to: contract.address,
  data: realData,
  customData: { 
    // 伪造前端展示数据
    security: { displayData: showData } 
  }
});

用户视角：
✅ 钱包弹窗显示 "Transfer 1 ETH to 0xUser..."
实际链上效果：
⚠️ 执行 approve(attacker, unlimited)，资产可被随时转走

怎么办呢？EIP-712 结构化签名验证

1. 前端生成可验证数据

const domain = {
  name: 'MyDApp',
  chainId: 1,
  verifyingContract: '0xContractAddress'
};

const types = {
  Transaction: [
    { name: 'action', type: 'string' },
    { name: 'to', type: 'address' },
    { name: 'amount', type: 'uint256' }
  ]
};

const value = {
  action: 'Transfer',
  to: '0xUserAddress',
  amount: '1000000'
};

// 生成签名
const sig = await signer.signTypedData(domain, types, value);

2. 智能合约验证签名

function execute(
  string calldata action,
  address to,
  uint256 amount,
  bytes calldata sig
) external {
  bytes32 digest = _hashTypedDataV4(
    keccak256(abi.encode(
      keccak256("Transaction(string action,address to,uint256 amount)"),
      keccak256(bytes(action)),
      to,
      amount
    ));
  require(ECDSA.recover(digest, sig) == msg.sender, "Invalid signature");

  // 执行逻辑
  if (keccak256(bytes(action)) == keccak256("Transfer")) {
    _transfer(to, amount);
  }
}

效果：任何前端参数篡改都会导致签名不匹配，交易自动回滚。

场景二：盲签劫持 —— 硬件钱包为何被攻破

示例：篡改 Ledger 解析规则

1. 攻击者劫持前端代码，向硬件钱包发送伪造的 calldata：

// 正常升级合约的 calldata
const realData = '0x095ea7b30000000000000000000...'; // approve(...)

// 篡改为 "升级合约" 的显示规则
const fakeDisplay = {
  type: 'contractUpgrade',
  info: '更新 v1.2 安全补丁'
};

// 发送至 Ledger
ledger.signTransaction(realData, fakeDisplay);

2. Ledger 屏幕显示：

[合约升级]  
类型: 安全补丁  
版本: v1.2  
✅ 确认签名  

实际执行：approve(attacker, unlimited)

怎么办呢？硬件钱包语义解析 + 链上二次验证

1. 升级硬件钱包固件支持 EIP-712

// Ledger 解析逻辑示例
void parse_calldata(const uint8_t *data) {
  if (is_eip712(data)) {
    display_struct_data(data); // 显示 "Transfer 1 ETH to 0x..."
  } else {
    display_hex(data); // 传统十六进制显示
  }
}

2. 链上强制语义匹配

function execute(bytes calldata data) external {
  (string memory action, address to, uint256 amount) = 
    abi.decode(data, (string, address, uint256));
  
  // 必须与签名类型匹配
  require(
    keccak256(bytes(action)) == keccak256(bytes("Transfer")),
    "操作类型不匹配"
  );
  
  _transfer(to, amount);
}

结语

前端安全与 Web3 安全的融合，既是挑战也是机遇。Bybit 被盗事件暴露了加密货币行业在安全管理和技术架构上的深刻问题。随着黑客攻击技术的不断演进，行业需从设备安全、交易验证和风控机制等多个层面全面提升防护能力，以应对日益复杂的威胁。前端开发要做的就是对 访问 DApp 、连接钱包、消息签名、交易签名、交易后处理 等环节不厌其烦的反复验证。实现从“被动修补”到“主动免疫”的跨越。唯有如此，方能在 Web3 的开放世界中守护每一笔交易的价值与信任。

当然链上合约的安全审计也是每个 Dapp 离不开的，ZAN-AI Scan 能够通过形式验证和人工智能辅助安全规范生成确保代码正确性，提供对数百万部署合约进行代码相似性和知识产权风险分析，提供全天候监控和即时通知，涉及可能影响您部署项目的零日漏洞和安全事件。并且拥有一个根据庞大的漏洞数据库进行优化的 GPT 模型，用于检测智能合约中各种现实世界的漏洞。