慢雾深度解析 Bitfinex 天价手续费转账:BUG+显示错误「酿成大错」_BUFF:FER

撰文:Thinking@慢雾安全团队

事件背景

分析源自一笔转账金额10wUSDT,手续费却高达7,676枚ETH的天价手续费交易。https://etherscan

将int转成Hexhttps://github

判断是否可以被2整除,如果不行需要在字符开头添加一个0,这里主要是为了能够成功的将数据2个1组写入到buffer。https://github

if(a

returna;}

以出错的示例数据:33974229950.550003进行分析,经过intToBuffer函数中的intToHex和padToEven处理后得到7e9059bbe.8ccd,这部分浏览器js和nodejs的结果都是一致的。

慢雾:DEUS Finance 二次被黑简析:据慢雾区情报,DEUS Finance DAO在4月28日遭受闪电贷攻击,慢雾安全团队以简讯的形式将攻击原理分享如下:

1.攻击者在攻击之前先往DeiLenderSolidex抵押了SolidexsAMM-USDC/DEI的LP。

2.在几个小时后攻击者先从多个池子闪电贷借出143200000USDC。

3.随后攻击者使用借来的USDC在BaseV1Pair进行了swap操作,兑换出了9547716.9个的DEI,由于DeiLenderSolidex中的getOnChainPrice函数是直接获取DEI-USDC交易对的代币余额进行LP价格计算。因此在此次Swap操作中将拉高getOnChainPrice函数获取的LP价格。

4.在进行Swap操作后,攻击者在DeiLenderSolidex合约中通过borrow函数进行借贷,由于borrow函数中用isSolvent进行借贷检查,而在isSolvent是使用了getOnChainPrice函数参与检查。但在步骤3中getOnChainPrice的结果已经被拉高了。导致攻击者超额借出更多的DEI。

5.最后着攻击者在把用借贷出来DEI兑换成USDC归还从几个池子借出来的USDC,获利离场。

针对该事件,慢雾安全团队给出以下防范建议:本次攻击的原因主要在于使用了不安全的预言机来计算LP价格,慢雾安全团队建议可以参考Alpha Finance关于获取公平LP价格的方法。[2022/4/28 2:37:18]

不一致的地方是在newBuffer的操作:

慢雾:DOD合约中的BUSD代币被非预期取出,主要是DOD低价情况下与合约锁定的BUSD将产生套利空间:据慢雾区情报,2022 年 3 月 10 日, BSC 链上的 DOD 项目中锁定的 BUSD 代币被非预期的取出。慢雾安全团队进行分析原因如下:

1. DOD 项目使用了一种特定的锁仓机制,当 DOD 合约中 BUSD 数量大于 99,999,000 或 DOD 销毁数量超过 99,999,000,000,000 或 DOD 总供应量低于 1,000,000,000 时将触发 DOD 合约解锁,若不满足以上条件,DOD 合约也将在五年后自动解锁。DOD 合约解锁后的情况下,用户向 DOD 合约中转入指定数量的 DOD 代币后将获取该数量 1/10 的 BUSD 代币,即转入的 DOD 代币数量越多获得的 BUSD 也越多。

2. 但由于 DOD 代币价格较低,恶意用户使用了 2.8 个 BNB 即兑换出 99,990,000 个 DOD。

3. 随后从各个池子中闪电贷借出大量的 BUSD 转入 DOD 合约中,以满足合约中 BUSD 数量大于 99,999,000 的解锁条件。

4. 之后只需要调用 DOD 合约中的 swap 函数,将持有的 DOD 代币转入 DOD 合约中,既可取出 1/10 转入数量的 BUSD 代币。

5. 因此 DOD 合约中的 BUSD 代币被非预期的取出。

本次 DOD 合约中的 BUSD 代币被非预期取出的主要原因在于项目方并未考虑到 DOD 低价情况下与合约中锁定的 BUSD 将产生套利空间。慢雾安全团队建议在进行经济模型设计时应充分考虑各方面因素带来的影响。[2022/3/10 13:48:45]

newBuffer(padToEven(hex.slice(2)),'hex');

动态 | 慢雾:2020年加密货币勒索蠕虫已勒索到 8 笔比特币:慢雾科技反(AML)系统监测:世界最早的知名加密货币勒索蠕虫 WannaCry 还在网络空间中苟延残喘,通过对其三个传播版本的行为分析,其中两个最后一次勒索收到的比特币分别是 2019-04-22 0.0584 枚,2019-09-01 0.03011781 枚,且 2019 年仅发生一次,另外一个 2020 还在活跃,2020 开始已经勒索收到 8 笔比特币支付,但额度都很低 0.0001-0.0002 枚之间。这三个传播版本第一次发生的比特币收益都是在 2017-05-12,总收益比特币 54.43334953 枚。虽然收益很少,但 WannaCry 可以被认为是加密货币历史上勒索作恶的鼻主蠕虫,其传播核心是 2017-04-13 NSA 方程式组织被 ShdowBrokers(影子经纪人) 泄露第三批网络军火里的“永恒之蓝”(EternalBlue)漏洞,其成功的全球影响力且匿名性为之后的一系列勒索蠕虫(如 GandCrab)带来了巨大促进。[2020/2/23]

