撰文：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的结果都是一致的。
慢雾首席信息安全官：V神推特被劫持发布钓鱼信息，大概率依旧是sim swap手法:金色财经报道，慢雾首席信息安全官23pds在社交媒体X（原推特）上称，今天V神推特被劫持发布钓鱼信息，大概率依旧是sim swap手法，此前Uniswap创始人推特也同样被黑，都是知名人士被定点攻击事件，知名人士有大量粉丝，发布钓鱼信息曝光度会大大增加，更容易获利。鉴于 sim swap 实在攻击成本太低，大家请注意这种风险。
据悉，此前7月，Uniswap 创始人 Hayden Adams 的 Twitter 账号同样被黑并发布了包含钓鱼链接的推文，推特被黑可能是一种 SIM 卡盗窃，即攻击者接管受害者的电话号码，使他们能够访问银行账户、信用卡或其他社交账户。[2023/9/10 13:29:27]
不一致的地方是在newBuffer的操作：
慢雾：远程命令执行漏洞CVE-2023-37582在互联网上公开，已出现攻击案例:金色财经报道，据慢雾消息，7.12日Apache RocketMQ发布严重安全提醒，披露远程命令执行漏洞（CVE-2023-37582）目前PoC在互联网上公开，已出现攻击案例。Apache RocketMQ是一款开源的分布式消息和流处理平台，提供高效、可靠、可扩展的低延迟消息和流数据处理能力，广泛用于异步通信、应用解耦、系统集等场景。加密货币行业有大量平台采用此产品用来处理消息服务，注意风险。漏洞描述：当RocketMQ的NameServer组件暴露在外网时，并且缺乏有效的身份认证机制时，攻击者可以利用更新配置功能，以RocketMQ运行的系统用户身份执行命令。[2023/7/14 10:54:22]
newBuffer(padToEven(hex.slice(2)),'hex');
慢雾：7月3日至7月7日期间?Web3生态因安全问题损失近1.3亿美元:7月10日消息，慢雾发推称，自7月3日至7月7日，Web3生态因安全问题遭遇攻击损失128,419,000美元，包括Encryption AI、AzukiDao、NFT Trader、MIKE&SID、Bryan Pellegrino、Aptos Foundation、Multichain、CivFund。其中，Multichain被攻击损失1.26亿美元。[2023/7/10 10:12:36]
处理方式分析：浏览器js
通过webpack打包好js文件并对文件进行引用，然后在浏览器上进行调试分析。
首先输入的示例字符33974229950.550003会进入到intToBuffer的函数中进行处理。
慢雾：近期出现假冒UniSat的钓鱼网站，请勿交互:5月13日消息，慢雾首席信息安全官 @IM_23pds 在社交媒体上发文表示，近期有假冒比特币铭文钱包及交易市场平台 UniSat 的钓鱼网站出现，经慢雾分析，假网站有明显的传统针对 ETH、NFT 钓鱼团伙的作案特征，或因近期 BRC-20 领域火热故转而制作有关该领域的钓鱼网站，请用户注意风险，谨慎辨别。[2023/5/13 15:01:11]
同步分析intToBuffer的处理过程，这部分和」关键代码分析「部分的代码逻辑是一样的，处理转换部分得到的结果是7e9059bbe.8ccd。
慢雾：Moonbirds的Nesting Contract相关漏洞在特定场景下才能产生危害:据慢雾区情报反馈，Moonbirds 发布安全公告，Nesting Contract 存在安全问题。当用户在 OpenSea 或者 LooksRare等NFT交易市场进行挂单售卖时。卖家不能仅通过执行 nesting(筑巢) 来禁止NFT售卖，而是要在交易市场中下架相关的 NFT 售卖订单。否则在某个特定场景下买家将会绕过 Moonbirds 在nesting(筑巢)时不能交易的限制。慢雾安全团队经过研究发现该漏洞需要在特定场景才能产生危害属于低风险。建议 Moonbirds 用户自行排查已 nesting(筑巢)的 NFT 是否还在 NTF 市场中上架，如果已上架要及时进行下架。更多的漏洞细节请等待 Moonbirds 官方的披露。[2022/5/30 3:50:23]
接下来分析如何将转换后的字符填充进入的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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。