白帽研究人员在九年后从 2016 年的 ICO 智能合约中释放了 200 万美元的以太币
目录
你可能想知道的事
未修补的智能合约漏洞如何能使投资者资金几乎十年无法访问?
当旧合约仍有价值时,哪些步骤能使回收既有效又符合道德责任?
主要内容
在一次协调的白帽回收中,一名以 0xflorent 为名的安全研究人员与 2016 年失败代币销售 HongCoin 的原管理员合作,释放了大约 1,003.62 ETH——约合 200 万美元——这些以太币在过去九年一直被困在该 ICO 的以太坊智能合约中。该合约的退款机制未按预期运作,因为一个全局计数器和一个损坏的上限阻止了较大的退款,导致尽管销售未达到资金目标,投资者的出资仍无法取回。
其根本技术原因是在一个管理函数中的整数溢出漏洞。 当 HongCoin 的代码在 2016 年编写时,Solidity 与常见的智能合约写法并不总是包含针对整数溢出与下溢的明确防护;后来的语言版本与最佳实践引入了检查与更安全的算术库以降低此风险。在 HongCoin 的案例中,该管理函数——仅可由项目团队控制的多签钱包调用——缺少此类保护。通过以特定输入调用该函数,研究人员可以将持有者的代币余额重置为一,使合约的退款检查通过,从而启用因全局退款计数器而被阻止的提现。
这一关键见解对理解旧合约回收有重大影响:即使看似永久损坏的合约,有时也能在存在管理通路且原始维护者合作的情况下,通过有针对性的交互予以修正。管理员专用的入口点至关重要:虽然整数溢出缺陷使得更改成为可能,但多签所有者仍需授权交易以在主网实施解锁。
重要的是,这次回收并非单方面利用。0xflorent 联络了 HongCoin 的多签持有人,在以太坊主网的本地测试分叉上演示了解锁步骤,并且多签参与者亲自签署了交易。团队执行了 41 笔单独交易——每位受影响的持有人一笔——释放了约 1,000 ETH,这些资金否则无法被取回。另有七位持有人因余额较小可在不需该变通方法的情况下直接退款,并已直接完成退款。
通过此次协调行动,48 位原始投资者变得有资格申领他们的以太币。已有两位受益者取回资金,共回收了 96.5 ETH(以回收时汇率计约 193,000 美元)。此行动紧随同一名研究人员几日前的一次类似白帽回收,当时他将其他遗留合约与过期 swap 中的 19.329 ETH 归还给原持有人。
应将此次回收置于去中心化金融(DeFi)生态的更广泛语境中:近期该领域发生了多起重大利用事件与协议资金外流。高调的黑客事件与漏洞已使数以亿计美元从去中心化协议中被抽离,促使人们对智能合约安全与运营实践加强审视。像此类白帽回收与恶意窃取形成对比,因为它们在移动资金前优先考虑协调、验证与项目维护者或合法所有者的同意。
从安全与治理角度看,此案例强调了几点教训。首先,采用现代安全算术做法与语言功能以防止整数溢出的重要性。其次,明确且有文档记录的管理控制与多签程序的价值,这些能在必要时允许负责任的介入。第三,在提出会改变状态的主链操作时,使用测试分叉与透明的验证步骤有助于降低意外后果的风险——研究人员在多签于主网执行前已在链外验证方法。
最后,本事件表明从旧合约回收价值通常是可行但需谨慎。这需要技术能力来设计正确的操作顺序、道德判断来与维护者及利益相关者沟通,以及操作上的谨慎以确保仅影响预期的余额。在本例中,技术熟练的研究人员与项目的多签持有人之间的合作,产生了一个实用且低风险的解决方案,为长期等待的投资者恢复了资金访问权。
关键见解表
| 方面 | 描述 |
|---|---|
| 根本原因 | 管理函数中的整数溢出漏洞允许重置余额,绕过损坏的退款上限。 |
| 回收金额 | 约 1,003.62 ETH,约合 200 万美元,48 位原始投资者有资格申领资金。 |
| 回收方法 | 协调的白帽利用:研究人员在测试分叉上验证流程;HongCoin 多签签署了 41 笔主网交易以解锁资金。 |
| 伦理与治理 | 回收依赖多签持有者的同意与验证步骤,以避免单方面行动或造成进一步损害。 |
| 更广泛语境 | 发生在多起高调 DeFi 利用事件之中;强调持续需要改进智能合约实践与事件响应流程。 |
之后...
展望未来,此案例强化了几个值得持续关注的领域。首先,在开发过程中采用更安全的编程模式与自动化静态分析可防止许多传统上易被利用的漏洞,例如整数溢出。其次,更广泛使用多签托管、透明治理与有文档的应急程序,可在遗留合约失效时促成负责任的回收。
第三,为安全的状态迁移与链上回收原语提供改进工具,可能能够以标准化、可审核的方式归还资金,而无需为每个案例设计专属的利用方法。对形式化验证、运行时不变式以及更强的默认语言保障(例如要求明确的溢出检查)之研究,将持续降低长期存在且无法访问资金的情况发生率。
最后,安全研究人员、项目维护者与更广泛社区间的合作——强调披露、在分叉上测试以及多签授权——仍然是以最小风险解决类似事件的务实途径。持续投资于事件响应流程与可互操作的回收工具,或能使纠正这些历史错误变得更容易,同时维护去中心化系统的完整性。