内容来源：@WutalkWu、Will42@Will42W。发文时间：下午5:54 · 2025年2月24日
Colin Wu@WutalkWu ：
编辑整理了前几天 Bybit CEO BEN 参加我们 SPACE 的内容全文，我整理了几个要点，细节更丰富：
– 并非完全没有停止提币，而是根据客户级别分批允许提币，散户基本都能正常提，只是以太坊无法提取，机构客户沟通，12 小时后全面放开
– SPACE 里已经说了，会尽快通过 OTC 交易等方式把这些钱还上（如果仔细听到这句话的同学去做多 ETH 应该可以小赚一笔）
– CZ 建议停止提币没问题，如果是热钱包出问题得冻结所有出金。慢雾看后说剩下的部分没有问题，所以才放心做出决定
– 检查过，所有参与签名的人的电脑上都没有木马。各种可能性都有，但现在没办法确定排除哪一种，所以还在查。可以把冷钱包想象成汇丰银行。这次事件就是“汇丰银行”这边出了问题 — — 我把钱往回拿的时候被拦截，导致全部被盗
– 有四个人负责签名，都在不同的网络环境，电脑也定期排查，事后也没发现木马。签名时不在同一个地方，甚至不在同一个国家，是一个人签完后下一个再签，每次都会检查 URL 之类的东西。还在排查到底是哪个环节出了问题
– 审计机构发布了声明，证明他们审计过 Treasury，确认我们的现金和代币储备完全可以覆盖这 15 亿美元的损失
– 不敢想象，如果损失达到 100 亿美元这种量级会怎样，可能得考虑卖公司了
– 最幸运的是，USDT 也在 Safe 的一个钱包里，差不多 30 亿美元，是以太坊的两倍。但那个钱包因为 USDT 储备充足，基本没动过。我猜黑客可能等了一阵子没耐心了，或者不敢动 USDT，因为 USDT 容易被冻结
– 首要任务是透明、重新赢得信任。最关注的是这件事对业务的影响，比如流失了多少用户、多少 VIP 客户、多少机构
– 以后的冷钱包必须分散，不能再把这么大的资产放在一个钱包里。为什么要把 15 亿美元放一个钱包？分成五个不行吗？至少损失不会这么集中。可能因为我们从没被盗过，对出入金体系太自信，就没在这环节多想，更多关注签名环境和电脑安全。我觉得这是个思维转变，不再是想着如何永远不被盗，而是假设会被盗后，怎么确保损失不至于让我们一无所有，而是控制在能承受的范围
– 每个月都有被盗和系统崩溃的演练，这次属于 P1 级别
– Bitget第一个提供帮助，没有任何条件，合同都没签
BEN 直播中对被盗当时操作具体过程的回忆：
otter@otterpal24：
Bybit 被黑最可怕的是，看了各方和bybit自己的安全分析，都只有近似解，没有完全解。就是大家都了解被黑过程的步骤，但是不清楚具体是怎么操作的，甚至bybit 查不出设备上的木马痕迹。这就意味着，整个行业还没建立起抵御朝鲜黑客的手段。
上午12:39 · 2025年2月23日
@Will42W：
@Bybit 被盗事件的原因分析目前仍然在进行中，一开始基本上认为是典型的用户前端植入/拦截型攻击，但随着 @Safe.eth 暂时中止了应用层服务，以及 @Ben Zhou 在与 @吴说区块链 对话中所提到经过所有排查尚未发现任何木马，关于直接原因的结论反而越来越扑朔迷离。
但攻击的底层逻辑是清晰的，就是伪造交易欺骗签名者，替换Safe钱包的实现合约。这不由得让我们产生一些疑问：难道我们只能每次研究清楚黑客攻击手段，才能针对性地做出防范吗？难道防范措施必须是让人的肉眼审核更多的交易信息吗？我们没有技术上的手段，“一劳永逸”的方案去阻止无穷无尽的攻击手段吗？
必须说明的是，至少在Safe智能合约钱包领域，这个手段是存在的。实际上Safe作为业内最广泛的智能合约钱包，为安全性已经做出了完备的考虑，从1.3.0版本开始，就引入了相关的Transaction Guard的概念，与Safe Modules一起，构成了对m/n这种签名权限模型的完整扩充。
简而言之，m/n签名机制只是智能合约上面的一套交易规则。在实践中，用户对任何一套规则集，会有两个方向上的需求：定制化与严格化，定制化用于丰富权限模型，严格化用于加强安全控制，Safe为此推出了Safe Modules和Transaction Guard机制，分别服务于这两个目标。
Safe Modules推出得比较早，在业内已有广泛采用，典型之一是 @Cobo 的Argus，实现了多种丰富的应用模型。Transaction Guard在1.3.0版本推出，实现了在交易最终执行之前的回调模型，可用于检查交易内容，同意或者拒绝交易执行。这个机制如果使用得当，可以成为最后一道保险，阻止伪造交易攻击
Transaction Guard虽然推出较晚，但也有一些应用在使用，最早的是Safe官方文档中引用的Yearn和Zodiac的例子。也许是因为版本较新，也许是因为开发权限检查的脚本代价较高，这个模式没有在业内流行开来，导致大量的Safe钱包都在没有任何保护的情况下“裸奔”，成为最近的几次伪造交易攻击的受害者。
@Solv Protocol 在2023年初基于Safe开发新一代产品的时候，很快意识到了这个问题。为了方便给所有的Safe Wallet增加Guard保护机制，开发了一套称为SolvGuard的智能合约框架，可以定义转账目标、币种、金额、智能合约ABI等规则，通过丰富权限模型的方式来方便每个钱包快速定义和部署Transaction Guard。
简单说，SafeGuard的模型，方便快速定义和实现每一个Safe Wallet的“专款专用”，杜绝一切目的之外的交易。我们相信，必须通过这种方式充分利用Safe合约提供的底层安全审查机制，才能阻止各种无法事先预料的攻击手段，避免落入“被攻击-找原因-解决问题-再被新的手段攻击”的无尽循环。
值得指出的是，此次被攻击的Safe合约，停留在1.1.1版本，没有Transaction Guard的功能，因此遗憾的丧失了最后一道保险机制。为此我们也提醒所有Safe Wallet的使用者，尽可能在不影响业务和基本安全性的前提下，争取升级到1.3.0版本以上，并尽快实施相关保护。
相关文章