处理方式分析:浏览器js

声音 | 慢雾科技联合创始人余弦:隐私不是拿来保护的 是拿来控制的:据巴比特消息,慢雾科技联合创始人余弦今日在活动中表示:“我觉得隐私不是拿来保护的。我的观点是,隐私是拿来控制的。大家都知道我们国家的法律里面有一个关于隐私的权利,大家都有隐私权,当然不一定所有人都会深刻地了解这个东西,包括你在使用很多互联网应用的时候,你可能不一定会它的隐私条款。”[2019/5/16]

通过webpack打包好js文件并对文件进行引用,然后在浏览器上进行调试分析。

首先输入的示例字符33974229950.550003会进入到intToBuffer的函数中进行处理。

动态 | 慢雾安全团队发现新型公链攻击手法“异形攻击”:慢雾安全团队发现针对公链的一种新型攻击手法“异形攻击”(又称地址池污染),是指诱使同类链的节点互相侵入和污染的一种攻击手法,漏洞的主要原因是同类链系统在通信协议上没有对非同类节点做识别。这种攻击在一些参考以太坊通信协议实现的公链上得到了复现,以太坊同类链,由于使用了兼容的握手协议,无法区分节点是否属于同个链,导致地址池互相污染,节点通信性能下降,最终造成节点阻塞、主网异常等现象。相关公链需要注意持续保持主网健康状态监测,以免出现影响主网稳定的攻击事件出现。[2019/4/18]

同步分析intToBuffer的处理过程,这部分和」关键代码分析「部分的代码逻辑是一样的,处理转换部分得到的结果是7e9059bbe.8ccd。

接下来分析如何将转换后的字符填充进入的buffer中,通过这步可以得到buffer的内容是126,144,89,187,14,140,205对应的是7e,90,59,bb,e,8c,cd。

>0x7e->126>0x90->144>0x59->89>0xbb->187>0xe->14>0x8c->140>0xcd->205

这里发现e.这部分的小数点消失了,于是开始解小数点消失之迷,追踪到hexWrite这个函数,这个函数会将得到的数据2个一组进行切分。然后用了parseInt对切分后的数据进行解析。

然而parseInt('e.',16)->14===parseInt('e',16)->14消失的小数点被parseInt吃掉了,导致最终写入到buffer中的数据发生了错误,写入buffer的值是7e9059bbe8ccd。

处理方式分析:nodejs

由于浏览器上出问题的是7_**__**_e9059bbe.8ccd在写入buffer的时候小数点被parseInt吃掉了导致数据出错,但是经过分析,node的数据也是错误的,且产生错误的原因是和浏览器的不一样。

首先我们先看下如下的示例:

node三组不同的数据填充到buffer得到的结果居然是一样的,经过分析node的buffer有个小特性,就是2个一组切分后的数据,如果没法正常通过hex解析的,就会把那一组数据以及之后的数据都不处理了,直接返回前面可以被正常处理的那部分数据。可以理解为被截断了。这部分可以参考node底层的buffer中node_buffer.cc中的代码逻辑。

>newBuffer('7e9059bbe','hex')>newBuffer('7e9059bbe.8ccd','hex')>newBuffer('7e9059bb','hex')

执行结果的比较

node由于会将原始数据7e9059bbe.8ccd中的e.及之后的数据进行截断,所以最终错误的值是7e9059bb,相比正确的值07e9059bbe小。

node的执行结果:

浏览器由于会将原始数据7e9059bbe.8ccd中的.吃掉,所以最终错误的值是7e9059bbe8ccd,相比正确的值07e9059bbe大很多。

浏览器的执行结果:

问题的原因

ethjs-util的intToBuffer函数不支持浮点型的数据,且在这个函数中没有判断传入的变量类型,来确保变量类型是预期内的。由于ethereumjs的toBuffer引用了ethjs-util的intToBuffer进行处理,也没有对数据进行检查。导致了这次事件的发生,所幸最终善良的矿工归还了「天价手续费7626ETH」。

吸取的教训

从第三方的库的角度来看,在编码过程中应该要遵循可靠的安全的编码规范,在函数的开头要对传入的数据进行合法性的检查,确保数据和代码逻辑是按照预期内执行。

从库的使用者的角度来看,使用者应该要自行阅读第三方库的开发文档和对接文档,并且也要对代码中接入第三方库的逻辑进行测试,通过构造大量的数据进行测试,确保业务上能够正常按照期望执行,保证高标准的测试用例的覆盖率。

参考资料:https://github.com/ethereumjs/ethereumjs-monorepo/issues/1497https://blog.deversifi.com/23-7-million-dollar-ethereum-transaction-fee-post-mortem/https://www.chainnews.com/news/611706276133.htm

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金智博客

[0:15ms0-7:98ms