内容简介:北京时间06月29日凌晨02时03分起,最近因“借贷即挖矿”模式而备受关注DeFi 平台 Balancer 上的 STA 和 STONK 两个 ERC20 通缩代币池遭到了黑客攻击,共计损失了超50万美元。PeckShield 安全人员介入分析后,迅速定位到问题的本质在于,接下来的篇幅中,我们将逐步解析黑客在该笔闪电贷交易(
北京时间06月29日凌晨02时03分起,最近因“借贷即挖矿”模式而备受关注DeFi 平台 Balancer 上的 STA 和 STONK 两个 ERC20 通缩代币池遭到了黑客攻击,共计损失了超50万美元。
PeckShield 安全人员介入分析后,迅速定位到问题的本质在于, Balancer 上的通缩型代币和其智能合约在某些特定场景不兼容,使得攻击者可以创建价格偏差的 STA/STONK 流通池并从中获利。
此次黑客实施攻击共计分了四个步骤,具体而言:
1)攻击者通过闪电贷从 dYdX 平台借出了 104,331 个 WETH; 2)攻击者反复执行 swapexactMountin() 调用,直至 Balancer 拥有的大部分 STA 代币被消耗殆尽,进而开始下一步攻击。最终 Balancer 仅仅剩余 0.000000000000000001 个 STA。 3)攻击者利用 STA 代币和 Balancer 智能合约存在的不兼容性即记账和余额的不匹配性实施攻击,将资金池中的其他资产耗尽,最终共计获利价值 523,616.52 美元的数字资产。 4)攻击者 偿还从 dYdX 借出的闪电贷,并卷走了攻击所得的数字资产。
接下来的篇幅中,我们将逐步解析黑客在该笔闪电贷交易( http://oko.palkeo.com/0x013be97768b702fe8eccef1a40544d5ecb3c1961ad5f87fee4d16fdc08c78106/ ) 中实施的攻击行为。
Balancer 遭黑客攻击全过程技术拆解
(图解黑客攻击全流程)
第一步:闪电贷
从 dYdX 闪电贷 104,331 WETH,这部分熟悉 DeFi 借贷模式的读者应该都比较清楚,此处不再赘述。
第二步:清空 Balancer 的 STA 资产
攻击者通过多次 swapExactAmountIn() 调用清空了 Balancer 的 STA 资产,为下一步实施攻击做准备。值得一提的是,我们发现合约代码中每次能够兑换的资产数额其实有上限,然而狡猾的攻击者预先计算了可兑换的 WETH 最大数额,并巧妙的让 Balancer 只剩了 0.000000000000000001 STA。
由于 Balancer 资金池(BPool)各资产间存在“动态平衡”原理,仅剩接近于 0 的 STA 会拉高 STA 的价值,使得任何人都可以用 1 STA 换到大量的其他数字资产。
第三步:攻击获利
经过前两个准备步骤之后,攻击者是时候展现真正技术了!
(第三步 :攻击获利图示上)
承上所述,攻击者通过 swapExactAmountIn() 函数将 0.000000000000000001 STA 发送到 BPool,以极高的价值差,立即兑换出了 30,347 个WETH,实现了获利。而此时,BPool 的内部记账机制 _records[STA] 在 BPool 真正收到 0.000000000000000001 STA 之前先加了 1(注:此后攻击者会用gulp()对该数值进行重置)。
(第三步:攻击获利图示下)
另外我们发现,在 swapExactAmountIn() 的底部,_pullUnderlying() 尝试从攻击者端收集相应消耗的 STA。然而,由于 STA 转账时还会烧掉 1% 的手续费,实际BPool 是收不到任何 STA 的。这样就使得 BPool 的实际 STA 余额和内部记账产生不匹配。
接下来是最有趣的一部分,攻击者调用 gulp() 不断重置 _records[STA],使得 BPool 中始终保持 0.000000000000000001 个 STA。 因此攻击者可以用极高价的 0.000000000000000001 个 STA 将流通池中的 WETH、SNX、LINK 等其他资产消耗光。
第四步:偿还闪电贷
最终,如上图所示,攻击者偿还了从闪电贷借出的104,331个 WETH。
建议
此次攻击事件再次暴露了 DeFi 可组合性存在的兼容性风险。此前不久,Uniswap 和 Lendf.Me 两个平台就因和 ERC777 标准的兼容性问题,产生了非常严重的黑客攻击事 件。需要警醒的是,在未来 DeFi 行业类似的黑客攻击行为或许会屡见不鲜。
如果问该怎样才能规避这类攻击事件的发生呢?或许有两个优化调整思路:1)STA/STONK 在执行 transfer() 或 transferFrom() 时,当转账数额不足以支付手续费时,应该直接回滚或者返回 False;2) Balancer 应该在每一次 transferFrom() 函数调用后检查 BPool 的余额。
当然,任何安全事件事后采取措施补救都无法弥补已经产生的损失,我们相信最好的解决方案还是事前防备。DeFi 项目开发者应尽可能利用好的代码规范,并可寻求第三方安全公司协助其在上线前进行全面的攻防测试,尽可能找出一切潜在的漏洞。最后,尽可能对 ERC20、ERC777 和其它 DeFi 项目的任何组合行为都做好周密排查。
后续
毫无疑问,Balancer 事件的发生势必也会对 DeFi 社区带来影响,而且这类事情接下来发生的可能性还会很大,在此提醒广大 DeFi 项目开发者应务必重视合约的安全问题。
经我们统计发现,Balancer 在此次攻击事件共计损失了 523,616.52 美元的数字资产,详情列表如下:
PeckShield 作为业内领先的区块链安全公司,安全业务已覆盖全球范围,主要客户包括有:公链提供商 ( EOS、Nervos、Harmony、AVA、HBTC、NEO 、IOST、Bytom、TRON、OKChain ),头部钱包和矿池 ( imToken、SparkPool、比特派、Cobo 金库,VoiceWallet) ,以及头部交易所( Huobi、KuCoin、Bithumb、Upbit、OKex )、DeFi 应用及智能合约( MakerDAO、StarkWare、Tokenloan、InstaDApp、Set Protocol、Ren Project、Hydro Protocol、dForce、Newdex、HoneyLemon )等。
近一年内,PeckShield 已经接连审计了数十个 DeFi 项目,帮助 DeFi 协议做代码安全审计、业务逻辑风控、威胁情报风险预警等等,已经成为服务 DeFi 领域的头部安全公司。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
JavaScript设计模式
Ross Harmes、Dustin Diaz / 谢廷晟 / 人民邮电出版社 / 2008 / 45.00元
本书共有两部分。第一部分给出了实现具体设计模式所需要的面向对象特性的基础知识,主要包括接口、封装和信息隐藏、继承、单体模式等内容。第二部分则专注于各种具体的设计模式及其在JavaScript语言中的应用,主要介绍了工厂模式、桥接模式、组合模式、门面模式等几种常见的模式。为了让每一章中的示例都尽可能地贴近实际应用,书中同时列举了一些JavaScript 程序员最常见的任务,然后运用设计模式使其解决方......一起来看看 《JavaScript设计模式》 这本书的介绍吧!